Most agent projects demo beautifully and then fall over in week three. The demo is three steps long; the real workflow is twenty, and it fails somewhere in the second half, usually after the expensive work is already done.
I build agent systems for the twenty-step case.
What that involves
- Durable state. The run keeps its decisions in storage, not in the conversation, so a step that needs something established earlier can re-read it rather than hope it is still in the context window.
- Idempotent tool calls. Every side effect carries an idempotency key, so a retry cannot send the second invoice or open the second pull request.
- Approval gates. Consequential actions stop and ask, with a record of what was proposed and who agreed. Everything else runs unattended.
- Compensation. Where a step cannot be undone, the system says so plainly instead of claiming a rollback it does not have.
- Observability. When a run dies you can see which step, on what input, holding what state.
Signals you need this
- Long runs fail in the second half and nobody can say exactly why.
- A retry has done something twice that should have happened once.
- The agent works for the person who built it and nobody else.
- You cannot tell whether a run half-succeeded.
- Cost or latency has grown and no one can attribute it to a step.
How the work runs
Usually a short paid discovery first: I read the code and the traces and write up what is actually failing, with a plan. That stands on its own even if you take it elsewhere. From there, delivery in phases against agreed checkpoints, with the reliability work landing before the feature work, because otherwise it never lands.
Related writing
- Why agents stall at step nine
- How a language model actually works
- The context window: what the model can actually see
Start a conversation
Bring the awkward part. If it is not something I should take on I will say so, and point you at what would help.