One call, workflow, or agent?

An architecture should begin with the work in front of it. If a request has a clear input, a bounded output, and an outcome your team can verify, a single augmented model call may be sufficient. The application sends the request, the model completes that one job, and conventional software handles the wiring around it. Tools, retrieval, and more reasoning can still support the call; none of them automatically turn it into an agent.

If the task contains several stages that can be determined ahead of time, it has a workflow shape. Your code can name the stages, pass information between them, record what happened, and insert checks at the places they matter. A model may interpret language, classify material, or draft an output inside a stage. The sequence remains inspectable because the system, rather than the model, owns it.

An agent is different. It receives a goal and a constrained set of tools, then decides which tools to use and in what order. The sequence is not authored in advance as a list of programmatic steps. This gives the system a real advantage when the next useful action depends on what the previous action found. It also means that the trajectory itself is a source of uncertainty.

The three patterns sit on a spectrum. At one end, the model has low autonomy and the path is highly predictable. At the other, the model owns a less predictable path through the work. The middle is not a compromise for its own sake. It is where many production tasks belong: predictable overall, with bounded areas where language judgment is useful.

Consider a hypothetical request-handling service. A single, well-formed request that only needs a verified classification may be a bounded call. If every request must first be classified, then sent through one of several known paths, then receive a drafted response, the shape is a workflow. If the task is an open investigation where the next source to inspect depends on evidence discovered during the investigation, an agent may be justified.

The point of that illustration is not to make every service process look the same. It is to show the question that separates the patterns: can the route be stated before the work starts? When the answer is yes, putting that route in code gives the team a cleaner structure than asking a model to rediscover it for every run.

Predictability is the first filter. Ask whether the necessary steps can be enumerated before the system runs. If they can, an agent has not earned the autonomy it adds. That one answer does not always select the final pattern, but it can eliminate the heaviest one before a team spends time rationalising it.

Next, assess the cost of a wrong result. A retry has a different consequence from an audit finding or an irreversible action. A workflow makes it possible to position deterministic checks between its stages; an agent exposes the full sequence of model choices across several turns. A one-call design is simple to operate, but it offers no stage-level guard once the request has been sent.

Then ask whether the operations team can reconstruct what happened. Workflows produce named steps that can be logged and inspected using familiar software practices. A single call is easy to record, yet the interpretation within it remains opaque. An agent produces a trace of its trajectory, which can be harder to turn into an operational alert or a clear explanation of why a particular action occurred.

Latency and cost complete the decision. One bounded call is usually the fastest and uses the fewest tokens. A workflow adds predictable time and expense as stages are added. An agent's duration and token use can grow with iteration, tool use, retries, and the context it accumulates. That does not mean every agent costs more than every workflow; design and boundaries matter more than the label. It does mean an open-ended pattern must be budgeted for the cases that run long, not only the typical run.

Choosing a workflow still leaves an architectural decision. The relationship between its steps should match the work, rather than being an accidental sequence of model calls. Four recurring shapes make that relationship explicit.

Chaining fits work with clean handoffs: one stage produces a defined output for the next. Routing fits inputs that require different known treatments: a classifier selects the appropriate path. Parallelization fits independent units that can be examined at the same time and then combined. Evaluator-optimizer fits work where quality can be checked against a criterion but one first attempt is not dependable enough; a separate evaluation requests revision until the condition is met or a retry limit is reached.

These shapes can be combined. A process may route an incoming item, chain a few dependent steps along one path, and parallelize independent checks within a stage. The combination does not make the system an agent if the overall design remains known and orchestrated. It is still a workflow because the control path lives in the system's code.

That distinction becomes valuable after launch. If operating evidence shows that a simpler workflow no longer handles a genuinely open-ended part of the task, the team has a clear reason to escalate the pattern. Autonomy then follows measured need, rather than an assumption about what an AI system ought to look like.

Before choosing the architecture, ask:

1. Can we write the steps and decision paths before this task runs?
2. Which exact part needs language interpretation or model judgment?
3. What does a wrong result cost, and where should a guard sit before that cost is incurred?
4. Can an operator reconstruct the route, the action, and the reason for an exception?
5. What is the deadline visible to the person waiting for the result?
6. What is the worst credible cost of the run at expected volume, not just its usual cost?
7. If the model chooses the next action, which tools, permissions, budgets, and stopping conditions constrain it?

If the path is known, start by expressing it as a call or a workflow. If the path is genuinely unknowable until the work unfolds, make the autonomy explicit and bound it. Constrained tool entry points, permissions, per-turn budgets, and stopping conditions are part of an agent architecture, not finishing touches added after it behaves unexpectedly.

Pattern selection is not a maturity ladder. A single augmented call is not a failed agent, and a workflow is not a temporary substitute for one. Each is a way of allocating control between the model and the surrounding system.

Start with the known shape, the error tolerance, and the evidence your operation must produce. Use an agent for the work that truly requires an adaptive trajectory. For everything else, retain the simplest structure that makes the process visible, testable, and accountable.