Workflows, Agents, and the Autonomy Spectrum

“Workflow,” “agent,” and “autonomy” are often arranged into a story of progress: begin with a model call, graduate to a workflow, add tools and memory, then arrive at a fully autonomous multi-agent system. That story is attractive and usually wrong.

These terms answer different engineering questions. A workflow describes how execution is organized. An agent describes where some runtime control resides. Autonomy describes how much discretion is exercised without contemporaneous human control. Tools, duration, and agent count change what a system can do, but none of them alone settles which control structure it uses or how much autonomy it should have.

The distinction matters because control labels become operating assumptions. If a model router is treated as a harmless classifier, its ability to send work into a consequential branch may be missed. If a fixed nightly pipeline is called autonomous merely because no person watches it, the team may confuse unattended automation with model discretion. If every tool-using system is called an agent, architecture reviews lose the language needed to locate actual decisions.

This chapter offers a practical boundary and a four-part delegation profile. Neither is an industry standard. They are Fieldbook tools for exposing who decides, what may change, how long delegation persists, and where people retain meaningful control.

Thesis

A workflow and an agent differ primarily in the locus and openness of runtime control. In a workflow, application code defines the admissible paths and invokes models for bounded operations or choices. In an agent, a model constructs or revises a course of action at runtime from a goal, current state, available tools, and feedback. Autonomy is a separate design variable: the discretion that system may exercise without contemporaneous human direction or approval.

Three consequences follow:

1. Model use does not imply model control. A model can classify, extract, draft, score, or route inside a predefined state machine without controlling the task as a whole.
2. Automation does not imply autonomy. A fixed process may run unattended while exercising no open-ended judgment about its course of action.
3. More autonomy is not more maturity. The right level is the least delegation that captures the required value while keeping consequences observable, bounded, and recoverable.

Anthropic draws a similar architectural boundary: workflows orchestrate models and tools through predefined code paths, whereas agents dynamically direct their process and tool use. It also recommends starting with the simplest structure that works because agentic flexibility trades against latency, cost, and predictability (Anthropic, 2024). OpenAI likewise treats model management of workflow execution and dynamic tool selection as defining characteristics of agents, while recommending deterministic solutions when they are sufficient (OpenAI, “A practical guide to building agents”).

Problem

The boundary is harder than “fixed equals workflow, dynamic equals agent.” Useful workflows already contain model decisions:

• a router selects one of several specialist paths;
• an evaluator decides whether an artifact needs another revision;
• an orchestrator decomposes an input into subtasks;
• a model chooses a query for retrieval; and
• a classifier determines whether a case should be escalated.

Conversely, an agent is always surrounded by deterministic machinery. Code supplies tools, permissions, budgets, schemas, stopping limits, storage, and the outer run loop. No production system hands literally all control to a model.

The useful question is therefore not whether code or a model makes any decision. It is:

Does code enumerate the meaningful course of action, using models within bounded transitions, or does the model assemble and revise that course of action from feedback at runtime?

This is a system-local question. A large product may contain a deterministic intake workflow, a model-directed research subsystem, and an approval-controlled publishing workflow. Calling the whole product either “a workflow” or “an agent” loses the boundaries that engineers need to secure and evaluate.

Terminology across the industry remains inconsistent. Anthropic uses agentic systems as an umbrella that includes both workflows and agents. Other sources use agentic workflow for adaptive model-directed execution. The Fieldbook does not try to enforce a universal label. It uses a precise local description and records the source-specific meaning when citing others.

Mental model: the control envelope

Think of every model-mediated component as operating inside a control envelope. The envelope defines:

• the goal or task presented to the model;
• the state and observations it can receive;
• the choices it may make;
• the tools and actions it can invoke;
• the resources and time it may consume;
• the conditions under which it must stop or escalate; and
• the consequences that require validation or human approval.

The workflow–agent distinction concerns freedom inside that envelope.

