In “Building Effective Agents,” Anthropic published what it has learned building systems on language models. The main point is blunt: the most successful systems use simple, composable patterns instead of heavy frameworks. If you want to get building AI agents right, start with that distinction.
Workflow versus agent
Anthropic splits the field into two approaches:
- Workflow: models and tools are steered along paths you already wrote in code.
- Agent: a dynamic system where the model itself decides how to plan, when to call tools, and how the work proceeds.
The difference is not just wording. The choice hits cost, latency, and how reliable the system is.
When should you use an agent?
Pick the simplest architecture that can do the job. Agent systems usually cost more and take longer.
For defined, repeatable work, a single model call with retrieval — or a linear workflow — is often cheaper and more stable. Agents fit better when the problem is open and you need flexibility and decisions in the moment.
Skip extra frameworks
SDKs and agent toolkits look simpler on the surface, but their abstraction layers usually make debugging harder. Anthropic’s advice is to start with the model API itself, and only reach for a framework once you understand the architecture underneath it.
Five core workflow patterns
Underneath these systems is an augmented language model wired to tools, memory, and data. Five patterns show up again and again:
1. Prompt chaining
The job is split into sequential steps. The first model’s output becomes the next model’s input. It fits decomposable work such as writing a draft, then translating or editing it.
2. Routing
The input is inspected and sent to the right subprocess. A common use is sending simple jobs to a lighter model and harder ones to a stronger model.
3. Parallelization
Tasks run at the same time. Either you split one job into independent subtasks, or you run the same job several times and compare outputs to raise accuracy.
4. Orchestrator-workers
A central model analyses the problem dynamically, breaks it into subtasks, hands them to worker models, and merges the results. This helps when the subtasks are not known in advance.
5. Evaluator-optimizer
One model produces content; a second model critiques and revises it in a feedback loop. It works well when the evaluation criteria are clear — literary translation, or tightening code, for example.
Designing autonomous agents
After the user gives an instruction, agents plan and run on their own. They succeed when they keep getting real signals from the environment — code output, or an API response.
Because they act on their own, chained errors are a real risk. Test them in an isolated environment, and set stop conditions such as a limit on the number of steps.
Where they actually work
Agents have shown decent results in two areas:
- Customer support: conversational work that has to keep pulling from a knowledge base or a user database.
- Coding: software problems where the agent can write code, run tests, and fix the code from the errors it sees.
Tool engineering
The tools a model calls matter as much as the prompt:
- Give the model room to think before it calls a tool.
- Shape tool inputs and outputs like the data the model was trained on. Passing code as Markdown often works better than dense JSON.
- Constrain tools so the model cannot misuse them easily. Requiring absolute file paths instead of relative ones, for example, keeps it from getting lost in directories.
Three principles
- Simplicity: start with basic prompts. Build a multi-step architecture only when the simple path fails.
- Transparency: the agent’s planning steps should stay visible and traceable.
- A careful agent-computer interface: tools need clear docs, a simple structure, and real tests.
Success is not the most complex system. It is the right system for a real need.