When Should You Use an Agent?

Mission

By the end, you can choose among ordinary code, a model call, a workflow, and an agent using task evidence—not fashion.

Prerequisite: Chapter 1.1. Build artifact: a one-page architecture decision memo. Time: 50-65 minutes.

Before you read: Predict → Commit → Connect

Northstar receives: “My conference moved. Find a sensible Friday alternative, but do not change anything.” The request may require interpreting “sensible,” checking policy, searching several options, and comparing trade-offs.

Choose one before reading:

• a fixed script;
• one model response;
• a predefined workflow with model steps;
• an agent loop.

Write the strongest reason your choice could be wrong.

Start with the uncertainty, not the technology

Use ordinary software where rules are knowable. Use a model where an input or output is fuzzy. Use a workflow where the sequence is knowable. Consider an agent only where the next useful step depends on information discovered during the task and enumerating all paths is impractical.

That yields a simple ladder:

The final branch matters. Some tasks are unsuitable for current automation. “Use a human” is a valid architecture choice.

The agent-shaped task

An agent becomes plausible when several properties appear together:

1. The goal is clear, but the path is not. “Find three policy-supported alternatives” is a goal; which searches and comparisons are needed varies.
2. Feedback is available. Tool results, tests, validators, or people can show whether a step helped.
3. Actions can be bounded. The system has a small, typed action set rather than unrestricted computer access.
4. Progress can be judged. Success, failure, uncertainty, and “done” have observable signals.
5. Errors are recoverable. A bad search query is cheap; an irreversible transfer is not.
6. The value covers the reliability tax. Extra latency, cost, evaluation, security, and operations are justified.

Good early domains often involve investigation, triage, drafting, or analysis with review. Poor early domains combine weak feedback, irreversible consequences, adversarial inputs, and vague ownership.

Task-level classification beats job-level classification

“Automate customer support” is too broad. Decompose the job:

The agent may coordinate safe pieces. It should not absorb rules that conventional code can enforce better.

The deterministic envelope

Place model judgment inside a deterministic envelope:

• conventional code authenticates the caller;
• authorization code limits accessible records;
• typed schemas constrain proposed actions;
• validators enforce business invariants;
• approval gates protect consequential changes;
• budgets stop runaway loops;
• transaction services execute narrow writes;
• immutable records support investigation.

The model handles ambiguity. The envelope handles authority.

Compare architectures by failure economics

Accuracy alone is insufficient. Ask what a failure costs and how quickly it is detected.

A useful pair of approximations is:

Expected loss per task = probability of a harmful error on one task × impact per harmful error.

Expected loss before detection ≈ expected loss per task × number of tasks exposed before detection.

Keep the units explicit: exposure changes the expected loss over a detection window, not the loss of one task. These are not promises of precision; segment different harms instead of hiding them inside one average. A research assistant that occasionally chooses an unhelpful search may recover. A payroll agent that occasionally sends an unauthorized payment creates unacceptable loss even at a much lower error rate.

Also count the reliability tax:

• more model calls and tool calls;
• longer and more variable latency;
• larger attack surface;
• non-deterministic behavior;
• harder reproduction and debugging;
• evaluation and monitoring work;
• human review and incident response;
• vendor and model-change risk.

If a four-step workflow achieves the same outcome, an agent loop rarely wins.

A practical scorecard

Score each factor 0, 1, or 2. This is a discussion aid, not a scientific law.

An agent candidate usually needs high path uncertainty and value of adaptation plus strong feedback, reversibility, measurability, and narrow permissions. Do not simply total the columns; a zero on safety can veto the idea.

Red flags: do not begin with an autonomous agent

Pause or redesign when the task has:

• an irreversible action with no approval or rollback;
• legal, medical, employment, credit, safety, or financial consequences without qualified oversight;
• access to many unrelated systems “just in case”;
• no representative test set;
• success defined as “looks intelligent”;
• no accountable product and operations owner;
• adversarial public input reaching privileged tools;
• a requirement to reveal private reasoning or sensitive traces;
• a business case that assumes near-perfect behavior;
• a simpler rule or workflow that has not been tested.

The answer may be a read-only copilot, a proposal generator, a deterministic workflow, or a human process improved with retrieval.

I do: Friday travel alternatives

Return to the opening request. The customer asks for options but forbids changes.

