AI agent or fixed workflow? Three architectures, four questions and an agent design card

Why is the word "agent" so blurry?

The term AI agent now covers two different things at once: an autonomous system that makes its own decisions and a flow that simply follows steps someone wrote in advance. Anthropic resolves the confusion with an architectural distinction. Anthropic defines workflows as "systems where LLMs and tools are orchestrated through predefined code paths," and agents as "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks" (Anthropic, "Building effective agents," December 19, 2024). It adds that agent implementations are often straightforward: typically just LLMs using tools based on environmental feedback in a loop. So the difference is not intelligence. It is who runs the control flow: your code or the model.

Microsoft Learn classifies the same ground at a different scale: a direct model call, a single agent with tools, and multi-agent orchestration. The two classifications do not measure the same thing, and we read them side by side below.

The difference between a chatbot and an agent is a separate question, which we answered on our AI integration page, so we do not repeat it here. Whether an AI feature can go live is also a separate question, answered by our pre-launch checklist. This article covers the step before both: should this job be an agent at all, and if so, what should it be authorized to do?

Three architectures, one table

The table compares three architectures on the same dimensions. The judgments in the cells are our engineering reading; neither the Anthropic nor the Microsoft page presents them as a table.

The mapping is also our reading: in Microsoft's level table, the direct model call corresponds to the first column, and the single agent with tools and multi-agent orchestration correspond to the last. The fixed workflow is the middle column, and it does not appear as a separate level in that table.

Both sources point the same way. Microsoft says to use the lowest level of complexity that reliably meets your requirements, and adds that if prompt engineering can solve the problem, you don't need an agent. Anthropic recommends finding the simplest solution possible and increasing complexity only when needed, and states that this "might mean not building agentic systems at all." The same page notes that agentic systems often trade latency and cost for better task performance, and that for many applications optimizing a single LLM call with retrieval and in-context examples is usually enough.

Workflow patterns: where many jobs end

Before you move to an agent loop, look at what a fixed flow can do. Anthropic lists five patterns in the workflow class, each given here in one sentence plus a "when":

• Prompt chaining. The task is split into fixed subtasks, each call processes the output of the previous one, and programmatic checks can sit between steps. Use it when the task decomposes cleanly into fixed parts.
• Routing. An input is classified and sent to a specialized next step. Use it when there are distinct categories and classification can be done accurately.
• Parallelization. Independent subtasks run at the same time, or the same task runs several times and your code combines the results. Use it when speed or higher confidence calls for several perspectives.
• Orchestrator and workers. A central model breaks the task down while running and delegates to workers. Anthropic still counts this as a workflow, but it fits where you cannot predict the subtasks, which makes it the pattern closest to an agent.
• Evaluator and optimizer. One call generates, another gives feedback in a loop. Use it when you have a clear evaluation criterion and iteration brings measurable improvement.

The patterns can be combined; Anthropic presents them as common patterns, not prescriptions, and says to add complexity only when it demonstrably improves outcomes. Whether you build a fixed flow with an off-the-shelf tool is a separate decision: our article on when n8n or Zapier is not enough lays out the thresholds with their documentation.

Four questions to decide: AI agent or workflow?

The four questions below are ones you answer about your own job. You can read a product, a process or a proposal against them. On question 1, "yes" points away from an agent; on the other three, "yes" makes an agent possible.

A second table reads the four answers together:

This table is our engineering judgment, not a standard. Whatever the result, the decision is made at the scale of your own job.

The four questions are most often misread in these places (our judgment):

• Question 1. Having many steps is not a reason for an agent; the test is not the number of steps but whether they can be written in advance.
• Question 2. "Technically reversible" is not the same as "the outcome is reversible": a message that has been sent can be deleted and still have been read.
• Question 3. "We will know if users complain" is not a measurement method.
• Question 4. Think of the budget for all the usage you expect, not for a single request.

Applying the four questions to three fictional jobs

The three jobs below are fictional; none is a client or project of ours. The point is to show how the questions read.

Entering incoming invoices into a system. The steps can be written in advance: read the document, extract fields, validate with rules, create the record. Question 1 is yes, so the result is a fixed workflow. The model appears at most in the field extraction step; the code that creates the record is yours.

