Text in, text out. Cheap, fast, predictable, easy to test. Use it when the answer is already in the model — writing, summarising, explaining, rewriting.

Whether you can write down the steps before running anything. If step 2 is the same regardless of what step 1 returned, the path is fixed and a workflow will do it cheaper, faster, and testably. You need an agent only when the next action genuinely depends on a result you cannot predict — like deciding which regions to investigate based on which ones showed a decline.

Because it means there is always a checkpoint between intention and action, and that checkpoint is code you control. The model emits a structured request; your code decides whether the tool is allowed, whether the arguments are sane, and whether a human should approve first. Every guardrail in agent safety lives at that boundary. If you wire model output directly into an action, you have removed the only place you could have stopped it.

Because agents are not deterministic — the same input can take a different path on the next run. A passing test shows that one path worked once, not that the system works. Real confidence comes from running each case many times and looking at the spread of outcomes, costs, and step counts. A single green run mostly tells you the happy path exists.

Every added agent multiplies cost and latency, and introduces failure modes that did not exist before: agents contradicting each other, context lost in handoffs, and a coordinator that becomes a single point of failure. Debugging also gets much harder, because a wrong result now has five possible origins plus the joins between them. Extra agents should follow a measured failure of the simpler design, not precede it.