AI agents vs workflows: make the workflow your default

Make the workflow your default and let the agent earn its place

The workflow is the default because the difference is one of control, not intelligence. Anthropic draws the line in two sentences: workflows are systems where models and tools are orchestrated through predefined code paths², and agents are systems where the model directs its own process and tool use².

Follow the support ticket through all three. In the workflow, one model call labels the ticket and a plain match statement picks the next step, so billing, bug and account tickets each take a fixed path. In the single agent, the model chooses which tool to call next and when to stop. With several agents, a lead model also chooses which other models to wake.

Anthropic's advice, from building with customers, is to find the simplest solution possible and only add complexity when needed². The most successful implementations they saw used simple, composable patterns rather than complex frameworks². OpenAI's guide makes the same call one level up: maximize a single agent's capabilities first³.

The agent earns its place where the path cannot be written down. Anthropic reserves agents for open-ended problems where the number of steps is hard or impossible to predict and a fixed path cannot be hardcoded². In the ticket system only a refund dispute fits: the agent may need the order, then the payments, then the delivery record, in an order no rule predicts.

The router is where you keep that boundary honest. Structured outputs guarantee schema-compliant responses through constrained decoding⁴, except, the same docs warn, on a refusal or a max_tokens cutoff. So the code checks stop_reason first, hands those to a person, and the match only sees labels your code knows.

from typing import Literal
from pydantic import BaseModel
from settings import client, MODEL
from routes import billing_reply, file_bug, account_reply
from refund_agent import refund_agent
from handoff import hand_to_person

class Label(BaseModel):
    kind: Literal["billing", "bug", "account", "refund_dispute"]
    summary: str

def classify(ticket: str) -> Label | None:
    response = client.messages.parse(
        model=MODEL,
        max_tokens=1024,
        system="Label this support ticket and summarise it in one sentence.",
        messages=[{"role": "user", "content": ticket}],
        output_format=Label,
    )
    if response.stop_reason != "end_turn":  # a refusal or a max_tokens cutoff
        return None
    return response.parsed_output

def handle_ticket(ticket: str):
    label = classify(ticket)        # the model judges inside one step
    if label is None:
        return hand_to_person(ticket, [])
    match label.kind:               # your code picks the next step
        case "billing":
            return billing_reply(ticket, label)
        case "bug":
            return file_bug(ticket, label)
        case "account":
            return account_reply(ticket, label)
        case "refund_dispute":
            return refund_agent(ticket, label)  # the one step the model steers

The same split decides how you debug it. Each fixed case is a function you can unit test alone, retry as a single step, and explain to an auditor from its input and output. The refund agent is the one branch whose path is chosen at run time, so it is the one you debug by reading its trace.

When someone proposes another agent step in review, ask which case it replaces and which real ticket showed the fixed path failing.

Every decision you hand the model is paid for in tokens

Each decision you hand the model is another call that rereads the context so far, and you pay for every call in tokens. In Anthropic's data, from its own workloads, agents use about 4× more tokens than chat and multi-agent systems about 15× more⁵.

On BrowseComp, a benchmark of browsing agents finding hard-to-find facts, token usage by itself explained 80% of the variance in performance, with tool calls and model choice as the other factors⁵. More tokens meant more searching, and on a browsing task, breadth is the job.

Anthropic states the trade plainly: agentic systems often trade latency and cost for better task performance, and you should consider when that makes sense². For a router that runs on every ticket all day, I think it rarely does. For the few refund disputes a person would otherwise untangle by hand, it can.

The multipliers are Anthropic's, so price one of your tickets before you build the agent step. Count the model calls on the happy path of each route, multiply by the context each call carries, and weight by how often each route fires. The fixed routes cost a classify call and a drafting call. The refund agent costs whatever its loop runs to, so the loop gets a cap, and the cap is its price ceiling.

Tools set the size of each turn. Anthropic restricts tool responses in Claude Code to 25,000 tokens by default⁶. Your own API loop has no limit until you add one, so truncate each tool result yourself. When a call fails validation, Anthropic suggests error messages that say what to fix rather than opaque codes⁶.

Cap the turns as well. When the cap is hit, the ticket goes to a person instead of the loop running on, so the worst dispute has a price you wrote down.

