AI agent tools: where bundling stops and what you will not build
Bundle operations into one tool only when no person must see them; the rest become tools you will not build.
Key points
- Bundle only what no person must see
- Keep irreversible ops in their own tool
- Add a will-not-build column to the table
- Re-quote additions outside maintenance
Overview diagram in preparation
Contents
Bundle only the operations no person has to see
A&A perspective
A tool for an AI agent is a function the agent calls part-way through a job, once it has chosen its own steps. Several operations may be bundled into one tool only when no person has to see them part-way through.
From the sources
Anthropic, which develops the Claude models, publishes an engineering article on writing tools for agents. It states that tools should let agents subdivide and solve tasks in much the same way a human would, given access to the same underlying resources.
From the sources
The same article says a tool should at the same time reduce the context that would otherwise have been consumed by intermediate outputs. It names tools that merely wrap existing software functionality, or the API endpoints that call it from outside, as a common error.
From the sources
It also says too many tools, or overlapping tools, can distract agents from pursuing efficient strategies. Overlap is described as something that disturbs the choice of tool, not as something that removes a capability.
A&A perspective
Which steps to pass through as they are, and which to rebuild into one tool, is covered in a separate article by Automate & Augment (A&A), the company writing this one: "AI Agent Quotes from Vendors: Pass Existing APIs or Rebuild the Tools?"
A&A perspective
What this article takes up is the question after that one. Where does the bundling judgement stop? A&A sets that limit by whether a person has to see the operation part-way through.
A&A perspective
If no person has to see them, bundling several operations into one tool removes no place where a person can stop the work. The moment an operation that does need a person is bundled in, that stopping place is hidden inside the tool.
Hypothetical example
Suppose you are building, under contract, an agent that answers billing questions. Today the staff member opens three things before writing a reply: the contract terms, the billing history and the past correspondence.
Hypothetical example
None of those three read operations needs a person to look at it part-way through. Nothing happens to the customer either. The three calls can be bundled into one tool.
Never fold an irreversible operation into the same tool
A&A perspective
An irreversible operation is not folded into the same tool as other operations. Issuing a refund, sending a message to a customer and committing stock are examples. This is where a person stops the work.
A&A perspective
In the example above, you build one tool that reads the contract, the billing history and the correspondence together, and you leave the refund as a separate tool. Reading happens in one breath; only the execution is kept outside.
A&A perspective
Drawing the execution line by whether an action can be undone is covered in A&A's "Letting AI take action: decide by whether you can undo it, not the amount". This article takes up how to cut the work after you have decided to delegate it.
From the sources
The engineering article lists four ways an agent goes wrong: calling the wrong tools, calling the right tools with the wrong parameters, calling too few tools, and processing tool responses incorrectly.
From the sources
It then says that by selectively implementing tools whose names reflect natural subdivisions of tasks, you reduce the agent's overall risk of making mistakes.
A&A perspective
A&A reads the place where a person stops the work as one of those natural subdivisions. The source says nothing about whether an operation can be undone. Drawing the line that way is A&A's own reading.
A&A perspective
Bundling has a cost in the other direction. An operation bundled into one call cannot be stopped part-way. It cannot be partly redone either.
A&A perspective
So the bundling judgement stops where that cost is worth paying. It is worth paying only for operations no person has to see part-way through.
| Operation | Handling | Reason |
|---|---|---|
| Read the contract terms | Bundle | No person has to see it part-way |
| Read the billing history | Bundle | No person has to see it part-way |
| Read past correspondence | Bundle | No person has to see it part-way |
| Issue a refund | Keep in its own tool | Cannot be undone |
| Issue the invoice | Put on the will-not-build side | Cannot be undone; staff issue it from the screen they use |
Add a will-not-build column to the tool table
A&A perspective
The tool table carries a column for the tools you will not build, not only the ones you will. The result of setting a bundling limit shows up on the side of the operations you decided not to build.
From the sources
The engineering article recommends building a few thoughtful tools targeting specific high-impact workflows that match your evaluation tasks, and scaling up from there. It also says careful, selective planning of the tools you build, or do not build, can really pay off.
A&A perspective
A&A takes the view that in contract work this "we will not build it" disappears when it is only spoken. Saying it in a meeting leaves nothing behind: the delivered specification lists only the tools that were built.
A&A perspective
Four columns are added: the name of the tool you will not build, how the work is done instead, why it is not built, and what would be needed if it were. A row whose "how it is done instead" is empty is not a decided row; it is an undecided one.
Hypothetical example
In the billing example, issuing the invoice goes on the will-not-build side. How it is done instead: the agent produces a draft and the staff member issues it from the screen they already use.
Hypothetical example
The reason is that issuing cannot be undone. If it were to be built, it would need an undo procedure for the issue and an agreement on who presses the button. Until those two are settled, the row stays on the will-not-build side.
From the sources
The same article says namespacing, that is grouping related tools under common prefixes, can help delineate boundaries between lots of tools. It gives examples of prefixing by service and by resource.
A&A perspective
A&A reads that prefix as a name the customer can also see. When the prefix matches the customer system it touches, the table alone shows which tool reaches which system.
Re-quote a request for a new tool outside the maintenance scope
A&A perspective
A request that arrives after delivery, asking for one more operation, is re-quoted outside the maintenance scope. It looks like adding one tool, but it is really redrawing the bundling limit.
A&A perspective
If the added operation cannot be undone, the cut of the existing tools changes too. The operation has to be taken back out of the tool that read everything in one breath.
From the sources
Lindy is a company whose product builds AI agents into business work. Its Head of Engineering, Luiz Scheidegger, explains on a case-study page published by Anthropic why they chose their default model.
From the sources
What he names is being able to make better tool calls when dealing with complex workflows such as calendar management and natural language conditions.
A&A perspective
A&A reads this as a practitioner naming tool calls in complex work as a real difficulty. The growth and productivity figures on the same page carry no definition, population or measurement period, so they are not used as a forecast for a small contract business.
A&A perspective
With a will-not-build table in hand, an added request becomes a question of which row to build. The row already carries the reason and what would be needed to build it.
A&A perspective
From there the acceptance criteria and the maintenance scope can be settled again together. When an operation arrives that is not in the table, the row is added first and the limit is judged again.
A&A perspective
A&A has not measured the relation between tool granularity and the number of defects or hours of maintenance after delivery. It offers no guide to how many tools there should be. What can be said here stops at making a place to write the line down.
Summary
A&A perspective
Operations may be bundled into one tool only when no person has to see them part-way through. An irreversible operation is not folded into the same tool as the others.
A&A perspective
The tool table carries a will-not-build column, with how the work is done instead, why it is not built, and what would be needed if it were.
A&A perspective
A request that arrives after delivery is handled as a row of that table and re-quoted outside the maintenance scope.
Operations may be bundled into one tool only when no person has to see them part-way through. An irreversible operation is not folded into the same tool as the others. The tool table carries a will-not-build column, with how the work is done instead, why it is not built, and what would be needed if it were. A request arriving after delivery is handled as a row of that table and re-quoted outside the maintenance scope.
FAQ
Will a will-not-build list make us look like a contractor that cannot deliver?
Every row also states how the work is done instead, so the row describes a route rather than a refusal. It carries what would be needed to build it as well, so the customer can decide on the spot whether to add it.
How many tools should an agent have?
No number is offered here. The source recommends an order rather than a count: start with a few tools and scale up from there. What you decide is not the number but the range of operations that may be bundled.
Is it wrong to pass an existing API straight through?
If a step finishes in one operation and returns little information, passing it through is fine. What this article takes up is where to stop once you have decided to bundle. Choosing between passing through and rebuilding is covered in a separate article.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Writing effective tools for AI agents
Anthropic · 2025-09-11
Accessed 2026-10-25 - Lindy empowers teams to scale with AI Agents powered by Claude
Anthropic · undated case-study page; no visible publication date
Accessed 2026-10-25