Choosing Between Workflows and Agents

Agent has become one of the most overloaded terms in AI. Product teams apply it to everything from a retrieval-backed chat interface to a long-running process that can plan, call tools, and take actions on its own. When one word covers all of those designs, design reviews turn into arguments about labels, even though the real design question is architectural.

For engineers and technical decision-makers, the useful question is not whether a system "is an agent" but who controls the next step. Some systems fix every transition in code. Others let the model choose among tools, decide what information to gather next, and determine when to stop or escalate. Those control patterns carry different reliability, latency, cost, and risk profiles.

The common assistant-versus-agent binary squeezes several distinct design decisions into one marketing label. A better framing separates the user-facing assistant interaction pattern from internal workflow or agent control (the two can coexist in one application), then evaluates control locus and authority across independent dimensions. This post covers those boundaries. Runtime loop mechanics, retries, and tool recovery come in Post 06, after the prerequisites the reading route places before it.

The optional memory lesson separates conversation memory, task state, working memory, and durable knowledge. Use those working categories to record each item's authority, lifetime, and owner. Collapsing them can hide what the runtime may read, write, or cite as evidence, which makes control decisions harder to assess.

What This Post Is Not

This post does not cover runtime loop mechanics, tool contracts, or failure recovery; those belong to Post 06. It is not a governance or auditability post either: Post 10 extends the architecture example with approval gates and inspectable traces. It is an instructional design, not a production certification standard. Its job is the conceptual framing: how control locus, authority, consequence, reversibility, and time horizon shape the design, and where approval boundaries belong.

Why Agent Terminology Gets Confusing

Part of the confusion comes from mixing product metaphors with systems terminology. Assistant is often a user-facing metaphor for software that helps someone complete a task, usually through conversation. It can describe very different architectures: a single-turn chat application, a retrieval-backed question-answering system, a deterministic workflow wrapped in a chat UI, or a bounded agent that plans multiple steps before responding.

Agent, by contrast, gets used as if it named one crisp technical architecture, even though teams apply it to four overlapping ideas:

• any system that invokes tools

• any system that spans multiple steps

• any system that triggers work proactively

• any system where a model helps steer the execution path rather than only drafting final text

Those definitions overlap without being identical. A system can call a tool without being meaningfully agentic, run many steps without choosing any of them itself, or act proactively while code still constrains it tightly. Loose terminology produces loose design reviews.

Stop treating assistant and agent as mutually exclusive product categories. Treat them as shorthand for five deeper control questions:

• Is the execution path predetermined in code or steered at runtime by a model?

• May the model select the next operation, or only populate a bounded stage?

• Which tools are exposed to it?

• Which state stores may it read or mutate?

• Where must a human approve, intervene, or halt execution?

Those questions are much more stable than the labels.

Assistants, Workflows, and Agents as Architectural Patterns

Define these patterns by control logic rather than conversational personality, and the system boundaries stay crisp.

Assistant

An assistant is best understood as an interaction pattern rather than a strict system class: software that helps a person accomplish a task, often through natural language, and that can be built with very different levels of autonomy.

Behind the same interface, an assistant might run:

• a single model call that drafts a reply

• a retrieval pipeline that cites internal documents

• a deterministic workflow executing a fixed stage graph

• a bounded agent that gathers evidence and proposes actions behind an approval gate

Saying you are building an assistant specifies the user experience while leaving the backend control architecture open.

Workflow

A workflow executes a predefined stage sequence. Control logic lives primarily in application code, which invokes models inside bounded steps (classifying, summarizing, extracting, ranking, or drafting) while the order of operations stays largely fixed in advance.

Typical workflows:

• retrieve documents, extract relevant tables, normalize units, then synthesize a summary

• classify a request, route it to one of three approved flows, then generate a response

• ingest a PDF, run layout extraction, validate required fields, then write structured output

Workflows are often the right default because fixed paths are easier to test, reason about, and constrain. Their weakness is flexibility: when a task is irregular or the right step order depends heavily on what the system discovers along the way, hardcoded branch trees can become brittle or expensive to maintain.

Agent

An agent is a system in which the model has meaningful control over part of the execution path. Within defined limits, that usually means the model can choose which action to take next, which tool to call, what additional information to gather, whether to revise its plan, and when to stop or escalate.

That delegation requires neither open-ended autonomy nor human-level judgment, and it does not free the system to do anything it wants. In production, useful agents are usually bounded systems:

• scoped to a defined task

• limited to an allowlist of approved tools

• governed by explicit, application-enforced policies

• stopped at approval gates before high-impact actions

• terminated by fixed stop conditions such as step, time, or cost budgets

A system becomes more agentic as more of its control logic moves from deterministic code to model-driven decisions, not because it seems more intelligent.

