Building Effective AI Agents: A Reference on the Five Workflow Patterns and Agents

• Introduction — Workflows, Agents, and the Augmented LLM
• The Five Workflow Patterns
• Autonomous Agents — the Loop, and When to Reach for It
• Failure Modes — Over-Engineering, Runaway Loops, Cost and Latency
• Frameworks — a Fast Start, a Debugging Tax
• Closing — Simplicity, Transparency, ACI
• References

Introduction — Workflows, Agents, and the Augmented LLM

While the word "agent" inflates, Anthropic's engineering guide Building Effective Agents starts from a rare, calm set of definitions. This post reorganizes that guide into a reference you can pull up while building. One distinction sits at the center.

• Workflow. A system where LLMs and tools are orchestrated through "predefined code paths" (Anthropic). The flow is fixed by the developer.
• Agent. A system where an LLM dynamically directs its own processes and tool usage, keeping control over how it accomplishes the task. The flow is decided by the model at runtime.

A single piece of advice runs through the whole document: build not the most sophisticated system but the right system for your needs. Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.

Beneath every pattern sits the augmented LLM — not a model that just emits text, but one equipped with three capabilities.

• Retrieval. It generates its own search queries to pull in the information it needs.
• Tools. It selects the right tool for the task and takes real actions on external systems.
• Memory. It decides what to keep and what to drop as it carries state forward.

For tool integration the guide points to standards like the Model Context Protocol (MCP). This block is the atomic unit of everything below.

The Five Workflow Patterns

First thing to internalize: all five below are workflows. Even when several LLM calls appear, their order and wiring are fixed in code. Autonomous agents are a separate section.

The table is for quick reference; here is one line each on how the patterns actually run.

• Prompt chaining. Split the task into sequential steps where each LLM call takes the previous output as input. Programmatic gates (format or condition checks) between steps stop a bad output from leaking downstream. Latency rises, but keeping each call focused on one thing raises accuracy.
• Routing. Classify the input first, then send it to a dedicated prompt or model. Separating concerns lets you optimize each path independently and avoids the quality loss of cramming every case into one prompt.
• Parallelization. Sectioning runs independent subtasks at once to cut latency; voting runs the same input several times and aggregates (majority or consensus). It shines when you need to pull apart things that interfere in one call — like separating answer generation from a safety screen (guardrails).
• Orchestrator-workers. A central LLM breaks the problem into subtasks at runtime, delegates them to workers, and synthesizes the results. The decisive difference from parallelization is that the model, not the code, decides how many subtasks and of what shape — which is why this pattern sits right at the border between workflow and agent.
• Evaluator-optimizer. One LLM drafts while another evaluates and gives feedback in a loop. It pays off only when evaluation criteria are clear and iteration genuinely improves the result — if the criteria are fuzzy, the loop just burns cost.

Finally, the five are not mutually exclusive. Real systems usually compose them — routing followed by a prompt chain, or an orchestrator whose workers run in parallel. The patterns are Lego bricks, not a religion.

Autonomous Agents — the Loop, and When to Reach for It

Autonomous agents look elaborate but are usually simple to implement. In Anthropic's framing, an agent is essentially an LLM using tools in a loop based on environmental feedback. At each step it gains "ground truth" — tool results, code execution output — and judges its own progress from that.

Agent loop (concept)
  1. A human gives a goal (or narrows scope through discussion)
  2. The LLM plans, then calls a tool
  3. The environment returns a result   = ground truth
  4. The LLM inspects it and decides: done? or loop back to step 2
  5. Stopping conditions: completion check, step budget, human checkpoint

The crux here is ground truth. What separates an agent from a plain chatbot is that it corrects its own judgment at each step from real signals in the environment — did the tool succeed, did the code pass. Without that feedback loop, it is just a prompt called several times.

