From 'Stacking Agents' to Verifiable Delivery: Rethinking Anthropic's Effective Agent Framework

In Anthropic's 2024 paper "Building effective agents," a decision-making framework is provided that remains valuable. It's important to note the boundaries: the original paper indicates that the ecosystem of tools listed has changed since publication. Therefore, this article treats it as an architecture decision-making guide rather than an SDK implementation manual.

Differentiate: Workflows Are Not Agents

Both link models, tools, and context, but differ in "who decides the next step."

• Workflow: Paths are predefined, with the model making decisions or generating output at fixed stages. This approach is more predictable, easier to evaluate, troubleshoot, and control costs.
• Agent: The model autonomously decides the next step, which tool to use, and when to finish based on environmental feedback. Suitable for tasks where the path can't be predefined, but requires stricter permissions, budgets, and human checkpoints.

This differentiation avoids a common misconception: multiple LLM calls do not automatically equate to an Agent. When refund, classification, or data query branches are predetermined, turning them into observable workflows is generally more reliable than allowing the model to "freely plan."

Starting from the Simplest Plan

The recommended starting point is not a multi-agent setup but a well-optimized model call: clear task instructions, a few high-quality examples, and retrieval, memory, or tools as needed. Only when it fails to reliably fulfill tasks should you incrementally add structure.

The key isn't memorizing pattern names but recognizing "complexity" as a capability to be purchased with evidence. If two additional calls don't improve pass rates, human rework, or completion time, it's better to backtrack rather than stack more components.

Select Structure by Task Features, Not Buzzwords

Start diagnosing with four questions.

1. Can the path be pre-written? If so, prioritize workflows; if not, and task differences are significant, consider model-driven dynamic breakdown.
2. Are results verifiable? The more reliable environment "truths" like automated tests, field verification, citation checks, and state reads are, the more suitable for systems to execute multiple rounds.
3. What is the cost of errors? When tasks involve payments, deletions, external communications, or production changes, it's crucial to narrow tool permissions and pause at human approval points.
4. Does the benefit outweigh the cost? Examine success rates, end-to-end timing, task cost per session, human takeover rates, and failure reasons together. Judging solely on whether model output "looks smart" may mislead decisions.

For instance, a customer service entry can route "order inquiry," "technical issue resolution," and "refund request" separately, with fixed verification and human authorization for refunds. There’s no need to grant models the ability to act freely from the start. In contrast, when localizing issues across multiple warehouses, modifying code, and rerunning tests repeatedly, it’s difficult to predict which files need to be read and how many rounds of repairs are needed, making agents with clear test feedback and stopping budgets genuinely valuable.

Reliability Comes from Control Layers, Not Greater Autonomy

The core loop of an open-ended agent is simple: the model proposes actions, the tool returns environmental results, and the model adjusts the next step accordingly. But production systems must add control layers outside of the loop:

• Define verifiable completion conditions for each task rather than just "try to solve it";
• Set limits on rounds, time, cost, tool calls, and retries;
• Log tool returns, key decisions, failures, and human pickups as traceable events;
• Enable high-risk actions through minimal permissions, parameter verification, sandboxing, and human approval;
• Allow the system to stop and request information when stalled, conflicting, or lacking evidence instead of fabricating progress.

This also explains why "tool interfaces" often deserve more investment than overall prompt terms. The essence of tool names, parameters, examples, input constraints, and error messages forms an operating interface for models to use the external world. When interfaces are vague, models can easily choose wrong actions or recover incorrectly from failures.

Pre-Evaluate to Determine If Agents Are Really Needed

Before increasing autonomy, prepare a task set covering real business boundaries: normal cases, fuzzy inputs, missing data, conflicting data, tool failures, and high-risk requests. Then compare the same metrics across different schemes: task completion rates, human correction rates, average delay, call costs, number of risky actions, and whether failures are recoverable.

If a fixed workflow already consistently meets targets, replacing it with an agent will likely only increase operational burden. Only when real task steps and tool choices cannot be pre-enumerated, and the system can obtain reliable feedback through testing, result retrieval, database state, or human review, is the agent's flexibility worth the cost.

A Practical Suggestion for AI Agent Projects

We prefer transforming agent design from "drawing a complex architecture diagram" to a decision record: why tasks can't be accomplished with simpler solutions, which tools are allowed, what evidence counts as completion, when to hand over to humans, and how additional complexity proves effective through metrics. Doing so makes architecture easier to evolve: first go live with an observable workflow, and then let data decide whether to upgrade a section to dynamic orchestration, rather than assuming autonomy is the default setting.

A truly effective agent isn’t the system that can call the most tools, but the system that can deliver consistently, be verified, and maintained within clear boundaries.