In a predefined workflow, code exposes a closed transition set. A model may choose billing, technical, or general, but code defines those categories and what each transition means. An evaluator may return revise or accept, but code owns the loop, the iteration limit, and the next operation.

In an agent, the available actions may still be finite, but their sequence is not enumerated as the task path. The model examines evolving state, selects an action, observes the result, and decides what to do next. A coding agent may search, inspect a file, edit another file, run tests, revise the patch, and stop. Code constrains the action vocabulary; the model constructs the route.

This boundary is not perfectly binary. An orchestrator may dynamically invent subtasks while a deterministic outer program assigns each subtask to a fixed worker and aggregates the results. The most useful description is then: model-directed decomposition inside a predefined orchestration envelope. The label matters less than making that transfer of control visible.

Automation versus autonomy

Automation executes a process without requiring a person to perform each step. Autonomy adds discretion over the course of action. A scheduled invoice pipeline can run every night without supervision while following the same code-defined route. It is highly automated but has little runtime discretion.

An interactive assistant may be less operationally independent—it waits for a user every few minutes—but still exercise meaningful autonomy between checkpoints by choosing searches, tools, and revisions. NIST describes autonomous systems in terms of selecting and executing diverse discrete actions without human intervention, while UK defence guidance emphasizes using AI to determine a course of action through the system’s own decisions (NIST; UK Dstl). Both ideas—choice and human involvement—matter.

For this Fieldbook, autonomy means delegated runtime discretion exercised without contemporaneous human direction or approval. This definition excludes a fixed timer from becoming “autonomous” merely because nobody is watching it, while recognizing that autonomy can exist inside a short, supervised run.

Capability must also remain separate. A powerful model can be required to request approval before every write. A weak model can be allowed to act unattended. Research on autonomy levels makes this distinction explicit: capability and operating environment may influence autonomy, but developers can hold them constant and still change the user’s role from operator to observer (Feng, McDonald, and Zhang, 2025).

The delegation profile

A single label such as “semi-autonomous” is too compressed for design review. Describe the delegation using four dimensions instead. They are not claimed to be mathematically independent; together they reveal the practical control surface.

Dimension	What to record	Lower-delegation example	Higher-delegation example
Path discretion	Which steps, branches, tools, retries, and stopping decisions may the model choose?	Select one code-defined support queue	Form a plan, choose tools, revise it from results, and decide when the goal is met
Action authority	May the system recommend, stage, or commit changes, and which changes are reversible?	Draft an email for review	Send messages, update records, or execute a payment
Operating horizon	How long and across which interruptions does the delegation persist?	One bounded turn with a low token limit	A background task that resumes over hours or days
Human involvement	What role does a person play before, during, and after execution?	Direct each step and approve every action	Set the goal, observe summaries, and handle exceptions only

Environmental reach and consequence provide the context for this profile. Reading a supplied public document and writing to a production customer record are not equivalent merely because both use one tool call. Model capability and evaluation evidence determine what performance may be expected. Identity and authorization determine what actions are actually permitted. NIST’s work on software-agent identity highlights authorization, auditing, and non-repudiation as separate requirements when agents access external data, tools, and applications (NIST NCCoE, 2026).

Do not average the four dimensions into one score. A system can have high path discretion but low action authority, such as a research agent that freely searches but only produces a draft. Another can have low path discretion but high authority, such as a fixed workflow that automatically issues refunds after a model classification. The second may require stronger controls even though it looks less “agentic.”

Boundary cases

The following examples test the model against systems that are often mislabeled.

1. Unattended document-processing pipeline

Every night, code loads new invoices, asks a model to extract fields into a schema, applies deterministic validation, and sends exceptions to a review queue.

• Control structure: predefined workflow.
• Reason: code defines every stage and transition; the model performs a bounded semantic operation.
• Delegation profile: low path discretion, staged action authority, batch horizon, human exception handling.

The pipeline is automated and may be AI-native, but it is not an agent under the Fieldbook definition.

2. Model-based support router

