Agents go faster only on the work you can describe

The measured speedup from agent-run work is real and smaller than the headlines. It shows up on tasks somebody bothered to specify, and nowhere else.

What happened

Augment Code published a description of the agent-run development loop, a way of organising work where AI agents plan, build, test and verify on their own and pause at named human checkpoints rather than at the end of a line. It points at Forrester, Gartner and Google Cloud's DORA research as evidence the industry is drifting this way.

The model itself is not the interesting part. The number attached to it is. Measured gains land at roughly two to three times faster, and only on tasks that were well specified before the agent touched them. Larger claims exist, and the piece puts the gap down to something dull: a person still has to look at the result, and that person works at human speed.

Two words are carrying most of the weight in that sentence. Well specified.

Why this matters to your business

Read the finding as a statement about your documentation rather than about AI.

An agent moves fast when it can tell what finished looks like. Give it a task with a clear input, a clear output and some way to check one against the other, and it will run the loop by itself. Give it a task where "correct" lives in a supervisor's head, and it produces something plausible that a person then has to read line by line. You bought the speed and spent it again in review.

Most support and back-office work is the second kind. The refund policy has exceptions nobody wrote down. Escalation happens when a senior agent senses a customer is about to leave. What makes the answer right is judgement built over years, and judgement is not a specification.

So the first honest question before automating anything is not which model to use. It is whether you can write down what a good outcome looks like for this task, in terms a machine could check. Where the answer is yes, expect the gains to be real. Where it is no, the work to do first is writing the rule down, and that work is not technical.

Why this is a CX-Builder use case

The move is to get the definition of done out of people's heads and somewhere a machine can reach it. That happens two ways, and CX-Builder does both.

Retrieval covers the part that is already written but scattered. Policy documents, the knowledge base, the last two years of resolved tickets: an agent grounded in those answers from your actual rules instead of from a general impression of how refunds usually work. Ambiguity you cannot fix by wording the prompt harder gets fixed by pointing at the source. Because CX-Builder runs on your own infrastructure, those documents never leave it.

Human checkpoints cover the part nobody has written down yet. You name the condition: an amount above a threshold, a low confidence score, a case type you have decided not to automate. Everything the specification covers runs on its own. Everything it does not stops and waits for a person. That is a loop with a brake on it rather than an open pipe.

What this looks like if you build it

In practice it is one flow with four deliberate parts. A retrieval step over the policy documents and past resolutions, so the agent reasons from your rules. A structured output step, so the proposal comes back as fields rather than a paragraph, which is the only thing that lets a downstream condition evaluate it at all. An approval node on the branches you have not specified well enough to trust yet. Logging across all of it.

That last part is what compounds. The queue sitting at the human checkpoint is a live list of the cases your specification does not cover. Work through it, write down what the reviewer keeps deciding, and a little more of the loop closes each quarter.