A More Useful Distinction: Fixed Process vs Model-Directed Process

Asking who selects the next step separates three operating modes that are often blurred together.

In a fixed workflow, application code picks every transition while models execute bounded subtasks.

In an assistive system, the user may remain the primary driver: the system helps with retrieval, drafting, and analysis, but the user chooses each next move.

In an agentic system, the model directs at least part of the process: it may retrieve more evidence, call a parser, cross-check conflicting records, ask a clarifying question, or stop because confidence is too low or approval is required.

Reliability changes once the model controls the process rather than only the output. Errors can compound across steps: a poor retrieval choice can poison later synthesis, an unnecessary tool call adds latency and cost, and a missing stop condition can turn a useful loop into a runaway one.

The architectural shift is real, but describe it precisely: delegating process choices relocates control; it does not create a new kind of intelligence.

Use a Multidimensional Decision Matrix

Compressing autonomy into a single ladder creates its own blind spots. A month-long fare monitor may carry little authority, while a one-step non-refundable purchase can create an immediate financial commitment. Read access can still expose confidential data, and a purchase's reversibility depends on its actual terms. Duration is not an authority score.

1. Control Locus

Specify whether application code, the human user, or a model selects the next step. A routed workflow may call a model classifier while code still enumerates every allowed branch, whereas a bounded agent delegates some process choices to the model. Anthropic's workflow-versus-agent framing offers practical shared vocabulary rather than a formal industry standard (Anthropic, 2024).

2. Authority

List what the system may read, recommend, write, or commit. Tool availability is not enough: the authenticated principal, delegation, and target resource policy must authorize the exact operation.

3. Consequence

Classify the effect if the system is wrong: informational, internal operational, externally visible, financial, safety-related, or regulated. The same control pattern can carry very different risk in different domains.

4. Reversibility

Distinguish read-only queries, easily reverted edits, actions compensatable at a cost, and effectively irreversible commitments. Updating a versioned internal draft and charging a non-refundable payment should not share the same approval design.

5. Time Horizon

Note whether the task is one-shot, multi-step, resumable, scheduled, or long-running. Longer horizons increase state, drift, and monitoring needs, but duration does not by itself grant more authority.

Choose an architecture only after mapping all five dimensions. This matrix is this tutorial's design aid, not a validated numerical risk score. The goal is not to maximize autonomy but to delegate only the process flexibility the task needs while keeping authority and consequence bounded.

Approval Boundaries Matter More Than Branding

Once you separate control locus from authority and consequence, the next design question is where to place approval boundaries. That is where many "agent" discussions become concrete.

This post uses approval boundary as the broad design term: it marks where the system may prepare an output but may not advance on its own. An approval gate is the concrete runtime checkpoint that enforces that boundary inside a workflow.

Any system with model-directed behavior should have clear answers to four questions:

• What may the model decide on its own?

• Which tools may it call?

• What state may it read or modify?

• Which actions require explicit human approval before execution?

Those answers are core parts of the architecture, not documentation details.

Authorization and approval are different controls. Authorization determines whether an authenticated principal may perform an action on a resource. Approval records a human decision inside that already-authorized boundary; it cannot add a permission that the user, workload identity, or resource policy lacks. A February 2026 NIST NCCoE concept paper poses separate questions about identification, authentication, authorization, delegation, and audit logging for AI agents, and asks how to bind agent identity to human identity to support human-in-the-loop authorizations. It is a draft concept paper, not a final standard (NIST NCCoE, 2026).

Contrast two travel-copilot policies:

• the model may draft a hotel booking recommendation

• the model may confirm and pay for the hotel booking

The first is a bounded analysis task. The second crosses into operational control and carries a much higher consequence if the system is wrong. That difference should not hide behind the same agent label.

Approval gates matter most as implementation points when the system can:

• write to durable records

• contact customers or external partners

• trigger code changes in production

• spend money or commit inventory

• launch physical processes

• change system or security configuration

Decide review requirements from the action's consequence, the principal's permissions, organizational policy, and the cost of error. A durable internal draft update does not automatically need the same approval as a payment. Human review is one control and can itself fail, so it supplements authorization and validation rather than replacing them.

Design review to avoid approval fatigue. Show reviewers the plan, the supporting evidence, the exact resource or fields that will change, the expected consequence, the approval expiry, and the rollback or compensation path. Low-risk repeated reads can run under standing authorization; irreversible or externally visible actions should stay bound to a specific, fresh decision. Anthropic describes shifting oversight toward reviewing a plan, while keeping the ability to intervene during execution, as one practical pattern (Anthropic, 2026).

Stop conditions matter too, but only the concept is needed here: once the model controls part of the process, the system must know when to stop, escalate, or wait at an approval boundary. Post 06 covers the operational details of retries, stops, and escalation paths.

