Agent or Workflow

The question and what it scores

The interviewer says: "Harbourline wants to automate claims intake. Would you build it as an agent or as a workflow?" Some loops phrase it as "when would you not use an agent?" The two phrasings test the same skill.

They are scoring four things:

• You define the terms by who decides the next step. Candidates who treat "agent" as a synonym for "better" lose the round at this point.
• You decide from properties of the task, not taste: whether the path is known, what a wrong step costs, whether you must explain the outcome, how tight latency and cost are, and how often the task changes.
• You say what the choice costs you. Every option here gives something up, and a strong answer names it before the interviewer asks.
• You reach the hybrid and can say exactly where the model's authority ends.

Who decides the next step

Anthropic's Building effective agents (December 2024) draws the line that most interviewers use. Workflows are "systems where LLMs and tools are orchestrated through predefined code paths". Agents are "systems where LLMs dynamically direct their own processes and tool usage". The difference is where the control flow lives.

In a workflow the control flow is code. A function calls the model with a prompt, parses what comes back, and ordinary if statements and function calls decide what happens next. The model fills in steps but never chooses them. In an agent the control flow is the model's output. The loop is: call the model, and if it asks for a tool, run the tool, append the result to the history, and call again. The loop ends when the model replies without a tool call. The same tool-use mechanism sits under both; see the loop in the harnesses chapter for the mechanics.

Four properties follow from that one difference:

• Call count. A workflow makes a fixed number of model calls, so you can price it before you run it. An agent's call count is a random variable. Each call re-sends the whole history, so cost grows faster than the number of calls (chapter 05 puts numbers on this).
• Testability. You can unit-test each step of a workflow and draw it on a whiteboard. For an agent you test the distribution of paths it takes, which is why chapter 08 exists.
• Error compounding. If each step is right 95% of the time, a ten-step run is right about 60% of the time (0.95¹⁰). A workflow limits how many steps can go wrong. An agent that picks its own steps can pick more of them.
• Coverage of unseen inputs. A workflow handles the cases its author drew. An agent can handle a case nobody drew, which is its entire advantage.

Autonomy is a dial, not a switch. The useful question is never "is it an agent?" but "which decisions does the model own?"

The patterns between the two ends

The same article names five workflow patterns and then the autonomous agent. Knowing them by name lets you answer "what else could you have used?" in one sentence. The Harbourline column shows that each has a natural home in the AI programme.

Orchestrator-workers sits on the border: the model decides the subtasks, but code still owns the structure that runs them. Anthropic's advice for choosing among all six is blunt: start with the simplest option, and add agentic behaviour only when the simpler one measurably falls short, because agents "often trade latency and cost for better task performance".

Five questions that decide it

1. Can you draw the path before you see the input? If a senior adjuster can sketch the steps for every input on one page, write the sketch as code. The model then does what it is good at inside each box, and you keep the boxes. If the honest answer is "it depends on what the customer says next", the path is not knowable and you need the model to choose.

2. What does a wrong step cost, and can it be undone? Look up a payment status wrongly and the customer asks again. Approve a payout wrongly and you have a regulatory problem. The rule is to let the model own reversible, low-cost decisions and keep irreversible or regulated ones in code. A wrong coverage decision is the case Harbourline cannot afford, so the coverage check is a step that always runs; it is never a tool the model may skip.

3. Must you explain what happened? The trace of a workflow is its diagram: step 3 ran, produced X, so step 4 ran. The trace of an agent is a transcript someone has to interpret. When a regulator or a complaints handler asks why a claim went to a given queue, "the model chose" is a weak answer. The audit-trails chapter covers what to record.

4. What are the latency and cost budgets? A three-step workflow makes three calls. An agent makes however many calls the task needs, and they run one after another. A customer waiting in chat tolerates that for a hard question and not for a payment status. A nightly job tolerates anything but the bill.

5. How often does the task shape change? Every new request type forces a code change in a workflow. If product adds a new kind of request each week, a model with a good tool set absorbs it with a prompt change. If the shape has been stable for two years, the flexibility buys nothing.

The worked answer on Harbourline

Claims intake. About 6,000 new claims arrive a day, and they follow one shape: receive the first notice of loss, extract the facts, check the record is complete, check coverage, route to an adjuster. Apply the five questions. The path is knowable. A wrong coverage decision is a regulatory issue. The routing must be explainable. Volume makes per-claim cost matter. So the skeleton is a workflow, and the code owns the order.

One step does not fit that mould. "Ask for missing information" depends on the peril: a water-damage claim needs the date the leak started and whether the water was shut off, a theft claim needs a police reference, and the customer's replies are free text. That step is a bounded agent. It has two tools, one to message the customer and one to record a field. It has no coverage tool and no routing tool. It has a cap on model calls. When it ends, the code takes over, and if fields are still missing the code sends the partial packet to a human adjuster.

Here is the skeleton as a sketch. The point is where each decision sits.

# Sketch: a deterministic skeleton with one bounded agentic step.
# extract_facts, required_fields, coverage_check and route are ordinary functions.
MAX_CALLS = 6                     # hard cap on model calls inside the agent step

def handle_fnol(claim):
    facts = extract_facts(claim)                       # one schema-checked model call
    missing = required_fields(facts.peril) - facts.known()
    if missing:
        facts = ask_for_missing(claim, facts, missing)  # the only open-ended step
    verdict = coverage_check(claim.policy_id, facts)    # always runs; model cannot skip it
    return route(verdict, facts)                        # table lookup; no model involved