Replying to an unstructured customer request and issuing refunds. Drafting a reply is reversible and can be measured with sample requests and expected replies. Starting a refund is an irreversible action that involves money. For many requests, routing plus a draft is enough, which makes it a workflow. Even if a refund suggestion comes from an agent, question 2 is a no, so the decision does not go beyond a human-approved agent.

Investigating an unknown error record. The required steps are not known in advance: you may need to look at logs, code and documentation and test a hypothesis. All the tools are read-only and the output is only a report. Question 1 is no and question 2 is yes. Question 3 decides: if you cannot measure the accuracy of the report against past incidents, measurement comes first. If you can, question 4 applies: if you can set limits on steps, calls and cost for each investigation, the table says "agent, with narrow tools, short-lived authority and hard limits"; if you cannot, a fixed workflow or a single call.

In all three, the decision comes from the job's own answers. Saying "we use AI" carries no weight.

Designing the authority you give an agent

OWASP's "Excessive Agency" entry splits the root cause in three: excessive functionality, excessive permissions and excessive autonomy. We turn that into three design areas.

Tool inventory (functionality). Give the agent only the tools it needs. Keep tools narrow, and keep read and write as separate tools. OWASP advises avoiding open-ended tools such as "run a shell command" or "fetch a URL" in favor of granular functions. A tool that only needs to read documents should not carry delete and modify functions.

Identity (permissions). Let the tool run in the context of the user making the request and with the least privilege needed, not with a generic high-privilege identity that can reach everyone's data. In the infrastructure system described in our engineering article, this principle goes further: the agent holds no persistent credential, and authority is granted at apply time through a short-lived credential tied to the approved plan. Keys leaking into code and client bundles is a separate danger; we cover it in our vibe coding audit.

Autonomy. Write every action into one of three classes: automatic, human-approved or forbidden. OWASP recommends human approval for high-impact actions and says that authorization should be enforced in downstream systems rather than relying on an LLM to decide if an action is allowed or not.

From our engineering article we take only the structural pattern, with no figures: the agent has no network path to the cloud system, the only output it produces is a plan, and a deterministic gate that does no reasoning decides whether the plan is applied. Your product may be a support assistant or a flow that updates records; the principle is the same: do not put a probabilistic component on the enforcement path. The checklist counterpart of this section is items 7 and 8 of the 14-point list; we do not repeat it here.

The approval gate needs design too; an approval screen should be more than an "approve" button. The reviewer should see the proposed action, the record it affects, the before and after state of the change, the agent's reasoning and the way to undo it. Without those on screen, approval drifts toward the rubber-stamp risk described below. This is our judgment; OWASP only says to require human approval for high-impact actions.

Action class and recommended authority, as a small table:

This classification is our judgment; OWASP's examples (sending mail, publishing content, deleting) are all actions that call for approval.

Evaluating and monitoring an agent

Evaluate the outcome and the trace separately. "Was the outcome right?" and "did it take the right path?" are different questions. Anthropic says agents gain ground truth from the environment at each step (a tool result, code execution output) and recommends showing the agent's planning steps explicitly; being able to read the trace is the counterpart. Testing an agent in a safe environment before it goes live is also Anthropic's recommendation. Writing separate criteria for outcome and trace is our judgment. For example, even if a refund suggestion is right, an agent that read another customer's record has a right outcome and a wrong trace, and a set that only measures outcomes will not see it.

Do not build a loop without a stopping condition and a hard limit. Anthropic notes that agents commonly include stopping conditions such as a maximum number of iterations, and Microsoft says to set iteration limits to guard against infinite tool-call loops. The value of the limit depends on your job; we do not recommend a number.

Keep a record that answers "why did it do that?" The system in our engineering article records the following for each decision; ask for the same fields for your own agent:

• the model and its version,
• the prompt that was used,
• the identifiers of the retrieved documents,
• the tool calls and their results,
• the identity of the person who approved.

The article's qualitative observation: without a record, human approval slows down, and slow review eventually slides into rubber-stamping. So the record is needed not only for audit but for the approval gate to work.

How to build an evaluation set and how to read it is covered by item 3 of the checklist and the evaluation set template; we do not copy it here.

The cost of thinking: compiling an agent into a workflow

