Build1 publisher2 min readPublished Updated
A return-policy question routes to either of two tools depending on how it is phrased
A dev.to post puts the fragile layer of a multi-tool agent in the choice between two tools that both fit the request, and argues that better tool descriptions plateau because the ambiguity belongs to the request itself.
The Engineer · Build desk
What happened
- A dev.to post puts the fragile part of a multi-tool agent in the routing step, the decision about which tool a request calls for, and says development usually treats that step as trivial.
- Tool-calling demonstrations use requests where exactly one tool is obviously correct, with "book an appointment" going to the booking tool and "check my balance" to the account lookup tool.
- With a general FAQ tool sitting beside a dedicated order status tool, the post says the model's choice can flip between the two on functionally identical requests phrased slightly differently.
- A wrongly chosen tool usually still returns something, and the post says that narrower output rarely produces the clear error signal a complete failure would.
- Writing more detailed tool descriptions is the common first fix, and the post says it helps up to the point where requests fall in the overlap between two tools' legitimate use cases.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure When one side of an ambiguous pair writes, a bad route lands on a customer's calendar or card, and the post argues a system that defaults to the consequential action loses trust faster than one that asks.
- constraint Error-rate monitoring is the wrong detector for this class, so a team watching dashboards for agent health will not see routing drift until users complain about answers that were merely unhelpful.
- decision The fix the post proposes sits above the tool list, in the system prompt, which makes routing a prompt-and-turn-budget question for whoever owns the conversation design, not a tool-schema question.
A tool call starts with a list. Each entry carries a name, a description, and an input schema, and the model picks one entry from that list before any of your code runs [3]. A test that calls the order status tool directly proves the tool works. The choice of tool sits outside that test.
Sizing the test surface is the part that gets missed. Tools are tested one at a time; routing has to be tested per pair. The post's opening example lists three tools: database lookup, calendar booking, payment processing [14]. Three tools make three unordered pairs, so covering every boundary takes three ambiguous requests, and a fourth tool takes it to six [1]. Demo suites exercise none of them, because the demo request was written after the tool list.
The post's ambiguous case is "what's your return policy for damaged items", which can be treated as a general knowledge question for the FAQ tool or as something specific enough for a targeted lookup if the system has one [6]. Expanding the descriptions helps up to a point and then stops helping, and the post is specific about why: the ambiguity is a property of the request, not a gap in how clearly the tools were explained [12].
The post's alternative is an explicit disambiguation layer in the system prompt, separate from and prior to tool selection [13]. For that to work, the model has to notice the overlap before it commits to a tool, and the system needs somewhere to put the clarifying question. The post does not report error rates or before-and-after measurements for that layer.
Read-write pairs are where I would spend the first week of testing. The post's example is "can I move my appointment to Thursday", sitting between a tool that checks availability and a tool that performs the reschedule, and it argues that a system resolving that by defaulting to the more consequential action, instead of confirming intent, produces the failure that erodes trust fastest [10]. A wrongly retrieved piece of information can be corrected quietly; a wrongly triggered write cannot [9]. I would make the confirmation turn mandatory for any pair where one side writes, and pay the extra round trip on every ambiguous booking request.
What to watch
- A measured comparison of a prompt-level disambiguation layer against improved tool descriptions on the same set of ambiguous requests.