Agents, workflows, and one-shot calls

A one-shot model call sends a prompt and available context to a model, then receives one response. The response might summarize a document, classify a support ticket, extract fields, or draft an email. The surrounding application may validate the result, but the model does not observe that validation and choose another action inside the same task.

This pattern is often the right starting point. It has one major model decision, so its latency, cost, and failure surface are easier to estimate. If the input contains everything needed and the desired output has a stable format, adding an action loop may create complexity without adding capability.

Consider invoice extraction. If every invoice arrives as text and the requirement is “return supplier, date, total, and currency as JSON,” one structured call plus schema validation can be enough. Calling that extractor an agent does not improve it. It only blurs the design.

A workflow coordinates multiple steps whose order and branches are primarily written by a developer or process designer. It may include several model calls. For example:

1. classify the request;
2. retrieve matching policy documents;
3. draft an answer;
4. run a policy checker;
5. route failures to a reviewer.

The workflow can contain if statements, retries, queues, and human approval. It can be highly capable without being agentic. Given the same intermediate state, its orchestration code normally chooses the same next step.

Fixed workflows are valuable because known business rules stay visible. A refund process should not improvise whether to check the transaction before issuing money. The order belongs in code. A model can interpret a customer message inside that process while deterministic logic controls the consequential path.

An agent adds a loop in which a model or policy chooses among allowed next actions based on current, observable state. The state can include the goal, messages, tool results, errors, remaining budget, and completed subgoals. The action might be “search the catalog,” “open result 3,” “ask the user a clarifying question,” or “finish with a cited comparison.”

That flexibility helps when the useful path depends on what is discovered. A research task may need two searches or six. A debugging task may inspect a log, revise a hypothesis, and choose a different diagnostic. The developer defines the action space and limits; the loop selects a route through it.

This definition does not claim that software has intentions, beliefs, or human-like agency. “Goal” is a specification supplied to a system. “Decision” is an observable selection among actions. You can evaluate the input state, chosen action, tool result, and stop reason without exposing private model reasoning or requesting a hidden chain of thought.

Real systems sit on a spectrum. A workflow may have one agentic research step. An agent may execute a deterministic checkout workflow after gathering options. A router may choose between fixed pipelines but never run a long loop.

Use architectural descriptions that reveal control:

• “One model call extracts fields, then code validates the schema.”
• “A fixed four-step workflow drafts and reviews the message.”
• “A bounded agent can choose search or document-open actions for at most eight steps.”

These statements are more useful than “AI-powered agent.” They tell reviewers where variability enters and where controls belong.

Start with the simplest architecture that can meet the requirement. Prefer a one-shot call when the context is complete and one transformation is enough. Prefer a workflow when the correct sequence is known. Consider an agent when the route cannot be enumerated economically because each observation changes what should happen next.

The choice changes operations. An agent can make different numbers of calls, encounter untrusted tool content, repeat ineffective actions, and stop without satisfying the goal. It therefore needs step budgets, traces, success checks, and recovery behavior. Those are not optional decorations; they are part of the architecture.

A common failure is to use an agent for a deterministic task because the label sounds advanced. Imagine a payroll process that asks a model to decide whether to calculate tax, validate bank details, or submit payment next. Flexibility here is harmful. The required order is known, and skipping a check has consequences. A workflow should control it.