AGENTS

Shrink the agent, grow the tool

Most unreliable agents are not under-prompted. They are over-optioned. The fix is usually to delete tools, not to add reasoning.

2 min readBurak Emre Kadan
All posts

An agent that fails 30% of the time gets treated as a prompting problem. The team adds instructions, examples, a planning step, maybe a second model to critique the first. Failure rate drops to 25% and the prompt is now unmaintainable.

Look at the tool list instead. In nearly every unreliable agent I have reviewed, the model was being asked to choose between too many things that were too similar.

Tool count is a reliability budget

Each tool you add multiplies the number of paths the model can take. Fourteen tools with overlapping purposes — search_orders, find_order, get_order_by_id, lookup_customer_orders — force a choice that has no obviously correct answer. The model picks differently across runs, and you call it non-determinism.

Collapse them:

// Before: four tools, overlapping, ambiguous
searchOrders(query)
findOrder(reference)
getOrderById(id)
lookupCustomerOrders(customerId)

// After: one tool, explicit about what it accepts
queryOrders({
  id?: string
  reference?: string
  customerId?: string
  text?: string
  limit?: number
})

The capability is identical. The decision the model has to make went from "which of four" to "which fields do I fill in" — and filling in fields is something models are reliably good at.

Push the logic into the tool

When a tool is thin, the agent has to compensate. If get_order returns raw JSON with 60 fields, the model burns tokens and attention deciding what matters. If it returns the six fields that answer real questions, plus a one-line summary, the agent barely has to think.

The rule of thumb: every decision you can make in code, make in code. The model should be choosing between meaningfully different actions, not doing data munging that a map would handle.

Where human approval belongs

Once the tool list is small, approval flows become obvious. You do not gate "the agent is about to think." You gate specific, named, irreversible tools:

  • refundPayment — always ask
  • sendEmail — ask above a recipient threshold
  • queryOrders — never ask

That distinction is only possible when tools map cleanly onto real-world consequences. It is another reason overlapping tools hurt: you cannot write a sane approval policy over four functions that all mean "look at orders."

If your agent needs a long prompt to pick the right tool, the tools are wrong.

The diagnostic

Print the tool list. For each pair, ask whether a competent new engineer could state the rule for choosing between them in one sentence. Every pair that fails is a merge candidate.

These write-ups come out of the course material. If they are useful, the courses go several layers deeper.

BROWSE THE COURSES

Keep reading