When to use an agent instead of a workflow. For a well-defined task where predictability and consistency matter, a workflow wins. An agent earns its keep only when you cannot predict the number of steps and cannot hardcode a fixed path. There is a price: the guide states plainly that agentic systems "trade latency and cost for better task performance." Reach for one only when that trade makes sense. A quick decision checklist:

• Can you sketch the steps and the path in advance → then a workflow.
• Do consistent, reproducible results for the same input matter → workflow.
• Do the required tools and steps vary per input, defying prediction → agent.
• Can the added latency and cost be justified by the performance gain → if not, defer the agent.

The ACI is half the job. An agent's success depends heavily on tool design. Anthropic calls this the agent-computer interface (ACI) and stresses documenting and testing tools as carefully as you would document an API for a human. Ambiguous schemas and thin tool descriptions are the most common root cause of agent failures.

The appendix names two domains where agents fit well. Customer support follows a conversation flow while needing external information and actions (lookups, refunds), and success is clearly measurable through resolutions — some companies are confident enough to charge usage-based pricing only for successful resolutions.

Coding fits especially well because solutions are verifiable through automated tests; the agent iterates using test results as feedback, and Anthropic cites solving real GitHub issues in SWE-bench Verified from the pull request description alone. Even so, human review remains crucial to ensure a solution fits broader system requirements.

Failure Modes — Over-Engineering, Runaway Loops, Cost and Latency

A reference is only useful if it records where things break, not just where they work.

• Over-engineering and premature frameworks. Reaching first for a heavy agent framework is the most common mistake. Frameworks make it easy to start, but the guide warns they add abstraction layers that obscure the underlying prompts and responses, making debugging harder. Start by using the LLM API directly, and add complexity "only when it demonstrably improves outcomes."
• Runaway loops. An agent is a loop by nature, so without stopping conditions it repeats the same mistake while burning tokens and cost. Always add a step cap, a timeout, and human checkpoints. Transparency — surfacing the planning steps — catches these runaways early.
• Cost and latency. Every step is another LLM call. Multi-agent setups and voting spend tokens at a multiple. Measure against your user-facing latency budget first — better task performance is worthless in a product if the response arrives too late.
• Neglecting tool design. If you do not treat the ACI with the same care as your prompts, even a strong model flounders in front of badly designed tools.
• Skipping evaluation. Layering on agentic complexity without measuring whether it actually beats the simple baseline. The guide's prescription is explicit — optimize simple prompts with comprehensive evaluation, and add complexity only when simpler solutions fall short.

Frameworks — a Fast Start, a Debugging Tax

The guide addresses agent frameworks head-on. SDKs like the Claude Agent SDK and GUI builders like Rivet and Vellum lower the barrier to starting, but there is a cost — they add abstraction layers that obscure the underlying prompts and responses, making it harder to see what actually goes into and comes out of the model, and complicating debugging.

So the recommendation is plain: use the LLM API directly to understand the fundamentals first, then adopt a framework once you know exactly what its abstraction does for you. This is not a claim that frameworks are bad; it is that convenience layered on top of a base you do not understand tends to trip you up precisely when something breaks.

Closing — Simplicity, Transparency, ACI

The guide's three core principles for implementing agents make a clean summary.

• Simplicity. Keep the design simple, and add complexity only when it demonstrably improves outcomes.
• Transparency. Do not hide the agent's planning steps; show them explicitly.
• ACI. Craft the agent-computer interface carefully through thorough tool documentation and testing.

The working lesson is plain. Most production problems are solved well enough by a single LLM call or one or two workflow patterns. The moment you genuinely need an autonomous agent is rarer than it sounds, and recognizing that rarity is itself good engineering. Success is not about building the most sophisticated system but about choosing the right one for the need — that single sentence is the whole point of this reference.

References

• Anthropic — Building Effective Agents (engineering guide, primary source)
• Anthropic Cookbook — patterns/agents (minimal implementations of the five patterns)
• Model Context Protocol — Introduction (standard for tool integration)