A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
An agent that gets each step right nine times out of ten sounds reliable. Chain five steps and it completes correctly about fifty-nine per cent of the time.
That multiplication is the whole discipline. A demo runs three steps on a clean input and looks extraordinary. Production runs seven steps on input somebody typed badly, with a tool that times out occasionally, and the compounding failure rate turns an impressive prototype into a feature that works slightly more often than not.
Everything that separates a working agent from a demo is a response to that arithmetic. Fewer steps. Narrower tools that are harder to misuse. Validation between steps so an error is caught where it happens rather than three steps later. Deterministic code wherever a decision does not genuinely need a model.
Which leads to the position we take with most clients: a large share of what gets specified as an agent should be a workflow with a model at two of the steps. That is not a lesser answer. It is usually the one that ships.
Demos are easy in this field. We screen for the things that decide whether it survives contact with users.
Whether they think in compounding failure rates and reduce step count deliberately, or add prompt instructions and hope.
Narrow, well-described, idempotent tools. A tool that does the wrong thing when called twice is a production incident waiting to happen.
A fixed set of real cases and a measured success rate, built before prompt iteration rather than after the first complaint.
Step ceilings, per-run budgets, context management, and awareness that a looping agent bills for every retry.
Willingness to say a known sequence should be code with a model in two places. The most valuable judgement in this role.
A live conversation in English, every time. Expectations in this field need managing carefully and early.
Agents fail in two directions, and teams are usually only watching for one of them.
The first is silent incorrectness. An agent that cannot complete a task rarely stops and says so — it produces something plausible instead. A research agent returns a confident summary citing a source it did not read. A data agent returns a number derived from the wrong column. There is no exception and no error rate to alert on, because from the system's point of view everything succeeded. Where a human accepts the output without checking, and the whole point was to avoid checking, the error propagates into whatever comes next.
The second is cost, and it arrives much faster than anybody plans for. An agent that loops — retrying a failing tool, re-planning after each failure, appending every attempt to a growing context — does not fail loudly either. It keeps working. Each iteration carries the entire history forward, so token spend per step climbs as the run goes on, and one badly-formed request can produce a run costing hundreds of times a normal one. Without a hard step limit and a per-run budget, a single malformed input at three in the morning is a genuine incident.
There is a third risk worth naming. An agent that reads untrusted content — web pages, inbound email, uploaded documents — is taking instructions from whatever it reads. If it also holds tools that can send mail or write to systems, the content it processes can influence what it does. Anybody building agents that touch external input needs to have thought about this before you ask.
Mid-level (2–4 years, with real LLM exposure). Builds agents on an established framework. Comfortable with tool definitions, prompting and the API surface. Needs direction on where determinism should replace a model call.
Senior (4–7 years). Designs the decomposition — what is a tool, what is code, where a human approves. Owns evaluation, tracing and cost control, and can defend making the system less agentic to make it more reliable.
Lead (7+ years). Owns the architecture across use cases, sets the evaluation and safety standard, decides which processes are suitable for autonomy at all, and handles the review path for anything irreversible.
Internal process automation. Multi-step work over your own systems, with tools you control. The most tractable category, and where the value usually is.
Customer-facing assistants. Higher stakes, because errors are visible externally. Needs stricter guardrails and a real escalation path.
Retrieval-heavy agents. Search and synthesis over your documents. Often paired with LLM engineers who own the retrieval quality that determines everything downstream.
Rescue engagements. An agent that works in the demo and not in production. Common, and usually solved by removing steps rather than adding prompts.
Evaluation and observability. Building the harness that tells you whether a change made things better. Unglamorous, and the thing most teams are missing.
Week one. They instrument before they build. Expect tracing of every step, tool call and token count, because without it no later claim about reliability or cost can be checked. Expect them to ask what the acceptable failure rate is and what happens when the agent is wrong — questions many teams have not answered.
Weeks two to four. An evaluation set built from real inputs, including the awkward ones, and a measured success rate against it. Expect the number to be lower than the demo suggested, and expect that to be presented as information rather than apologised for. Expect at least one step to have been replaced by ordinary code.
The warning sign is iterating on prompts with no evaluation harness. Without a fixed set of cases, prompt changes are judged on whichever example was tried last, and the system oscillates — fixing one behaviour and breaking another, with no way to notice. Somebody who has shipped agents builds the harness first because they have been through that loop.
Specifying an agent when you need a workflow. If the sequence of steps is known in advance, you do not need a model to choose them. Hard-code the sequence and use the model for the parts that genuinely require judgement. This is more reliable, far cheaper, and much easier to debug — and it is the recommendation we make most often.
Judging on a demo. Demos use clean inputs and a happy path. Ask instead for the success rate across fifty real cases, and for what the failures looked like. A candidate who has that number has built something real; one who has not has built a demo.
No budget or step ceiling. Agents loop. Without a maximum step count, a per-run token budget and a timeout, one pathological input can produce a bill nobody authorised. These take an afternoon to add and are missing from most prototypes we are asked to review.
Giving an agent irreversible actions with no approval step. Reading is recoverable. Sending, paying, deleting and posting are not. Until you have measured reliability over months, irreversible actions want a human in front of them — and the developer who suggests that before you do is the one worth hiring.
Rates depend on seniority, systems integration depth, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.