Agent orchestration

Explicit state, typed tools, bounded loops and a replayable trace. An agent is a distributed system, so we build it like one.

Most agent failures are not reasoning failures. They are the failures any distributed system has: a step retried and wrote twice, a loop that never terminated, a tool call that silently returned an error string, state that nobody could inspect after the fact. We build agents as state machines with explicit transitions, because that is the version you can debug at nine on a Tuesday morning when it has done something odd.

What we actually do

Explicit state graphs rather than open ended loops, so every transition is named, logged and replayable
Typed tool contracts with schema validation on both the call and the return, and an error path that is a value rather than a string the model has to interpret
Idempotency keys on every write, so a retry does not create a second refund, ticket or journal entry
Step and token budgets with a defined terminal state, so a confused run stops rather than spends
Planning separated from execution where the task warrants it, so a bad plan is caught before it takes actions
Deterministic code for the parts that are deterministic. A regular expression, a lookup table or a SQL query is not a worse answer for being unfashionable
Full run traces with inputs, retrievals, tool calls, state and timings, retained and searchable
Shadow running against live traffic before an agent is granted authority to act

What we instrument

Measurements, not results. These are the readouts we put in place so that you end up with numbers about your own system. There are no values on this page because a value here would be somebody else’s.

Task completion rate, split by whether completion required a human step
Steps and tool calls per completed task, and the distribution rather than the average
Tool call error rate by tool, and how often an error was recovered from
Time to terminal state at the median and the tail
Rate of runs that hit a budget ceiling instead of finishing

Where this stops working

An agent with authority over a system that has no rollback is a design we will argue against, whatever the brief says
Long horizon autonomy over many steps degrades, and the honest design is a shorter horizon with a checkpoint rather than a longer one with hope
If a process is genuinely deterministic, an agent is the wrong tool and a workflow engine is the right one. We say so before quoting the larger build

What we work with

Named as plain text. None of these is a partnership, an endorsement or a default: the right one is chosen per engagement, usually the one your team already runs.

LangGraph and comparable state graph frameworks
Queues and workflow engines for durable execution
Typed schemas over every tool boundary
Tracing across steps with OpenTelemetry

engineering / the other five

None of these works alone.

C1Retrieval and contextGetting the right passages in front of the model. Most quality problems that look like reasoning problems are retrieval problems.C2Evaluation and quality gatesA labelled set, a threshold agreed in writing, and a gate in CI. Built before the feature, not after the first complaint.C4Guardrails and escalationWhat the system may do alone, what it must hand to a person, and what the person receives when it does.C5Observability, cost and driftQuality, latency and cost per task on a dashboard your team owns, with an alert when any of the three moves.C6Product and platform engineeringThe application around the model: interface, data model, auth, pipelines, infrastructure as code and a deployment your team can run.

Where does your system sit against this?

Send the architecture and the failure you are seeing. You get a written read from an engineer within a working day.

Start a build

What we actually do

Explicit state graphs rather than open ended loops, so every transition is named, logged and replayable

Typed tool contracts with schema validation on both the call and the return, and an error path that is a value rather than a string the model has to interpret

Idempotency keys on every write, so a retry does not create a second refund, ticket or journal entry

Step and token budgets with a defined terminal state, so a confused run stops rather than spends

Planning separated from execution where the task warrants it, so a bad plan is caught before it takes actions

Deterministic code for the parts that are deterministic. A regular expression, a lookup table or a SQL query is not a worse answer for being unfashionable

Full run traces with inputs, retrievals, tool calls, state and timings, retained and searchable

Shadow running against live traffic before an agent is granted authority to act

What we instrument

Task completion rate, split by whether completion required a human step

Steps and tool calls per completed task, and the distribution rather than the average

Tool call error rate by tool, and how often an error was recovered from

Time to terminal state at the median and the tail

Rate of runs that hit a budget ceiling instead of finishing

Where this stops working

An agent with authority over a system that has no rollback is a design we will argue against, whatever the brief says

Long horizon autonomy over many steps degrades, and the honest design is a shorter horizon with a checkpoint rather than a longer one with hope

If a process is genuinely deterministic, an agent is the wrong tool and a workflow engine is the right one. We say so before quoting the larger build

What we work with

Named as plain text. None of these is a partnership, an endorsement or a default: the right one is chosen per engagement, usually the one your team already runs.

LangGraph and comparable state graph frameworks

Queues and workflow engines for durable execution

Typed schemas over every tool boundary

Tracing across steps with OpenTelemetry