Most "AI agent" projects that reach Sparsum aren't multi-step agents. They're single-step automations with an LLM in the middle — which is useful, but a completely different risk category from what the word "agent" suggests. An agent that executes one action and receives the result is predictable: you know exactly what's going to happen, and governance comes down to validating input and output. An agent that decides a sequence of actions — and adjusts that sequence based on what it discovers along the way — is a different architecture, with a different risk profile and a different governance requirement.
Confusing the two is where most projects lose control.
The difference between executing and deciding
Single-step automation follows a fixed script: it takes an input, applies a transformation or calls an API, returns an output. The LLM participates in a single decision — classify, extract, summarise — but the flow around it is deterministic.
A multi-step agent is different because the next step depends on the result of the previous one, and that decision is made by the agent itself, not coded in advance. In practice: the agent queries a system, evaluates what it found, decides whether it needs more information, queries another system, and only then decides the final action. Every intermediate step is a genuine fork — not a pre-programmed conditional with every path already mapped out.
That changes the central governance question. Single-step automation answers "is this output correct?" A multi-step agent needs to answer "was this sequence of decisions — including the intermediate ones that never show up in the final result — reasonable?"
What changes in the architecture: from fixed script to decision loop
Technically, the jump from single-step to multi-step introduces three components simple automation doesn't have:
- Planning — the agent decides the order of actions before or during execution, instead of following a fixed sequence written by a developer.
- Context-conditioned tool use — the same task can trigger different tools depending on what was discovered in previous steps, not a static rule.
- State across steps — the agent needs to maintain and update context across multiple calls, and that state influences future decisions within the same run.
Each of these three components is also a new failure surface. Wrong planning burns API calls on paths that lead nowhere. Poorly conditioned tool use triggers the wrong action with real context, not hypothetical. Corrupted state between steps propagates an error from step 2 into the result of step 5 — and when someone audits the final result, the root cause is already three steps back.
Where multi-step adds real value
Multi-step isn't better than single-step automation — it's necessary only when the process genuinely requires an intermediate decision based on information that only appears during execution. Typical cases:
- Document due diligence — the agent reads a contract, identifies an ambiguous clause, decides whether it needs to check a related document before classifying the risk, and only then produces the opinion.
- Technical incident triage — the agent checks logs, identifies a pattern, decides whether the pattern warrants checking similar incident history, and only then recommends action.
- Pricing with multiple dependent variables — the agent checks availability, decides whether the scenario requires checking a contractual exception, and only then calculates the final price.
In all three, step 2 couldn't be written as a fixed rule before step 1 runs — because what's relevant in step 2 depends on what step 1 found.
The risk nobody talks about: cascading failure
The most recurring problem in production isn't the agent getting one isolated decision wrong. It's a wrong decision in step 2 becoming the silent premise of step 4, with nothing flagging the inconsistency along the way.
Single-step automation fails visibly: the output is wrong, someone notices, it gets corrected. A multi-step agent can fail invisibly: each individual step looks reasonable, but the whole chain converges on a conclusion no single step would have produced on its own. That requires a kind of governance most projects don't implement: logging every intermediate decision, not just the final result — because it's the only way to audit where the chain diverged from what was expected.
Without that log, debugging a multi-step agent that went wrong is like investigating an accident with no black box: only the outcome exists, not the path that led to it.
When multi-step is over-engineering
Most cases that come in asking for an "AI agent" don't need multi-step — they need well-scoped single-step automation, and adding autonomous planning only introduces risk without benefit. Signs that a case doesn't warrant multi-step:
- The process has at most two decision variables, both known in advance — in that case, a deterministic conditional solves it with far less risk.
- Exceptions are rare and cataloguable — if the exception cases can be listed in advance, single-step automation with human escalation on the listed cases is cheaper and more auditable.
- Nobody is going to review the intermediate decision log — if the operation has no process to audit the path, not just the outcome, multi-step is adding complexity nobody is actually going to govern.
In those cases, RPA or single-step automation remain the right choice — multi-step exists to solve a specific problem, not to look more sophisticated.
Decision framework
Before scoping an agent as multi-step, answer:
- Can step 2 be written as a fixed rule before step 1 runs? If yes, it's not multi-step — it's a conditional with an LLM in the middle.
- How many intermediate steps are there, and will each be logged individually? Without per-step logging, there's no way to audit where a chain diverged.
- Who reviews the decision chain when the final result is questioned? If the answer is "nobody, we just look at the outcome", governance isn't ready for multi-step yet.
- Is the cost of a wrong decision in step 2 recoverable by step 4? If an early error is catastrophic and there's no review checkpoint along the way, the design needs a human validation point before the final step.
If the answers point to a genuine need for decisions conditioned on emergent context — not just to "look more advanced" — multi-step is the right architecture. Otherwise, simpler automation delivers the same result with far less failure surface.
Sparsum in practice
In a contract triage project for a services operation, the client's initial request was a full multi-step agent with five decision steps. After mapping the real process, it became clear that three of the five steps had exactly two possible outcomes, always the same ones — they didn't need emergent decisions, they needed a conditional. The final design used genuine multi-step in only two steps — exactly where the next action depended on a clause only identified during the contract read — and deterministic automation for the rest. The result processed faster, cost less per execution, and was auditable at every step, because the fixed steps never needed decision logging: their behaviour was already known.
In another case, an industrial operation used RPA to reconcile maintenance data across three systems that didn't talk to each other natively. The RPA broke every time one of the systems changed a screen layout. The agent that replaced this flow genuinely needed multi-step: every reconciliation required deciding, based on what the three systems returned, which was the source of truth for that specific record — a decision that changed case by case and couldn't be pre-coded.
In both cases, the criterion that decided the architecture wasn't "how sophisticated should the agent look" — it was where emergent decision genuinely existed, and where it was just a disguised conditional.