Module 07 · Lesson 2 of 15Free

Workflows vs agents: when you need autonomy

Level

Intermediate

Topic

Agents: models that plan and act

Reading time

17 min

Daniel wants three AI agents

Deskora is a help desk app. A shop’s support team uses it to answer customer emails from one shared inbox. Each customer problem becomes a ticket: one customer’s whole conversation with the support team. About 1,500 shops use Deskora, and 120,000 new tickets arrive a day.

Tomás is the Deskora engineer who builds the AI features. Two are live. The ticket summary puts three lines at the top of a long ticket, so a support agent like Priya can reply sooner. The drafting assistant writes a reply from the shop’s help center, for Priya to check and send. A third feature, Resolve, is proposed. It would prepare replies to “where is my order?” tickets, about 36,000 a day.

Daniel, another Deskora engineer, writes in the team channel: “Let’s rebuild all three as AI agents and let the model work out the steps.”

Tomás has numbers from last week’s Resolve prototype. One ticket took 4 model calls and about $0.04. The next took 8 calls and about $0.09. The summary costs about $0.0006 on a typical ticket, in one call, every time.

This lesson answers one question: which of Deskora’s three features should let the model choose its own steps, and what evidence should move a feature from fixed code to an AI agent?

Deskora’s ticket volume and the summary’s cost are shared course figures. Resolve’s call counts, costs, timings and test results are estimates for this lesson’s scenario.

Who decides the next step: code or the model

Anthropic’s guide “Building effective agents” (December 2024) groups every system that combines model calls and tools as agentic systems. Then it splits them by one question: who decides what happens next ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}?

• A workflow runs model calls and tools along paths written in code. Your code decides the next step.
• An AI agent lets the model decide its own steps and which tools to use, until the task is done. Agents builds that loop for Resolve.

Both are built from one block: a model call that can use retrieval, tools and memory, which the guide calls the augmented LLM ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}. The six shapes below differ in how those calls connect.

In the agent loop, each model reply either asks for tools or ends. With tools, the reply stops with stop_reason: "tool_use". Your code runs the tools and sends the results back in the next call ^{3Tool use with ClaudeAnthropic, Claude API documentation}. It stops when the task is done, when a step limit is hit, or at a checkpoint where a person must decide ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}.

So the useful question is which of the six shapes each feature needs.

Five patterns, five Deskora features

Deskora already runs three of the workflow patterns. The other two fit plausible features.

The router comes from Structured outputs; the weekly report from Long inputs. The summary isn’t on the table: it is one call plus code checks, as in Design: a ticket summary feature. The guide says one well-built call is enough for many applications ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}.

In orchestrator-workers the model chooses the subtasks, but code still fixes the shape: split, run, merge. Several AI agents working together is a separate topic, Multi-agent systems.

Only Resolve is a candidate for the sixth shape. Four questions decide whether it should be.

Four questions decide the shape

Can you list the steps before the ticket arrives?

For a summary or a draft, yes: every ticket goes through the same stages.

For “where is my order?”, often not. With one order and clean tracking, the steps are fixed. With two order numbers, or a parcel marked delivered that never came, the next step depends on what the last lookup returned. The guide puts AI agents here: open problems where the number of steps can’t be predicted or written in advance ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}.

Must cost and latency be known before the run?

A workflow’s cost is the sum of its fixed calls, known from the input size before you send anything. An AI agent’s cost depends on how many calls it makes, known only when it stops. Each call also pays again for the tool definitions and every earlier result ^{3Tool use with ClaudeAnthropic, Claude API documentation}. The guide states the trade: agentic systems give up latency and cost for better results on hard tasks ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}.

How will you test it?

A workflow runs the same steps on every ticket, so you can test each step alone, and a failure points at one step. An AI agent may take a different path on each run of the same ticket. You test the outcome and the path (did it check tracking before proposing a replacement?) over many runs, the subject of Evaluating agents.

How do errors add up over the steps?

Each model decision can be wrong. In a chain, a code check between steps catches many errors early. In an AI agent, a wrong early choice, such as the wrong order, steers every later call.

Chip Huyen gives the same shape of example: 95% per step over 10 steps leaves about 60% ^{2AgentsChip Huyen, huyenchip.com, 2025}. The guide warns that autonomy brings higher cost and the chance of compounding errors ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}.

Tomás suspected Resolve’s steps couldn’t be listed. He measured it before building an AI agent.

Resolve started as a fixed chain

The guide’s advice is to start with the simplest solution and add steps only when they are needed ^{1Building effective agentsErik S. and Barry Zhang, Anthropic Engineering, 2024}. So Tomás first built Resolve as a chain, with no AI agent:

1. Code takes the order number the ticket router already extracts.
2. Code calls get_order on the shop’s store, then get_tracking on the carrier. The shop id comes from the ticket, never from the model.
3. Code searches the help center for the delivery policy.
4. One call to Claude Sonnet 5.5 writes the reply and any proposed action, such as a replacement for a parcel lost more than 10 days.
5. Priya approves or edits. Nothing reaches the customer, and no replacement is sent, without her click.

He ran it on 200 labelled “where is my order?” tickets. One run gave these results:

Illustrative results for this scenario, not measured data.

A customer, Tendai, wrote: “I ordered twice, 51907 and 52114. One parcel never came.” The chain looked up 51907, the first number, which was delivered. The draft said: “Your parcel was delivered on 20 October.” Priya caught it. Sent, it would have told Tendai his missing parcel had arrived.

