Comparisons
Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.
Deterministic workflow vs agent
The plan for an assistant over company documentation starts with a multi-agent framework because that is what the demos show, and the single question — why is one deterministic workflow insufficient? — is never asked. The cost is a system whose behaviour cannot be predicted, tested or explained, solving a problem that a retrieval step and one model call would have solved observably. The strongest form of the agent side is real: some tasks are open-ended, and a fixed sequence fails on them in ways that show up in an evaluation; the honest position is that the evaluation has to exist first, and the agent is the answer to a failure it shows, not to a demo.
When the sequence is known: retrieve the relevant documents, call the model once, return the answer with sources. Most "AI assistant" requests are this.
When the sequence genuinely cannot be known in advance — the task branches on findings, tools must be chosen per case — and a measured failure of the single workflow says so.
| Aspect | Deterministic workflow — steps known in advance, possibly with a model call inside one of them | Agent — the next step chosen at run time from what the last step found |
|---|---|---|
| Steps | Fixed, known before the request | Chosen during the request |
| Testable | Yes — same input, same path | Only statistically, against an evaluation set |
| Explainable failure | Which step returned what | Which choice at which turn, if logged |
| First version of a docs assistant | Retrieve, call once, cite | Rarely |
| Justified by | The task being a sequence | A measured failure of the sequence |
| Sign of the mistake | A hard-coded flow that branches on twenty flags | A framework chosen before the evaluation exists |