Multi-Step Tool Flows (and When You Need an Agent)
Chain a few tool calls into a reliable feature, cap the steps, and recognize the point where you've crossed into agent territory.
Real features rarely finish in one tool call. Resolving a Deskmate refund request means finding out what the customer wants, looking up the order, checking the refund policy, deciding, and drafting a reply. Diagnosing why a customer's integration stopped syncing means checking its status, then its error log, then maybe its credentials, depending on what each check reveals. Each of those is a multi-step tool flow: several model calls and tool calls chained into one feature.
The design question is who decides the order of the steps. Your code can decide, the model can decide, or you can split the work between them. That choice determines how predictable, debuggable, and expensive the feature is. In this lesson you'll build both kinds, put real budgets on the model-driven one, and learn to recognize the point where a "flow" has become an agent and needs a different kind of engineering.
Who decides the next step?
There are three ways to chain steps, and they sit on a spectrum from most predictable to most flexible:
| Pattern | Who picks the next step | Best for | Watch out for |
|---|---|---|---|
| Code-orchestrated pipeline | Your code, in a fixed order | Processes you can draw as a flowchart | Rigid when cases vary a lot |
| Model-driven loop | The model, by calling tools | Paths that depend on what earlier steps reveal | Variable cost, harder to test |
| Hybrid | Code fixes the stages; the model loops inside a stage | Most real features | More moving parts |
The default should be the first. If you can write down the steps before the request arrives, put them in code. Your code never forgets a step, never calls the same tool five times, and produces the same sequence every time, which makes it testable with ordinary tests. Reach for model-driven control only for the part of the flow where the path genuinely can't be known in advance.
A useful exercise before building: try to draw the flow as a flowchart. If every box and arrow is clear, it's a pipeline. If one box says "investigate until you know," that box is where the model drives.