Why should agent tools be atomic rather than composite, and what goes wrong when a tool tries to do too much?
Explain the principle that agent tools should be atomic. Describe two problems that arise from composite tools (tools that bundle multiple operations together).
Atomic tools do exactly one thing, so the agent gets one Observation per step. That makes failures easy to attribute and retries safe to repeat.
Imagine teaching a new cook by handing them recipe steps. If you give one giant card that says cook the whole meal and it goes wrong, you have no idea which part failed, and redoing it might burn the parts that were already fine. Now give them small cards instead: chop the onion, boil the pasta, add the sauce. When one card fails, you know exactly which step broke, and you redo only that step without ruining the rest. Agent tools work the same way. A tool that does one clear thing returns one clear result, so the agent can look at it, understand what happened, and decide the next move. A tool that bundles five things together returns one fuzzy result, and the agent is left guessing what actually went right or wrong.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
An atomic tool is a tool that performs exactly one operation, with clearly typed inputs and one clearly typed output. A composite tool bundles two or more operations behind a single call, for example a search_and_summarise tool that runs a web search and then summarises the hits, or a fetch_and_update_db tool that reads a record and writes a change in one shot.
The reason granularity matters so much is that the agent loop is fundamentally a sequence of observe-reason-act steps, where each tool call produces one Observation the model inspects before choosing its next action. The shape of your tools therefore decides the shape of the signal the model gets back. Atomic tools give the model one clean result per decision. Composite tools collapse several operations into one murky result, and that murkiness is where production agents quietly fail.
What atomic means, and why it maps onto the loop
Atomic does not mean trivial. It means single-purpose and independently meaningful: one operation that has a name you can say in a few words, a schema you can specify precisely, and a result the model can reason about on its own. A search(query) tool is atomic. A write_record(id, fields) tool is atomic. A search_and_summarise(query) tool is not, because it hides two distinct operations behind one entry point.
The agent loop reasons one Observation at a time. On each turn the model reads the running state, emits a tool call, and then waits for the result before deciding the next move. This is the whole point of an agent over a fixed chain: the next step depends on what the last step actually returned.
When a tool is atomic, the model gets fine-grained control. It can search, look at the hits, decide they are off topic, and search again with a better query, all before spending a token on summarisation. A composite tool takes that decision away. The model commits to the whole bundle up front and only finds out at the end whether anything went wrong.
This maps directly onto the single-responsibility idea from ordinary software design, but the payoff is different. In normal code the benefit is readability and testability. In an agent the benefit is decision quality, because every tool boundary is also a point where the model is allowed to think. Coarsening a tool removes a thinking point. Each operation you fold into a bundle is a branch the model can no longer take based on what it just saw.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- The Model Context Protocol (MCP) ecosystem favours small single-purpose tools with typed schemas, so a host like Claude Desktop can compose servers without ambiguous composite calls.
- Anthropic's tool use guidance and the Claude Opus 4.7 function-calling API push descriptive names, precise input schemas, and structured error returns so the model selects correctly.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you decide the right granularity for a tool when the operations are sometimes used together and sometimes separately?
Make each independently nameable, independently retryable operation its own tool, and add a thin composite only when a failure between steps leaves an invalid state. Measure tool-selection error rate and trace which tools the model actually chains before adding bundles.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Bundling many operations into one tool to save round trips, then losing the ability to tell which internal step failed or to retry one step safely.
60 second bullets to scan on the way to the call.
What separates an atomic tool from a composite one
How error attribution collapses inside a composite call
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.