How do you design a robust tool system for a production...

Five properties, and they matter more than how many tools the agent has:

• Precise schemas — a vague name and description leads directly to the model picking the wrong tool or the right tool with wrong arguments. The schema is the interface contract; treat it that seriously.
• Idempotency — a tool has to be safe to call twice with the same input, because retries happen. If “send email” isn’t idempotent, a retried step after a timeout sends a duplicate.
• Structured error handling — tools should return a typed error object, not throw and crash the run. The agent can only adapt to a failure it can actually read.
• Input validation — catch bad arguments before execution, not after. A malformed customer ID should fail at the boundary, not after it’s already touched a downstream system.
• Least privilege — a research tool gets read-only access; nothing gets write access it doesn’t need for its specific job.

The mistake that undermines all five at once is giving an agent too many tools, especially ones with overlapping purposes — it doesn’t just slow things down, it directly increases the odds of wrong selection, because the model has to disambiguate between things that look similar in description space. Fewer, sharply-scoped tools beat a large surface every time.