Workflows and Agents

The idea in one minute#

In a workflow, your code decides what happens next and the model does each step. In an agent, the model decides what happens next: it is given a goal and a set of tools, and it loops — think, call a tool, read the result, think again — until it judges the task done.

Agents can do work that no fixed sequence of steps could: fix a bug, research a question, resolve a customer case that could go a dozen ways. They also turn cost, duration and behaviour from numbers into ranges, and they can act — send, pay, delete — which makes a wrong decision more than a wrong sentence.

The architect’s job is not to be for or against agents. It is to decide how much autonomy a task has earned, to give the agent the narrowest tools that let it succeed, and to put the limits in code where the model cannot argue with them.

A picture#

flowchart TB
  G[":i-user: <b>Goal</b><br/><small>from a user or an event</small>"] --> L[":i-brain: <b>Model</b><br/><small>decides the next action</small>"]
  B[":i-gauge: <b>Budgets</b><br/><small>steps, tokens, time, money</small>"] -.-> L
  L -->|"proposes an action"| P[":i-shield-check: <b>Policy check</b><br/><small>allowed? needs approval?</small>"]
  P -->|"allowed"| T[":modelcontextprotocol: <b>Tools</b><br/><small>search, read, write, run code</small>"]
  P -->|"risky"| HU[":i-hand: <b>Human approval</b>"]
  HU --> T
  T -->|"result"| L
  L -->|"done"| R[":i-check: <b>Result</b><br/><small>with a trace of every step</small>"]
  L -.-> ST[(":postgresql: <b>State</b><br/><small>checkpoints, memory</small>")]
  class G,R neutral
  class L compute
  class P,HU warn
  class B queue
  class T io
  class ST memory

The model is one box. Everything else in the picture — budgets, the policy check, approvals, state, the trace — is the harness: ordinary software that you design, and where an agent’s safety and reliability come from.

How it really works#

The autonomy dial#

“Agent” is not one thing. It is a dial with five positions, and choosing the position is a design decision made per task.

Start one position lower than the sponsor asks for. Moving up is a release decision backed by evidence from the level below; moving down after an incident is a crisis.

The test: has this task earned an agent?#

Four conditions, all required.

1. The steps cannot be listed in advance. If they can, build a workflow.
2. The task is valuable enough. An agent run costs ten to a thousand times a single call. The value per task must clear that with room to spare.
3. A wrong result is detectable and recoverable. There is a test, a reviewer or an undo.
4. The tools exist and are safe to expose. The systems it must touch have APIs with permissions fine enough to grant only what the task needs.

Fail any one and the right answer is a workflow, a narrower task, or assistance to a person.

Tools decide what an agent can do#

A tool is a function the model may ask your code to run: search the knowledge base, look up an order, create a ticket, execute code. The model never runs anything itself — it emits a request, and the harness decides whether to carry it out.

That makes tool design the main lever of agent design:

• Few and specific beats many and general. refund_order(order_id, amount) with a limit enforced in code is safer and more reliable than run_sql(query).
• Read tools and write tools are different risks. Grant reads broadly, writes narrowly, and irreversible writes only behind approval.
• The agent acts as someone. Decide whether tools run with the user’s permissions or the agent’s own, and make sure the agent can never reach more than the user could.
• Descriptions are prompts. The model chooses tools by reading their descriptions, so unclear descriptions cause wrong actions.

Two open protocols now carry most of this. MCP (Model Context Protocol) is how an agent connects to tools and data: write a tool server once and any compliant agent can use it. A2A (Agent2Agent) is how one agent hands a task to another across a team or company boundary. Both are governed by the Agentic AI Foundation under the Linux Foundation, and all three large cloud platforms support them — which, for an architect, means tools are an asset you can build once and reuse across agents and vendors. The mechanics are in Tools and Protocols.

One agent or many#

Multi-agent designs — a supervisor delegating to specialists — are popular in diagrams. They earn their place in three situations: the work splits into independent parts that can run in parallel; a sub-task needs so much reading that it would flood the main agent’s context; or separate teams own separate agents. Otherwise a single agent with good tools is cheaper, faster and far easier to debug. Every hand-off between agents loses context and adds a place to fail.

What an agent needs that a chatbot does not#

Counting the cost before you build#

An agent’s cost is a distribution. Estimate three numbers and present all three:

typical run   =  median steps × (average input + output tokens per step) × price
bad run       =  the 95th-percentile steps — often 3–5× the median
worst run     =  the budget cap, because some runs will hit it

Input tokens dominate: each step resends the growing history, so a 30-step run reads far more than it writes. Prompt caching and trimming old tool results are the two biggest savings, and both are architecture decisions, not tuning.

Why agent projects get cancelled#

Gartner’s June 2025 forecast that over 40% of agentic projects would be cancelled by the end of 2027 named three causes, and each maps to something on this page.

Gartner also coined agent washing — vendors relabelling chatbots and automation scripts as agents. When evaluating a product, ask which position on the autonomy dial it actually occupies and what enforces its limits.

What fills the boxes in 2026#

How the loop, state and sandboxes are built is the subject of Agentic Systems.

Remember this#

• Workflow: your code picks the next step. Agent: the model does.
• Autonomy is a dial from 0 to 4. Start one lower than asked and earn the next level.
• An agent needs all four: unknown steps, enough value, recoverable errors, safe tools.
• Limits live in the harness — budgets, policy, approvals — never only in the prompt.
• One agent with good tools beats several agents, unless the work is truly independent.

Try it#

1. Take a process at your work and place each of its tasks on the autonomy dial. Which tasks would you never move above level 2, and why?
2. For one of those tasks, list the tools an agent would need. Mark each as read or write, and each write as reversible or not.
3. Estimate the typical, bad and worst run cost for a 12-step agent that reads 6,000 tokens and writes 400 per step on a mid-tier model. Remember the history grows.

Check yourself#

1. What are the four conditions a task must meet to deserve an agent?
2. Why should limits be enforced in the harness rather than written in the prompt?
3. When is a multi-agent design justified?
4. What is agent washing, and what one question exposes it?

Sources#

• Anthropic: Building effective agents
• Gartner: Over 40% of agentic AI projects will be canceled by end of 2027
• AWS Prescriptive Guidance: Agentic AI patterns and workflows
• Linux Foundation: formation of the Agentic AI Foundation