#tool-use
Every post tagged "tool-use".
76 posts · showing 11–20
-
One Tool With Twelve Parameters or Four With Three? Let the Agent's Error Log Decide
Merging tools trades wrong-tool mistakes for wrong-argument mistakes. Your traces already show which one your agent makes more, and an overloaded tool leaves a signature you can grep for.
-
Retrieval Returned Zero Rows and the Agent Cited a Policy Doc Anyway
Empty retrieval results are the only tool failure that arrives as a success — status 200, results [] — and a model asked to answer from sources will invent one to fill the hole. Two boundary fixes: a loud typed empty, and citation IDs validated in code.
-
Forty Tools in One Prompt: What It Actually Costs, and the Three Signals That Say Split the Agent
Forty registered tools do not fail loudly — the agent just gets vague, picking near-synonyms and asking questions it had the answer to. Here are the three costs you're paying, and the signals in your traces that tell you to merge, gate, or finally split.
-
A 1% Flaky Tool Shouldn't Take You Down. Three Nested Retry Layers Will.
A tool that fails one call in a hundred is healthy. The retry logic wrapped around it is what turns a dependency's bad minute into a queue of hung user requests — and the load multiplier is at its worst exactly when the dependency is weakest.
-
Your Agent Called the Same Tool Three Times in a Row. Here's What the Loop Is Telling You.
A repeating agent isn't being stubborn — it's being consistent. Identical tool calls mean the context barely changed between turns, and there are only four reasons that happens.
-
Your Agent's Dry Run Doesn't Bind the Real Run — Confirm the Plan Hash, Not the Intent
A human approves a preview; the agent then executes a freshly computed call. Everything that shifts in between is unguarded — and the fix is a redeemable plan object, not a sterner confirmation prompt.
-
Your Tool Returned 4,000 Rows and the Agent Needed Three: Truncate, Paginate, or Summarize?
Most tool endpoints were written for a caller that can loop and discard. An agent reads the whole response in one gulp and keeps it forever — and the three ways of shrinking that response fail in completely different ways.
-
Agent or Just a Script? Count the Branches That Depend on Reading Something
There is a ten-minute test that settles whether your automation needs an agent loop or just a script with a couple of model calls in the middle — and the two ways of guessing wrong are not equally recoverable.
-
Cached or Re-Called? Giving Every Agent Tool a Staleness Budget
An agent that reads a value once and acts on it four minutes later isn't reasoning badly — nobody told it how long that value stays true. Per-tool staleness budgets, and the one rule that matters most before a write.
-
Your Agent Retried the Tool Call. The Customer Got Charged Twice.
A timed-out tool call is not a failed one — it is an unknown one. Here is why "just retry" quietly doubles real-world side effects, and where to put the idempotency check so it cannot.