AI enablement · Agents and process automation
Where an agent beats a workflow, and where it does not
Multi-step automation with tool calling, durable state, failure handling and human checkpoints. Including the judgement about when a deterministic workflow is the better engineering decision, which is more often than the market suggests.
Where this starts
Autonomy is a cost, not a feature
An agent that chooses its own path is harder to test, harder to debug and harder to explain than a workflow that follows a defined one. Sometimes that cost buys something real, because the path genuinely differs per case. Frequently it does not, and a team has taken on the hardest available implementation of a problem a state machine would have solved in a fortnight.
What we usually find
- An agent used where the steps were always going to be the same
- A loop that retries, spends and achieves nothing in particular
- Failures that cannot be reproduced, and therefore cannot be fixed
- No record of why the agent chose what it chose
- A run that half completed, with no way to resume it or unwind it
- A cost per run that nobody discovered until the invoice arrived
Our position
We will frequently recommend a deterministic workflow with a single model call inside it. It is less impressive to describe and it is usually the right answer.
What the work covers
Designing work a machine can finish
The engineering is in the boundaries: what the agent may do on its own, what it must ask about, and what happens when a step fails after earlier ones have already taken effect.
Choosing the shape
Deterministic workflow, workflow with model steps, or a genuine agent. Decided from how much the path actually varies in your cases, rather than from what the category happens to be called this year.
Tool design
Each action exposed as a narrow, precisely described tool with validated inputs. Most agent failure is really a tool that was too broad or too vaguely described to be used correctly.
State and resumption
Durable state, so a long run survives a restart and can be resumed or unwound rather than begun again from the top with whatever side effects the first attempt left behind.
Human checkpoints
Explicit approval before anything irreversible, presented with the context needed to approve quickly. A checkpoint that is slow to answer stops being a control and becomes a queue.
Failure and compensation
What happens when step four fails after step three has already sent the email. Compensating actions designed in advance rather than discovered during the first real incident.
Step and spend ceilings
A hard limit on steps, tokens and cost per run, because an unbounded loop is a financial incident as much as a technical one and it happens on a weekend.
How a run is accountable
Every run explains itself
An agent nobody can audit after the fact will not be trusted with anything that matters, and it should not be.
- Trace
- Every step, tool call, input and decision recorded as a single trace, so a run can be replayed and understood rather than reconstructed from guesswork.
- Limits
- Step, token and spend ceilings enforced per run, with the run halted and reported rather than quietly allowed to continue.
- Idempotency
- Actions safe to repeat, so recovery does not duplicate the email, the order or the payment that the first attempt already sent.
- Approvals
- Checkpoints recorded with who approved and what they were shown, which is what makes the automation defensible months later.
- Regression
- A fixed set of scenarios replayed on every change, because a prompt edit can alter behaviour three steps downstream in a way no unit test will catch.
What you are left holding
- An honest recommendation on whether you need an agent at all
- Tools that are narrow, validated and documented
- Durable runs that resume rather than restart
- Step and spend ceilings enforced per run
- A replayable trace for every run
Describe the process from end to end
If the steps turn out to be the same every time, we will say so and build you something simpler.