AI Speedforce
ABOUT / METHOD

How we work

This page is about method, not about us. It says how a task gets scoped, what has to be true before an agent writes anything, and what you own at the end.

01Stance

What we hold to

We would rather scope one task narrowly and prove it than build a platform nobody trusts. Everything below follows from that.

Naming the job

Most tasks pitched as agents are workflows, and we say so. If the path is fixed and you already know every branch, a scripted workflow is cheaper to build, cheaper to run and easier to debug. We will tell you that before you pay for a model to rediscover it on every request.

Reliability

Reliability is the job, not a phase at the end. Eval cases, tracing and budgets are written into the first sprint, not bolted on once the demo impresses somebody. An agent that works once is not evidence of anything.

Human gate

Write actions wait for a person until you decide otherwise. Reads can be broad. Anything that changes a record, sends a message or moves money sits behind an approval step, and you are the one who opens that step up, task by task.

Ownership

You own the code, the tools and the eval suite. The prompts, the tool definitions, the MCP servers and the test cases live in your repository. Nothing in the build depends on us staying in the room.

02Work

How an engagement runs

Five steps, in this order. The order matters: each one produces the thing the next one is measured against.

  1. Scope one task narrowly enough to be measured

    We pick a single job with a clear trigger and a clear finish, then write down what the agent reads, what it writes and where it stops. If the task will not reduce to that, we say so and reshape it before anyone builds.

  2. Agree the eval cases from your real examples

    You give us examples of the task being done, including the awkward ones. Those become the test suite, and we agree what counts as a pass before the agent exists rather than arguing about it afterwards.

  3. Agree the cost and latency budget

    Every task gets a ceiling on what one run may cost and how long it may take. Those numbers are yours to set. They constrain the design, so a plan that cannot meet them gets changed now, not after the first invoice.

  4. Build to those, with tracing on from the first run

    Every run records its plan, its tool calls, the inputs and outputs of each one, and its cost. You can read what the agent did and why from day one, not after we hand over.

  5. Widen scope only once the traces say it is safe to

    More tools, more autonomy and fewer approval steps come one at a time, and only where the traces and the eval suite support it. Scope goes up on evidence, not on enthusiasm.

The same sequence runs whether the task is agent engineering, retrieval work or an automation, and whichever platform it lands in.

03Terms

What we commit to

Not results we cannot show you yet. These are the conditions we work under, on every engagement.

Evals Every agent ships with an eval suite Written from your real examples, before the agent exists.
Tracing Every run is traced end to end Plan, tools, inputs, outputs and cost, from the first day you use it.
Human gate Write actions wait for a person by default We open that up only where you tell us to.
Budgets Cost and latency ceilings are agreed before we build Enforced inside the run, not reviewed after the invoice.
[PLACEHOLDER] company facts

Team, location, founding and client references have to be supplied by Rahul before this page is finished. None of it has been invented in the meantime: every claim above describes method only, and the page carries no statement about who we are, how many of us there are, how long we have been doing this or who we have done it for.

04Asked

Questions about working together

How do you charge?

Engagements are scoped per task, and we quote once that scoping is done. We do not quote before we understand what the agent would read, what it would write, and where a person has to approve. The quote is tied to the task we scoped, the eval cases we agreed and the cost and latency budget the build is held to, so you can see what you are paying for rather than a rate against an open-ended brief.

How small can a first project be?

One task. That is the size we prefer to start at, because a single task can be scoped narrowly enough to be measured, and a measured task tells you whether the next one is worth doing. If a job cannot be reduced to one task with a clear trigger and a clear finish, we say so before anyone builds it.

What do you need from us to start?

Real examples of the task being done, including the awkward ones, because those become the eval cases. Access to the systems the agent would read and write, at the narrowest scope that does the job. And a named person who can decide which write actions an agent may take without approval. That is enough to scope.

Bring us one task

Describe a single job you would hand to a capable new starter. We will tell you whether an agent should do it, what it would touch, and where a person still has to sign off.

AI Speedforce
Start a project