Tomás could add a branch for two order numbers, another for split parcels, another for disputed deliveries. The last row is the warning: 14 tickets, nearly 14 different next steps.

The two paths in code

Install the SDK with pip install anthropic and set ANTHROPIC_API_KEY. The order data stands in for the store’s API.

import json
import anthropic

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY from the environment
MODEL = "claude-sonnet-5-5"
MAX_CALLS = 12  # Resolve's limit per ticket
TASK = "Draft a reply for the support agent to check. Never promise a refund."
ORDERS = {"51907": {"status": "delivered", "delivered_on": "2026-10-20"},
          "52114": {"status": "shipped", "last_scan": "2026-10-16"}}
TOOLS = [{"name": "get_order",
          "description": "Look up one order in this shop's store by its order number.",
          "input_schema": {"type": "object",
                           "properties": {"order_number": {"type": "string"}},
                           "required": ["order_number"],
                           "additionalProperties": False}}]


def get_order(order_number: str) -> str:
    return json.dumps(ORDERS.get(order_number, {"error": "no such order"}))


def text_of(reply: anthropic.types.Message) -> str:
    return "".join(b.text for b in reply.content if b.type == "text")


def fixed_path(ticket: str, order_number: str) -> str:
    # Code decides the steps: one lookup, then one model call.
    prompt = f"Order: {get_order(order_number)}\n\nTicket: {ticket}\n\n{TASK}"
    return text_of(client.messages.create(
        model=MODEL, max_tokens=2000, messages=[{"role": "user", "content": prompt}]))


def agent_path(ticket: str) -> str:
    # The model decides the steps: it asks for lookups until it stops asking.
    messages = [{"role": "user", "content": f"Ticket: {ticket}\n\n{TASK}"}]
    for _ in range(MAX_CALLS):
        reply = client.messages.create(model=MODEL, max_tokens=2000,
                                       tools=TOOLS, messages=messages)
        if reply.stop_reason != "tool_use":
            return text_of(reply)
        messages.append({"role": "assistant", "content": reply.content})
        messages.append({"role": "user", "content": [
            {"type": "tool_result", "tool_use_id": b.id, "content": get_order(**b.input)}
            for b in reply.content if b.type == "tool_use"]})
    return "HANDED BACK: call limit reached"


ticket = "I ordered twice, 51907 and 52114. One parcel never came. Where is it?"
print(fixed_path(ticket, "51907"))  # the first number found: the delivered parcel
print(agent_path(ticket))

fixed_path always makes one lookup and one call, even with the wrong order. agent_path makes as many calls as the model asks for: one run might look up both orders, another only one. Treat your runs as examples.

Running both costs under 2 cents on Claude Sonnet 5.5, as of October 2026: about 1,500 input tokens and 1,350 output tokens across three calls, with about 300 thinking tokens a call assumed. usage.output_tokens_details.thinking_tokens reports the real number.

What each feature costs, and when you know

An AI agent’s cost is a sum over its calls. Each call’s input carries everything before it, so input grows with every step.

This counts model calls only, without retries of failed calls or caching. Resolve’s $0.10 limit assumes prompt caching, which cuts the repeated input most, since every call resends the same opening.

Estimates. Summary and drafting figures are on Claude Haiku 5.5, from earlier lessons’ assumptions. Times assume about 100 output tokens a second.

A common belief is that AI agents are unpredictable because their costs vary more. But the summary’s long case costs about 3 times its typical case, and Resolve’s AI agent only about 2.5 times. The difference is when you know. The summary’s cost follows from the thread’s length before the call; the AI agent’s is known only after its last call. Without a limit, a loop that keeps retrying a broken carrier lookup has no ceiling.

Resolve runs when the ticket is routed, before Priya opens it, so 35 seconds is acceptable. The cost tail is what needs the limits.

Deskora’s verdict: two workflows and one AI agent

Tomás replies to Daniel with the table and three decisions:

• The summary stays one call. It has no steps to choose. If it ever needs data outside the thread, a fixed lookup in code adds it.
• The drafting assistant stays a chain. Its stages are the same for every ticket, each with its own tests. If the draft step needs order data, a tool call inside that step adds it, as in Function calling; the chain stays fixed.
• Resolve is an AI agent only for the tickets whose steps can’t be listed. Clean tickets take the fixed chain. The rest go to the AI agent, within 12 calls and $0.10, and Priya approves every action.

The rule behind all three: start with the simplest shape that works. Move to an AI agent only when a measured failure shows the steps can’t be listed. Move steps back into code when they can.

Where this shows up

• Design: a research agent that writes reports: orchestrator-workers, with subtopics chosen at run time.
• Design: an AI customer support platform: routing, chains and an AI agent side by side.
• Design: a data analysis agent: a task whose next query depends on the last result.

Inside Resolve’s loop, each call picks the next step from what it has seen so far. How a model reasons, acts and reads results in turns is the next lesson.

Common mistakes

• Building the AI agent first. Without a fixed chain to compare, you can’t tell what its extra cost buys.
• Judging by average cost. An average of $0.066 hides a long run near $0.10 and a broken loop with no ceiling. Set a call limit and a cost limit on every AI agent.
• Adding branches forever. When each new failure needs a different next step, try an AI agent for those tickets.
• Letting an AI agent act alone. Refunds, replacements and customer messages wait for a person’s approval.
• Calling every tool use an AI agent. A tool call inside a fixed chain is still a workflow. What matters is who decides the order of steps.

Check your understanding

Summary