def ask_for_missing(claim, facts, missing):
    tools = [SEND_MESSAGE, RECORD_FIELD]               # no coverage tool, no routing tool
    messages = [{"role": "user", "content": brief(claim, facts, missing)}]
    for _ in range(MAX_CALLS):
        reply = client.messages.create(model=MODEL, max_tokens=500,
                                       tools=tools, messages=messages)
        if reply.stop_reason != "tool_use":
            break                                      # the model says it is done
        messages += run_tools(reply, facts)            # code executes the tool calls
        if not (required_fields(facts.peril) - facts.known()):
            break                                      # code decides it is done too
    return facts                                       # may still be incomplete

# If facts are still missing, route() sends the packet to a human adjuster
# with the partial record, rather than letting the loop run on.

The customer-service chat. About 40,000 sessions a day, and the customer can ask anything: a payment date, a change of address, a question about a clause, a complaint. The path is not knowable, so this is an agent. What keeps it safe is the boundary around it. Read tools run freely. Write tools stage a request that the customer must confirm in the interface. Coverage decisions are not in its tool list at all. Chapter 06 builds that boundary.

Where the recommendation flips. If a month of chat logs shows that 85% of sessions are three intents (payment status, policy document request, address change), route those three to small workflows and keep the agent for the tail. You pay agent latency and cost only where the open-ended behaviour earns it. Measure the intent mix before you decide. Do not guess it.

The hybrid, and how it moves

Most production systems end up as a deterministic skeleton with bounded agentic steps. The rule for placing the boundary: the model chooses among options that code supplies, and code decides whether a step happens at all. Money, compliance gates and ordering live in code. Open-ended language and variable fields live with the model.

The boundary moves in both directions, and both are normal. Teams often start with an agent to learn what the task really looks like, then read the traces. When 80% of runs take the same five steps, they freeze those steps into a workflow and keep the agent for the rest. The other direction starts with a workflow, finds a slice where the fixed path fails on the eval set, and promotes that one step to a bounded agent. Either way the evidence is traces and an eval set, not preference. The evals chapter and chapter 08 cover how to collect that evidence.

Frameworks deserve one warning. Anthropic's article notes they speed up a start but add layers that obscure the prompts and responses and make debugging harder. In an interview, say you would begin with the model API directly and adopt a framework only for a feature you can name.

Interview probes

These are the follow-ups that come next. Answer each aloud before opening it.

✓ Check yourself

Answer from memory before opening each one.

1. Two teams both say they built "an agent" for refund requests. One team's code calls the model once to classify, then runs a fixed approval routine. The other runs a loop in which the model picks from six tools. Which team built an agent, and what changes for testing and for cost?

   Show answer

   Only the second team. The first built a routing workflow, because code decides every next step. The workflow has a fixed call count, so you can unit-test each step and price it up front. The agent has a variable call count and a distribution of paths, so you test with an eval set and budget with caps. See who decides the next step.

2. A ten-step agent run has a per-step success rate of 98%. A colleague says that is "basically perfect". What is the chance the whole run is right, and what does that imply about where you let the model choose?

   Show answer

   About 82% (0.98¹⁰). One run in five fails somewhere, and the failures compound because later steps build on earlier mistakes. So limit the number of model-chosen steps on the critical path and put checks between them. See error compounding.

3. You inherit a claims agent that decides for itself whether to call the coverage tool. In testing it skipped the tool on 2% of claims that looked obviously covered. A teammate proposes adding "always check coverage" to the system prompt. What do you do instead, and why is the proposal weaker?

   Show answer

   Move the coverage check into code so it runs on every claim and the model cannot skip it. A prompt instruction lowers the skip rate but leaves it above zero, and a regulatory control needs a guarantee, not a rate. The tempting fix treats a control as a preference. See the five questions.

4. Harbourline's chat logs show 70% of sessions are payment status, policy documents or address change, and the rest vary widely. Describe the design you would propose and the measurement you would run first.

   Show answer

   Split by intent: classify first, send the three common intents to small workflows, and send the tail to the agent. Measure first that the classifier separates the intents accurately on a labelled sample, since a misroute sends a hard question to a workflow that cannot answer it. If the classifier is weak, a single agent with those three as fast-path tools is the safer start. See the worked answer.

5. An interviewer says "agents are the future, why are you hedging with workflows?" How do you answer without sounding defensive?

   Show answer

   Agree that model capability is moving the boundary, then restate your rule: the model owns decisions that are reversible and open-ended, code owns decisions that are regulated or must be explained, and an eval set decides when a step moves. The answer shows you have a method for moving the boundary, which is stronger than a position. See the hybrid.

Takeaway

• A workflow is code choosing the next step and an agent is the model choosing it; the useful question is which decisions the model owns.
• Choose by five properties: whether the path is knowable, the cost of a wrong step, the need to explain it, the latency and cost budget, and how often the task shape changes.
• Regulated and irreversible steps belong in code, where they run every time, not in a prompt that asks the model to run them.
• The common production shape is a deterministic skeleton with bounded agentic steps, each with a call cap, a small tool list and a defined handover.
• Harbourline's claims intake is a workflow with an agent inside "ask for missing information"; its customer chat is an agent behind hard tool boundaries.
• The boundary moves with evidence from traces and an eval set, and it should move in both directions.

Next, the claims design in full, with a token budget it must stay inside. → A Claims Agent Under a Token Budget

Further reading

• Building effective agents: Anthropic engineering, December 2024. The workflow and agent definitions, the five patterns and the advice to start simple.
• Tool use with Claude: Anthropic documentation. How the tool-use loop works, including tool_choice and parallel calls, so you can say what the loop does.
• Effective context engineering for AI agents: Anthropic engineering, September 2025. Why long agent runs degrade and the lightest fixes: clearing old tool results, notes, sub-agents.