One more lesson from the system in our engineering article, again without figures: resolving every decision with a full reasoning loop is both expensive and slow. According to the article, decisions mostly cluster into a small number of shapes. When a decision shape recurs with a stable outcome, it is compiled into a parameterized workflow, in the article's term a playbook. A decision that does not fit a playbook goes to a fast, cheap model, and one that misses the shape or has low confidence goes to a stronger model. The share of decisions escalating to the strong model is also a leading indicator of drift: if it rises in one environment, that environment has moved outside the shapes seen before.

Our reading is this: using an agent for discovery and then turning the recurring pattern into a fixed flow means asking "agent or workflow?" continuously, not once. A job that starts as an agent can turn into a fixed flow over time, and the agent stays only at the edge you still cannot predict. Whether this works on your job is something your own records will show.

The agent design card

Copy the table below and fill it in for each agent candidate. The second column tells you what to write on each row.

How to use it: have the business owner, the engineer and the person responsible for security each read and fill it in separately. Every empty row is an open decision; if you cannot write a row, the agent is not ready on that point. If the purpose and "why an agent" rows cannot be written, the card is not yet a design. If the answer to the first question is "yes," then "no agent needed" is also a valid result, and the card may be a single row.

How we do it

Every project is a paid engagement that starts with a written quote you approve. Scope, timeline and cost are in your hands in writing before anything is billed; nothing is charged until you approve. In AI projects, most of the value is created in the first two steps, because that is where we decide what AI will and will not solve. We treat the mistake as an input to the design from the start; where a wrong answer is costly, the system does not decide, it suggests, and the action is tied to human approval. We write down the reasoning behind every technical decision. You talk directly with the engineer writing your code. If a ready-made chatbot subscription already does the job, there is no need for a custom build, and we say so. The scope is set out in a written quote. We describe the steps on our Process page and the AI side on our AI integration page. Tell us about your project.

Frequently asked questions

How do you build an AI agent, and where do you start?

Answer the four questions above first. Often the starting point is a fixed workflow; an agent loop is added only for the part where you cannot write the steps in advance. The MVP development approach helps keep the first version small. If the first two rows of the agent design card cannot be filled in, go back to defining the job before building. Which framework or model to use is a separate question that comes after this decision and depends on the job's risk, data and cost; this article does not pick one.

What is the difference between an agent and a workflow?

By Anthropic's distinction: in a workflow, LLMs and tools are orchestrated through predefined code paths; in an agent, the LLM dynamically directs its own processes and tool usage. We answered the difference between a chatbot and an agent in the answer on our AI integration page.

Which actions should an agent be allowed to take, and which should wait for approval?

It can take some actions on its own; the real question is the boundary of the actions it is allowed to take. For irreversible actions or actions that affect the outside world, you need a propose and apply split, human approval, and the approval rule placed in a gate outside the model. The action class table is above; the detail is in item 8 of the checklist. Decide in writing with the job's owner which action falls into which class, and have the system behind the tool enforce it, not the agent.

When do you need a multi-agent system?

As Microsoft puts it, use the lowest level of complexity that reliably meets your requirements. Multi-agent orchestration can be justified where a single agent cannot reliably do the job because of prompt complexity, tool overload or security requirements. Measure with a single agent or a fixed workflow first; if you cannot show in writing why it was not enough, you probably do not need several agents. That last sentence is our judgment.

How can you tell later why an agent did something?

By keeping a record: model and version, prompt, identifiers of retrieved documents, tool calls and their results, and the identity of the approver. Without these fields, the answer to "why did it do that?" turns into a guess. The "Record" row of the card is there for this. It is hard to add a record after the agent is written; put it into the design from the start, because the person at the approval gate will read the reasoning from the same record.

Sources

The pages below were opened and read on November 6, 2026. The Anthropic page carries a note that much of the tooling it describes has changed since December 2024; we used only the architectural distinction and the principles.

• Anthropic, Building effective agents (December 19, 2024).
• Microsoft Learn, AI agent orchestration patterns (page date February 12, 2026).
• OWASP GenAI Security Project, LLM06:2025 Excessive Agency (last modified May 5, 2025).
• C.E.O. Bee engineering article: Proposals, Not Actions: The Control Plane Behind Autonomous Infrastructure Agents.