Worked Example: An OptiVerse Travel Copilot With Approval Gates

Return to the fictional OptiVerse Travel copilot used throughout this series. The contracts, properties, and comparisons below are teaching fixtures, not claims about real suppliers. A travel consultant asks:

Prepare the Kyoto hotel segment for trip JPN-2026-0417: find accessible rooms during cherry blossom season within the client's budget, and recommend whether Contract KYO-H12 is the best option.

That request can be implemented in several ways.

Version 1: Assistive

The system retrieves partner hotel contracts, accessibility specification sheets, seasonal rate tables, and past client reviews for Kyoto properties, then surfaces three candidate hotels with pricing and accessibility details. The consultant decides each follow-up: narrow the search by price, inspect a specific hotel's accessibility record, or request a recommendation.

This is assistive: the system helps substantially, but the human controls each step.

Version 2: Workflow

The system runs a fixed five-step path:

1. search partner hotels for accessible rooms in Kyoto on the requested dates

2. filter candidates against mandatory wheelchair-accessibility criteria

3. extract seasonal rates and normalize amounts to USD

4. first enforce required accessibility features from suitable evidence, then rank qualifying options by stated preferences and budget; do not let a blended rating compensate for a missing required feature

5. render a structured comparison sheet for consultant review

This is a workflow because the sequence is predetermined. It can be reliable and efficient when the task shape is stable. If availability has changed or a hotel's accessibility claims conflict with its actual facilities, the workflow can still refresh inventory, branch on conflicts, or escalate through explicitly designed rules. Adaptive behavior alone does not prove that model-directed control is necessary.

Version 3: Bounded Agent

The system receives the same goal, but now it can decide part of the process for itself. It might:

• start with retrieval across partner contracts, availability feeds, and accessibility records

• notice that one hotel's contract lists a roll-in shower while its accessibility specification sheet describes only a tub with grab bars

• verify rail coverage from a current authoritative source that carries an effective date, applicable sales channel, and source ID

• call a rate-extraction tool on Contract KYO-H12 to pull the seasonal pricing appendix

• compare those rates against two alternative partner properties

• flag the discrepancy between the two records, then check that they concern the same room type and effective period; neither document alone establishes current physical conditions

• ask the consultant for approval before widening the search to non-partner hotels

• produce a cited recommendation that clearly flags the unresolved accessibility conflict

This is more agentic because the model can choose what to do next within a constrained task. But the boundaries remain firm:

• it may gather evidence across authorized contracts and availability feeds

• it may draft comparisons and the recommendation

• it may suggest booking a specific hotel

• it may not confirm any booking

• it may not modify the client's trip file or itinerary

• it may not authorize any payment or deposit

The verbs describe, recommend, and act are useful shorthand for discussing capabilities, but they do not form a complete governance ladder. Each concrete operation still needs the five-dimensional assessment, especially because a recommendation can influence a consequential user decision.

That is bounded autonomy in practice: the system is useful because it has some discretion, not because it has unlimited authority.

Hands-On Exercise

Complete this matrix for five actions: read a partner contract, draft an itinerary, update a trip draft, place a hotel hold, and charge a payment method.

For each action, record the user interaction pattern separately from internal workflow or bounded agent control, then name the application-side authorization check and any approval boundary. Justify each design with all five dimensions.

Deliberately Broken Case

Compare two systems:

• System A is a month-long monitor that reads public fare pages and writes internal alerts. It cannot book or pay, but because it writes alerts, it is not entirely read-only.

• System B performs one model-selected, non-refundable purchase using a stored payment method.

A scalar autonomy ladder may rank System A "above" System B because it runs longer. The multidimensional matrix shows the opposite operational concern: System B has greater authority, consequence, and irreversibility. Repair System B by keeping payment outside the model-selected action set, enforcing authorization in application code, and requiring a fresh human approval bound to the exact amount and purchase.

When Not to Use an Agent

Recognizing when agentic control is unnecessary is one of the most important design decisions.

When the task sequence is known, repeatable, and easy to validate in code, a deterministic workflow is usually the better choice.

When errors are high-impact and flexible planning adds little, a deterministic process with explicit checks often wins in compliance, finance, safety, or production operations.

Do not hand control to a model when the available tools are weak, underspecified, or hard to observe. Giving a model control over poor tools does not create useful autonomy; it creates opaque failure.

Hold off on model-directed control until your team can evaluate multi-step behavior. Once a model directs the process, single-turn prompt evaluation is not enough: you need step-level tracing, tool-call inspection, and tests for termination and escalation behavior.

Do not add autonomous planning just because the interface is conversational. A chat box does not imply that the underlying system should plan or act autonomously, and many excellent products should stay mostly deterministic behind a natural-language surface.

In practice, teams often reach for agents too early because the label sounds advanced. The better progression is usually the reverse:

