6 min read
A linear chain works perfectly in a demo and breaks the first time a real user does something unexpected. Modeling an agent as a directed graph instead of a pipeline is what lets it branch, retry, and recover instead of just failing, and the difference is usually invisible until the day it matters most.
A linear chain works perfectly in a demo and breaks the first time a real user does something unexpected. Modeling an agent as a directed graph instead of a pipeline is what lets it branch, retry, and recover instead of just failing, and the difference is usually invisible until the day it matters most.
Why Linear Chains Break
A chain assumes step two always follows step one. In practice, a lookup comes back empty, a tool call times out, or a user answer contradicts an earlier assumption. A linear pipeline has no vocabulary for any of that. It either presses forward with bad data or fails the whole run, and the only fix available to most teams is bolting on more prompt instructions to cover cases the architecture was never built to handle.
We have seen this play out the same way on more than one build: a demo works flawlessly against the five happy-path examples the team tested, then falls over in week one of production against a case nobody scripted for. The instinct is to add another prompt instruction covering that one case. Repeat that pattern for a few months and you have a fragile wall of special cases instead of an architecture that was ever designed to branch.
What a Missing Branch Actually Costs
The cost of this is not abstract. Every unhandled branch either surfaces as a bad answer a customer sees, or as a support ticket for an internal user who has to manually finish what the agent could not. Both are expensive, and both are avoidable with a small amount of upfront design work on what happens when a step does not go as expected.
Graphs as the Fix
A state machine gives the agent real options: nodes represent states or actions, edges represent transitions guarded by conditions, and a failed edge can route back to an earlier node instead of dead-ending. This is the same model Agentforce topics and actions already lean on, and AgentScript makes the transitions explicit rather than implied by prompt wording. Retries, fallbacks, and conditional branches become structure instead of hope.
Designing the Edges, Not Just the Nodes
Teams new to this model tend to spend all their design time on the nodes, the individual actions, and very little on the edges, the conditions that decide what happens next. In our experience the edges are where the actual reliability work lives. For every action, ask explicitly: what does success look like, what does a recoverable failure look like, and what does an unrecoverable failure look like that should escalate to a human. Answering that for every node, before you build it, is what turns a diagram into a system that survives contact with real users.
Conclusion
Treat your agent's control flow as a graph from day one, even a simple one. It costs a little more design work up front and saves months of patching a pipeline that was never meant to branch.
Start small: even a graph with three nodes and one conditional retry edge is a meaningfully different architecture than a straight line with no way back. You do not need the full topology on day one. You need the habit of asking what happens when a step fails, before it fails in production instead of in your design review.