When not to use agents

An architect’s most useful agent skill is knowing when not to build one. Anthropic’s guidance draws a clear line:

• A workflow runs LLM calls and tools along paths your code defines.
• An agent lets the model decide its own steps and tool use, in a loop, based on what it observes.

Agents trade latency, cost and predictability for flexibility. That’s a good trade only when you can’t write the steps down in advance. Start with the simplest thing that works. Often that’s a single well-prompted call with the right context retrieved, and you add complexity only when it measurably helps.

The ladder of complexity

Rung	Shape	DevOps example
Plain code	No model at all	terraform fmt -check, a jq filter, a regex alert rule
Single call	One prompt with retrieved context	Summarise a failed job log for the PR
Prompt chaining	Fixed sequence of calls, with code checks between them	Extract changes from a plan, then a gate, then draft release notes
Routing	Classify, then send to a specialised path	Alert: billing, infra, or app on-call runbook
Parallelization	Independent sections at once, or the same task N times and vote	Review security, cost and tests separately; three runs on “is this a breaking change?”
Evaluator–optimizer	One call drafts, another critiques, loop to a bar	IAM policy draft, then least-privilege critique, then revise
Orchestrator–workers	The model splits work at run time (lesson 3)	Triage across whichever services a deploy touched
Autonomous agent	Open-ended loop with tools	“Find why p99 latency doubled and propose a fix”

In Anthropic’s terms every row except the last is a workflow pattern, even orchestrator–workers, although there the model already chooses the split. The lower rungs are predictable, testable and cheap to run in CI. Climb a rung only when the one below demonstrably fails.

Signals that you don’t need an agent

• You can write the steps down. If the runbook is a fixed sequence, encode it as a pipeline and use the model only for the judgment steps.
• The answer must be deterministic or auditable. Compliance checks, policy gates and cost thresholds belong in code. You don’t want “the agent felt it was fine”.
• It’s a single transformation. Classify, extract or summarise means one call, maybe with structured output.
• Mistakes are expensive and hard to undo. Errors compound across agent steps. The more autonomous the loop, the more you need sandboxing, caps and human gates. Sometimes it’s cheaper not to loop at all.
• Latency matters. A chat-ops command that must answer in two seconds can’t afford ten tool round-trips.

Signals that you do

• The number of steps can’t be predicted from the input.
• The task needs feedback from the environment: run the tests, read the error, try again.
• You can verify the outcome (tests pass, the plan is clean, the alert clears), so autonomy is checked by something real.
• The work runs in a sandbox with stopping conditions and human checkpoints.

Recap

• Workflows follow code-defined paths. Agents choose their own steps.
• Prefer, in order: plain code, a single call, a workflow pattern, and only then an agent.
• Workflow patterns: prompt chaining, routing, parallelization (sectioning or voting), orchestrator–workers and evaluator–optimizer.
• Use an agent when the steps are unpredictable, feedback-driven and verifiable, and keep it sandboxed, capped and gated.