A model chooses among billing, returns, and technical-support; code then launches the corresponding fixed process.

• Control structure: predefined workflow with a model-mediated branch.
• Reason: the choice is closed, and code defines both the available destinations and their consequences.
• Review focus: routing accuracy, abstention, fallback, and whether any destination has consequences too large for a probabilistic classification.

If the same model can invent a resolution plan, select arbitrary tools, negotiate policy exceptions, and decide when the case is complete, the locus of control has changed and the subsystem is now agentic.

3. Evaluator–optimizer loop

One model drafts an artifact; another scores it against a rubric; code repeats the pair until the score passes or an iteration limit is reached.

• Control structure: predefined workflow.
• Reason: code owns the loop topology and stopping limit even though a model supplies the gate signal.
• Review focus: evaluator reliability, correlated model failures, maximum iterations, and the meaning of “pass.”

If the system may change its strategy, select new evidence sources, add or remove subtasks, or redefine intermediate goals from feedback, model control extends beyond a bounded gate.

4. Orchestrator–worker research system

An orchestrator model decomposes a question into a variable set of research tasks. Code dispatches each task to identical workers, then a fixed aggregation stage combines their results.

• Control structure: hybrid boundary case—model-directed task decomposition inside a predefined orchestration envelope.
• Reason: the model constructs part of the path, while code fixes the worker topology and outer lifecycle.
• Review focus: which subtasks may be invented, duplication and omission, budgets, source boundaries, aggregation quality, and whether the orchestrator can recursively delegate.

Calling it simply a workflow or an agent is less informative than documenting the split.

5. Repository coding agent

Given an issue and a repository, a model searches the codebase, chooses files and tools, edits code, runs tests, reacts to failures, and decides when the patch is ready.

• Control structure: agent inside a deterministic harness.
• Reason: the model constructs and revises a multi-step route from environmental feedback.
• Delegation profile: high path discretion; action authority varies from read-only analysis to direct writes or deployment; a bounded or long-running horizon; human involvement ranging from step approval to final review.

The harness remains responsible for filesystem scope, command policy, secrets, budgets, test execution, approval gates, and termination. Calling the component an agent never removes the surrounding system’s obligations.

Choosing the control structure

Start with the task, not the desired label.

Prefer a predefined workflow when

• the meaningful stages and exceptions can be enumerated economically;
• consistency, auditability, and predictable latency matter more than open-ended adaptation;
• model judgment is needed only inside bounded transformations or decisions;
• consequences require deterministic validation at known points; or
• representative evaluation does not show that model-directed sequencing improves the outcome.

Workflows are not a primitive stage to outgrow. They are often the correct architecture for regulated, high-volume, or well-understood work.

Prefer an agent inside a deterministic envelope when

• the required steps depend materially on information discovered during execution;
• hard-coding the decision tree would be brittle, incomplete, or more expensive than bounded model reasoning;
• the system can observe action results and use them to correct its course;
• success and failure can be evaluated at the task or environmental level; and
• permissions, budgets, stopping, recovery, and escalation can be enforced outside the model.

An agent is justified by the value of runtime adaptation, not by the presence of a planning prompt, a tool API, memory, or multiple model roles.

Increase delegation one dimension at a time

Do not jump from advisory output to unattended action as one release. A safer progression is often:

1. let the system recommend a plan;
2. let it execute in a sandbox or on reversible state;
3. stage actions for review;
4. auto-commit low-consequence actions that pass deterministic checks;
5. reserve high-impact or anomalous cases for explicit approval; and
6. expand scope only when evaluation and production evidence support it.

This is not a universal maturity ladder. A system may remain permanently at any step because that allocation of responsibility best fits the use case.

Trade-offs

Greater path discretion can handle exceptions and information that were unknown when the software was written. It can reduce brittle branch logic and let one system address a wider task distribution. Longer horizons can move from suggestions to completed work. Reduced human involvement can improve throughput and availability.

Those benefits change the engineering burden:

• Legibility decreases: the actual route may not be known before execution.
• Evaluation expands: tests must cover trajectories, tool use, stopping, and final state, not only individual outputs.
• Failure propagation grows: an early misunderstanding can shape many later actions.
• Cost and latency vary: the number of steps and retries becomes input-dependent.
• Security exposure increases: tools connect model-mediated behavior to data and side effects.
• Recovery becomes architectural: long or consequential runs need checkpoints, idempotency, cancellation, and rollback.
• Human attention becomes scarce: approvals and monitoring consume time and can become perfunctory.

Human approval is not a magic boundary. Experiments in AI-assisted decision tasks show that people can over-rely on incorrect recommendations, and adding explanations does not necessarily remove that effect (Cecil et al., 2024). An approval step is meaningful only when the reviewer has adequate context, time, authority, and a realistic way to reject or modify the action.

The opposite trade-off also matters. Excessive deterministic orchestration can encode a sprawling, fragile approximation of judgment. If engineers keep adding branches to handle cases that are genuinely open-ended, the apparent control may be illusory. The goal is not minimum model use; it is the simplest control structure that produces acceptable outcomes under enforceable boundaries.

Failure modes

Autonomy theater

The team adds planning language, memory, or multiple agents and presents the design as advanced, although code still determines every meaningful transition. Complexity rises without useful discretion. Describe the control envelope and measure whether adaptation improves outcomes.

Hidden autonomy

A component is called a classifier or assistant but can select consequential branches, retry indefinitely, or trigger tools with side effects. Review control at each transition rather than trusting the product label.

Capability–permission collapse

Because a model can perform an action in evaluation, the production system is allowed to perform it automatically. Capability evidence answers “can it?” Authorization and autonomy design answer “may it?” and “without whom?” Keep the decisions separate.

Approval theater

Every action technically requires a click, but reviewers see too little context, receive too many requests, or cannot alter the proposal. The system appears low-autonomy while the human functions as a rubber stamp. Design selective checkpoints around consequence and anomaly, and evaluate the human process itself.

One label for the whole product

A product with intake workflows, a research agent, and a publishing approval gate is assigned one autonomy level. Local differences disappear. Produce a delegation profile for each consequential subsystem or action class.

Multi-agent inflation

The number of model roles is treated as an autonomy or maturity measure. A fixed chain of five agents can have less path discretion than one tool-using agent. Add agents only for demonstrated separation, specialization, context, or evaluation benefits.

Unbounded horizon

A run can continue consuming tokens, calling tools, spawning work, or modifying state because “done” is left entirely to model judgment. Enforce budgets, maximum turns, deadlines, cancellation, checkpointing, and explicit terminal states outside the model.

Workflow overfitting

The team refuses model-directed adaptation and responds to every exception with another branch. The workflow becomes opaque, expensive to maintain, and still fails on novel cases. Reconsider the agent boundary when the task path depends on discoveries that cannot be enumerated economically.

Industry evidence

The evidence supports several durable observations while leaving room for different terminology:

1. Locus of control is an actionable architecture boundary. Anthropic and OpenAI both distinguish model-managed execution from bounded model use inside simpler applications or workflows.
2. Autonomy and capability are different deployment choices. The autonomy-level research and DeepMind’s broader AGI taxonomy both separate what systems can do from how independently they are deployed (Feng et al., 2025; Morris et al., ICML 2024).
3. Authority makes abstract autonomy concrete. NIST frames external data, tools, applications, authorization, and auditing as explicit agent-system concerns.
4. The action surface is expanding. A UK AI Security Institute analysis of 177,436 published agent tools reported a shift in downloads from observation toward action capabilities, including tools operating in less constrained environments. The dataset measures published tooling and downloads rather than verified executions, but it demonstrates why action authority cannot remain implicit (AISI and Bank of England, 2026).
5. Human presence is not equivalent to effective control. Human–AI decision research documents both over-reliance and context-dependent trust, so oversight must be designed and evaluated rather than asserted.