1. Explicit rules? Policy and price rules can be coded, but “sensible alternative” is contextual.
2. One model call? It cannot know live availability without tools, and one search may return poor options.
3. Known workflow? Search Friday, filter policy, rank results could work for ordinary cases.
4. Need adaptation? If there are no direct options, the system may search nearby airports or ask whether an overnight connection is acceptable.
5. Can we bound it? Read-only search tools, allowed date window, maximum queries, no booking tool, cited output.

Decision: first ship a workflow for common cases. Route “no acceptable result” to a small read-only agent that may revise searches and ask one clarification. The agent earns its complexity only on the uncertain tail.

This hybrid is common: deterministic trunk, agentic branches.

We do: challenge a seductive proposal

Proposal: “Build an autonomous finance agent that reads all company systems, finds waste, cancels vendors, and moves budgets.”

Rewrite it into a safer first release:

• Goal: identify duplicate or underused subscriptions and produce evidence-backed review packets.
• Inputs: approved billing exports and contract metadata, not unrestricted systems.
• Actions: read, compare, calculate, and draft—no cancellation or fund movement.
• Feedback: deterministic duplicate checks, owner confirmation, finance review.
• Stop: capped records, time, model spend, and ambiguity.
• Success: precision of flagged cases, reviewer time saved, false-positive cost.
• Owner: finance operations with security and procurement partners.

The useful intelligence remains. The unearned authority disappears.

You do: LAB-2 — Architecture decision memo

Pick one candidate task and create a one-page memo:

1. User and job: who is trying to achieve what?
2. Task decomposition: which subtasks are rules, fuzzy transforms, fixed workflows, or adaptive search?
3. Baseline: what is the simplest non-agent solution?
4. Agent advantage: which unpredictable path creates measurable value?
5. Feedback: how will the system know a step helped?
6. Consequences: what can go wrong, and who is affected?
7. Envelope: tools, permissions, validators, approvals, budgets, and rollback.
8. Evaluation: what representative cases and threshold govern release?
9. Decision: no automation, code, model call, workflow, bounded agent, or hybrid.

Ask a skeptical reviewer to disprove the agent advantage. Revise the decision if the baseline wins.

Done when: the architecture follows from task properties and failure economics, not from a desire to use an agent.

Pause & Recall

Without looking back:

1. State the four rungs before “human-led process” in the complexity ladder.
2. What makes a task agent-shaped?
3. What belongs inside the deterministic envelope?
4. Why is a high aggregate score unable to override one safety veto?

Production lens

Roll out authority in stages:

1. offline replay on recorded synthetic cases;
2. shadow mode with no user-visible effect;
3. suggestions reviewed by people;
4. narrow read-only actions;
5. reversible writes with approval;
6. limited automatic writes only after evidence supports them.

Each stage needs a promotion threshold and rollback trigger. Autonomy should be earned by measured reliability, not granted at launch.

Chapter compression

• Use code for rules, a model for fuzzy transformation, a workflow for known paths, and an agent for bounded path uncertainty.
• Decompose jobs into tasks; do not make a whole job agentic by default.
• Put probabilistic judgment inside a deterministic security and transaction envelope.
• Compare expected harm and reliability tax, not demo quality alone.
• A hybrid often places an agent only on the uncertain tail.

Memory hook: Use the least agency that reliably closes the loop.

Retrieval deck

• Q: What is the central signal that may justify an agent?
  A: The next useful step depends on information discovered during the task.
• Q: What is a deterministic envelope?
  A: Conventional controls around model judgment: identity, authorization, schemas, validation, approvals, budgets, transactions, and records.
• Q: What is the simplest useful release strategy?
  A: Begin with offline or advisory behavior and expand authority only after evaluation evidence.
• Q: Why decompose a job?
  A: Its subtasks have different uncertainty and consequence; each deserves the simplest suitable architecture.

Spaced review

• Now: complete the scorecard for Northstar’s request.
• +1 day: reconstruct the decision ladder.
• +3 days: turn one “autonomous employee” pitch into a bounded task contract.
• +7 days: compare an agent and workflow using expected failure cost.
• +14 days: revisit your memo after learning tools and security; record what changed.

Sources and further study

• Anthropic, Building Effective Agents
• NIST AI Risk Management Framework
• NIST AI RMF Generative AI Profile
• OpenAI, A Practical Guide to Building Agents (PDF)