An agent that runs the process, not just the conversation

What this is actually bought to fix

A chatbot answers a question. It does not do the work. The companies that buy this have a process that takes two or three hours of somebody's day, touches four or five different systems, and changes often enough that it has resisted every attempt to reduce it to a fixed rule. A refund case from the first email to the payment. New leads researched and written into the CRM. The month-end reconciliation nobody wants.

This is the most expensive service in the category because it is the one with the clearest return. Automating a process that occupies two people full time changes a headcount line, not a software line, and the fee stops being the interesting number. The interesting number is how reliable it turns out to be — and that is decided almost entirely by choices made in the first week, before any code exists.

How the build runs

1. Map the process with the person who actually does it. Every step, every decision, every exception, written down as it really happens rather than as the documentation claims. This is the single most important stage and it is not a workshop — it is sitting with someone while they work. One week.
2. Decide, step by step, what is code and what is the model. This is where reliability comes from. Most steps in most processes are lookups, transformations and rules, and all of those belong in ordinary code that is right every time. The model is reserved for the places that genuinely need judgement or language. Reducing a process from eight model steps to three moves the completion rate up by roughly twenty points without changing anything else. Three to five days.
3. Build the tools and write their descriptions carefully. Each capability the agent can call — find the customer, list their orders, check the tracking — is built, and then given a written description. The model never sees your code. It reads that sentence and nothing else, so it says what the tool returns, over what period, in what order, and what it does not do. One to two weeks.
4. Build the loop, with a ceiling and approval points. A hard limit on how many steps a single run may take, so nothing spirals. Approval gates on anything irreversible. Structured logging of every step. One to two weeks.
5. Run fifty real cases and measure. Historical cases with known correct outcomes, run through the finished system, scored on how many a person would have approved unchanged. That percentage is the number the whole project is judged on, and it is measured rather than asserted. One to two weeks.
6. Widen the autonomy gradually. Everything through approval at first. After several weeks of real running, the categories that are consistently correct come off the approval queue, one at a time, with the figures to justify each release. Ongoing through the final weeks.

Typical tooling — direct tool use against the model API or the Claude Agent SDK, LangGraph where the flow genuinely warrants it, Temporal or Inngest for runs that last hours and can pause in the middle, n8n for the parts that are plain automation and should stay that way, Postgres for the run history, and Langfuse for tracing. That last one is not optional here. Without a trace of each run, a failure is unexplainable, and an unexplainable failure ends the project.

What changes the quote

How many systems it has to touch. Each additional system is roughly a week of work and a step up in price — its own authentication, its own error behaviour, its own edge cases where a record exists but is not in the state you expected.

Whether money moves. A process that issues refunds or payments carries roughly double the testing and guardrail work of one that drafts and files. That is not caution for its own sake — it is the difference between a mistake you correct and a mistake you refund.

Whether your systems can be reached programmatically. Modern platforms with proper APIs sit at the low end. Older software with no programmable access, where the only route in is a person clicking, changes the project completely. This is the first thing we establish.

Where these go wrong

Reaching for multiple agents before one has failed. A job that one agent and three well-described tools would handle gets divided among five specialised agents because the architecture sounds more serious. The result is five times the running cost, five times the latency, and a fault that could have originated anywhere with no way to isolate it. Start with one. Add a second when the first demonstrably cannot do something, and write down what that was.

Giving the model steps that belong in code. New builders hand the whole process to the model because it can technically do all of it. Then the compounding takes over — eight model steps at ninety-five percent each produce a fully correct run about two thirds of the time, and every third case needs a human to unpick. The same process with three model steps and five coded ones behaves like a different product.

Tool descriptions written as an afterthought. A tool labelled gets orders will be called at the wrong moment, because the model has no other information about it. A tool described as returning the customer's orders from the last twelve months, newest first, is called correctly — and, just as importantly, the model knows not to expect a two-year-old order from it. Vague descriptions are the most common cause of agents that behave erratically for no visible reason.