No source establishes the Fieldbook’s four-part delegation profile as a standard. It is a synthesis intended to make architecture reviews more concrete. It should change if repeated use shows that its dimensions overlap unhelpfully or omit an important form of control.

Fieldbook guidance

For every model-mediated subsystem, write a short control statement:

Code defines [fixed stages, available tools, hard constraints, budgets, and terminal conditions]. The model may decide [bounded branches, action sequence, retries, or stopping]. A person must [provide direction, approve named consequences, handle exceptions, or review outcomes].

Then record the delegation profile:

1. Path discretion: list decisions delegated to the model and decisions retained in code.
2. Action authority: separate read, recommend, stage, write, transact, publish, and delegate permissions.
3. Operating horizon: define maximum turns, time, cost, continuation, resumption, and cancellation.
4. Human involvement: state who directs, approves, monitors, handles exceptions, and remains accountable.

Choose the architecture only after this description. If the task can be expressed as a stable closed graph, prefer the workflow. If the route must be assembled from unpredictable discoveries, consider an agent—but retain a deterministic envelope proportional to reach and consequence.

Grant autonomy per action class, not per product. A research system may search public sources freely, require approval to access private data, stage a report for review, and prohibit publication. That is more precise and safer than calling it “Level 3 autonomous.”

Finally, require evidence for every increase in delegation. The evidence should show improved task outcomes under realistic conditions and acceptable behavior at the new authority, horizon, and oversight configuration. A model benchmark alone is not sufficient.

Checklist

Before approving a workflow or agent design, ask:

• Can we state the task goal and success condition independently of the model’s prose?
• Which meaningful paths are enumerated by code, and which are constructed by the model?
• Are model routers and evaluator gates closed, bounded, and able to abstain or escalate?
• What may the system read, recommend, stage, write, transact, publish, or delegate?
• Which actions are irreversible, externally visible, expensive, sensitive, or high-impact?
• What limits turns, time, cost, retries, recursive delegation, and background execution?
• How can a run be paused, cancelled, resumed, rolled back, or safely repeated?
• At which points is human judgment genuinely useful, and what context does the reviewer receive?
• Can the reviewer reject, modify, or take over, or is approval merely ceremonial?
• Are capability, permission, autonomy, and accountability documented as separate decisions?
• Have we evaluated the complete trajectory and final environmental state, not only the final text?
• What measured outcome justifies each increase in model discretion or reduction in human involvement?
• Would a simpler workflow produce acceptable results with lower operating and failure costs?
• Are different subsystems and action classes described separately instead of assigning one label to the product?

References

1. Anthropic, “Building effective agents” (2024) — Distinguishes predefined workflows from model-directed agents and documents common workflow patterns.
2. OpenAI, “A practical guide to building agents” — Describes model-managed workflow execution, tools, orchestration, guardrails, exit conditions, and human intervention.
3. Feng, McDonald, and Zhang, “Levels of Autonomy for AI Agents” (2025) — Treats autonomy as a design decision separable from capability and organizes levels around the user’s role.
4. Morris et al., “Levels of AGI for Operationalizing Progress on the Path to AGI” (ICML 2024) — Separates performance, generality, autonomy, deployment risk, and human–AI interaction choices.
5. NIST, “Autonomous systems” — Defines autonomous systems through selection and execution of diverse actions without human intervention.
6. NIST NCCoE, “New Concept Paper on Identity and Authority of Software Agents” (2026) — Connects agent access with identity, authorization, auditing, and non-repudiation concerns.
7. UK AISI and Bank of England, “How are AI Agents used? Evidence from 177,000 AI agent tools” (2026) — Provides observational evidence about the growth of action-enabling agent tools and unconstrained environments.
8. Cecil et al., “Explainability does not mitigate the negative impact of incorrect AI advice in a personnel selection task” (2024) — Provides experimental evidence that human review can over-rely on incorrect AI advice.