#199 — Building blocks, workflows, and agents

A workflow is a system where you hardcode the exact path the LLM and its tools follow through code — you decide the steps in advance. An agent is a system where the LLM decides its own path and keeps control over execution as the task unfolds . The practical difference: workflows are predictable and cheaper to run, agents are flexible but cost more and carry more risk of compounding errors .

No. Most agentic patterns can be implemented in a few lines of code using raw LLM API calls, and starting there makes debugging far easier than working through a framework's abstraction layers . If you do adopt a framework like the Claude Agent SDK, AWS's Strands, Rivet, or Vellum, read the underlying code first — misunderstanding what's happening under the hood is one of the most common mistakes teams make .

Use an agent only for open-ended problems where you can't predict the number of steps needed and can't hardcode a fixed path, and where you're willing to trust the model's judgment over many turns . For most well-defined, repeatable tasks — support ticket routing, document generation, translation — a workflow or even a single optimized LLM call with retrieval outperforms an agent on cost and predictability .

MCP is Anthropic's open standard for connecting an LLM to a growing ecosystem of third-party tools through a simple client implementation, instead of hand-building every integration yourself . For founders, this means faster tool integration for agents that need to pull data from CRMs, databases, or APIs without custom-coding each connector .

Agentic systems trade latency and cost for better task performance, so agents are inherently more expensive to run than a single well-optimized LLM call . Anthropic's own guidance is to default to the simplest solution and only add the cost and complexity of agents when a simpler approach demonstrably fails to meet the task .

Anthropic's own SWE-bench coding agent resolves real GitHub issues by editing multiple files based only on a task description, and its 'computer use' reference implementation lets Claude operate a computer UI directly to complete tasks . In customer support, some companies now charge customers only for successful resolutions under a usage-based pricing model, signaling real confidence in agent reliability .

Agent failures usually trace back to unnecessary complexity, not weak prompts — adding steps, frameworks, or autonomy that don't measurably improve the outcome . Anthropic's teams found that tool design deserves as much attention as prompt design; a small fix like forcing absolute file paths instead of relative ones eliminated an entire category of agent mistakes in their SWE-bench work .

ACI refers to how clearly you document and structure the tools an agent uses, and Anthropic recommends investing the same effort here that teams typically put into human-facing UI design . Poorly documented tools, ambiguous parameters, or formats the model hasn't seen naturally online (like raw JSON instead of markdown) create avoidable errors regardless of how good the underlying prompt is .

Customer support and coding are the two domains where agents have shown the clearest production value, both sharing conversational interaction, clear success criteria, tight feedback loops, and built-in human oversight . Coding agents benefit from automated tests as objective feedback, while support agents benefit from measurable resolutions and direct access to customer and order data through tools .

Anthropic recommends extensive sandbox testing paired with clear guardrails before any agent touches production, given that autonomy raises both cost and the risk of compounding errors . A practical method is running real inputs through a workbench, observing exactly where the model stumbles on tool calls, and iterating on tool definitions from there .

MCP is Anthropic's open standard that lets an LLM connect to third-party tools and data sources through a single client implementation instead of custom-coding every integration . You don't strictly need it — many agentic patterns work fine with a few lines of direct API code — but it saves significant engineering time once you're integrating more than a handful of external tools .

Sectioning splits one task into independent subtasks that run at the same time, like having one model answer a user query while a separate model screens it for inappropriate content . Voting runs the identical task multiple times to get diverse outputs, such as several prompts independently reviewing the same code for security vulnerabilities and flagging issues by consensus .

They look similar on a diagram, but parallelization pre-defines the subtasks upfront while orchestrator-workers has a lead LLM decide the subtasks dynamically based on the specific input . This matters for tasks like multi-file coding changes, where you can't know in advance how many files need editing or what kind of change each one needs .

Anthropic recommends building in explicit stopping conditions, such as a maximum number of iterations, alongside checkpoints where the agent pauses for human feedback when it hits a blocker or completes a meaningful step . Grounding the agent in real environmental feedback at each step — like actual tool results or code execution output — is what lets it assess its own progress instead of drifting .

Markdown is generally easier for a model to produce reliably than JSON, because JSON requires escaping newlines and quotes while markdown code blocks don't carry that formatting overhead . The broader rule is to pick whatever format the model has seen most naturally occurring in internet text, since anything unfamiliar increases the chance of formatting errors .

Poka-yoke is a manufacturing term for mistake-proofing, and applied to AI tools it means changing parameter design so that errors become structurally difficult to make . A concrete example from Anthropic's own coding agent: requiring absolute file paths instead of relative ones eliminated a whole class of navigation errors once the agent had moved away from the root directory .

Not for well-defined, repeatable processes — those are exactly the cases where a hardcoded workflow beats an agent on cost, predictability, and debuggability . Agents earn their place only on open-ended tasks where the steps can't be predicted in advance and some model judgment is required, which is a narrower slice of automation work than founders often assume .

The source doesn't specify a number, but it stresses that each tool needs a clear, unambiguous purpose with boundaries against other tools — similar to writing a docstring for a junior developer joining your team . Testing real inputs against your tools in a workbench and watching where the model gets confused is the recommended way to find out if you have too many overlapping tools .

SWE-bench Verified is a benchmark where an AI agent resolves real GitHub issues by editing code across multiple files, using only the pull request description as input . Anthropic used it internally to test its own coding agent and found that tool definition quality mattered more to performance than the core prompt .

Some companies charge only for successful outcomes rather than per API call or seat, particularly in customer support where a 'resolution' is easy to define and measure . This outcome-based pricing signals real confidence in the agent's reliability, since the vendor absorbs the cost of failed attempts rather than passing it to the customer .

Yes — even in Anthropic's best-performing use cases, human review remains essential for catching issues automated tests can't, like a coding agent's solution technically passing tests while missing broader system requirements . The recommended pattern is human checkpoints built into the agent's loop, not full unsupervised autonomy, especially before production deployment .