1. start with an explicit workflow

2. measure where fixed branching hurts real tasks

3. add bounded model-directed decision points only where they earn their complexity

That progression tends to produce systems that are easier to ship and easier to trust.

Common Misconceptions

Five common misconceptions often distort architecture reviews.

Any system with a tool is an agent. Tool use alone is not enough. A workflow can call tools in a fixed sequence without giving the model meaningful control over the process.

Agent means fully autonomous. Many useful agents are tightly bounded by tool allowlists and step budgets, and they require approval for the most important actions.

Assistant means simple chatbot. An assistant can sit on top of anything from a single model call to a complex orchestration layer.

More autonomy means more intelligence. It means more delegated control. Whether that improves outcomes depends on task structure, tool quality, and control design.

If the model can plan, humans should leave the loop. In high-consequence systems, that is often exactly the wrong conclusion: planning ability does not remove the need for approval boundaries.

The Real Design Question

Requests to "build an agent" usually boil down to one of three concrete needs:

• handling irregular multi-step tasks whose step order depends on intermediate findings

• selecting tools or evidence sources dynamically per request

• reducing manual step-by-step driving by the human operator

Those are legitimate goals, but translate each one into an architectural decision about control placement, permissions, and stopping rules. The most useful question in design review remains the simplest one:

Who controls the next step?

Answer it at each decision point rather than once for the whole product. A user can start an assistant interaction that runs a code-defined workflow, which can in turn contain a bounded model-directed investigation. A model classifier inside a fixed route set does not by itself make the whole system an agent. Describe each delegated process decision explicitly.

That framing is more useful than arguing over whether a product deserves the agent label.

Exit Criteria

Your matrix is complete only if:

• all five actions are classified across all five dimensions;

• duration is never used as a substitute for authority or consequence;

• every write or commit action names an application-side authorization check;

• approval cannot expand a missing permission;

• high-consequence review shows plan, evidence, exact change, expiry, and recovery or irreversible effects;

• the recommended pattern is simpler than an agent whenever a fixed workflow meets the task.

Knowledge Check

Answer without looking back.

1. Why is autonomy not one scalar ladder?

2. What is the difference between authorization and approval?

3. Which dimensions distinguish a draft update from a non-refundable payment?

4. Why can a long-running monitor still be lower risk than a one-step action?

Answer Key

1. Control locus, authority, consequence, reversibility, and time horizon vary independently across actions.

2. Authorization determines whether a principal is permitted to perform an operation on a resource; approval records a human decision inside that existing permission boundary.

3. Consequence and reversibility, paired with commit authority.

4. In the fixture, the monitor only reads public fares and writes internal alerts, while the purchase commits money that cannot be refunded. The comparison depends on those permissions and consequences, not on duration, although the monitor can still mislead users or create excessive alerts.

One defensible exercise solution follows. Its approval rules are chosen product policies, not universal requirements:

A bounded agent may gather evidence before any of these operations, but its discretion to investigate does not expand the executor's permissions. After an approval delay, recheck authorization and proposal validity at execution time.

Bridge to Agent Loops in Practice

Once you decide that a task needs bounded model-directed control, the next problem is operational: how should that loop actually run?

Before Agent Loops in Practice, complete its identity and authorization prerequisite. That post moves from architectural boundaries to runtime mechanics: reason-act-observe loops, tool-call validation, planner-executor splits, tool failure recovery, and the stop budgets that keep a bounded agent useful instead of erratic. The goal is not to make systems look more autonomous. It is to make multi-step tool use legible, testable, and safe enough to deploy.

Sources and Further Reading

This post draws on the following primary and practitioner sources:

• Anthropic. "Building effective agents." Practitioner reference for distinguishing workflows from agents, starting with simple patterns, and using bounded autonomy. anthropic.com/research/building-effective-agents

• BAIR. "The Shift from Models to Compound AI Systems." Reference for control logic in code versus control logic delegated to the model. bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• Schick, T., Dwivedi-Yu, J., Dessì, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." Reference for model-directed tool selection as a capability. arxiv.org/abs/2302.04761

• Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." Reference for reason-act-observe loops, used here as background for Post 06. arxiv.org/abs/2210.03629

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." Reference for oversight, guardrails, and generative AI risk framing. nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

• National Institute of Standards and Technology, National Cybersecurity Center of Excellence. "Accelerating the Adoption of Software and AI Agent Identity and Authorization." Draft concept paper, February 2026. Questions on identification, authentication, authorization, delegation, audit logging, and human-in-the-loop authorization. nist.gov agent identity concept paper

• Anthropic. "Trustworthy agents in practice." April 2026. First-party discussion of meaningful human control, plan review, intervention, and prompt-injection risk. anthropic.com/research/trustworthy-agents