An agent that succeeds once has not shown it will succeed twice

One successful run says little about the next, yet one run is the first measurement most teams take. Sierra built τ-bench as a simulated customer with real tools and a policy to follow. From deploying support agents, it found that measuring reliability well is critical to deployment¹. When τ-bench was published, its best agent fell to about 25% on pass^8 in retail, a 60% drop from its pass^1 score¹.

One try asks whether the agent can do the task. pass^k asks whether it does the task every time: Anthropic defines it as the probability that all k trials succeed⁷.

Anthropic says the metric especially matters for customer-facing agents, where users expect reliable behavior every time⁷. Each customer meets a single run. A green demo is one try too, and it says little about the refund dispute your agent gets wrong on its fourth. Anthropic also notes that minor issues for traditional software can derail agents entirely⁵, and in the refund loop one wrong order lookup becomes the premise for every step after it.

The fix is a test that reruns real failures. Anthropic's evals team writes that 20 to 50 simple tasks drawn from real failures is a great start⁷.

import json
import pytest
from triage import handle_ticket

RUNS = 8  # pass^8: a case passes only if every run passes
# Each line: a ticket the agent once got wrong, and the action a person says was right.
CASES = [json.loads(line) for line in open("cases/refund_failures.jsonl")]

@pytest.mark.parametrize("case", CASES, ids=lambda c: c["id"])
def test_passes_every_run(case):
    actions = [handle_ticket(case["ticket"]).action for _ in range(RUNS)]
    wrong = [a for a in actions if a != case["expected_action"]]
    assert not wrong, f"{len(wrong)} of {RUNS} runs chose {wrong[0]}"

The assert counts a case only when every run passes, so a flaky case fails the build instead of averaging into a green number. Run it before you widen the agent's tools and after every prompt change. Hamel Husain led the team behind CodeSearchNet and has watched many LLM products succeed and fail. The failed ones, he finds, almost always share one root cause, no robust system for evaluating them⁸, and he puts error analysis first:

A second agent helps only when the work splits cleanly

A second agent helps only when the work splits cleanly, as in Anthropic's multi-agent system, where a lead model with subagents beat a single agent by 90.2% on its internal research eval⁵. That gain is on Anthropic's own task and was bought with heavier token spend. Since token use explains most of the variance in performance⁵, we think part of it comes from the extra tokens rather than the split alone. Research also splits well: many independent searches, each returning a short summary to the lead.

The same team names where splitting fails. Domains where all agents must share the same context, or where agents depend on each other heavily, are not a good fit today⁵. Most coding tasks have fewer truly parallel parts than research, and agents are not yet great at coordinating and delegating to each other in real time⁵.

Cognition, which builds a coding agent, reached the same place from the other side. Its principle is that actions carry implicit decisions, and conflicting decisions carry bad results¹⁰. Its answer is one single-threaded linear agent, where the context is continuous¹⁰.

A Berkeley-led team measured how this goes wrong. From a close analysis of a smaller set of traces they defined 14 failure modes, grouped as system design, misalignment between agents, and task verification¹¹. They then applied them to a dataset of more than 1600 multi-agent traces¹¹. Their summary is blunt: despite the enthusiasm, gains on popular benchmarks are often minimal¹¹.

Back to the ticket. A refund dispute needs the order history and the payment record, and the decision depends on both at once. Split them across two agents and each decides with half the facts, which is Cognition's conflict in miniature. One agent with both tools keeps one context.

Before you add an agent, write down what each one owns, what it hands back and what it never sees. If the handoff needs the whole context, you have one agent with extra steps and a larger bill. When the list comes out clean, as it does for research, that list is the build.

What to do on Monday

1. Draw the steps. For your next AI feature, write one line per step saying whether your code or the model picks what runs after it.
2. Price one request. Count the model calls on the happy path, multiply by the context each one carries, and weight by how often the route fires.
3. Cap the agent step. Give it a turn limit, an allowlist of tools, and a person for anything that pays, refunds or deletes.
4. Rerun every case. Turn real failures into cases, run each several times, and count only the cases that pass every run.

Build it with me: the Free Live Lab Build a Team of AI Agents, live on Thursday, October 29.