An agent's capability set is its tool set. Design the tools well and many behavioural problems disappear, because the wrong action is simply not available.
Narrow beats general
A single run_query tool that takes arbitrary SQL is convenient and grants the agent everything the database connection allows — including everything you did not intend.
Instead: get_order_by_id, search_orders_by_email, list_recent_orders. Each does one thing, takes typed parameters, and can be permissioned, validated, rate-limited and audited on its own.
The trade is real — more tools to define, and a very long tool list makes selection harder. The balance is usually a handful of narrow tools per domain rather than one general one or thirty granular ones.
Contracts, not suggestions
Every tool needs a strict schema: parameter names, types, whether required, allowed ranges. Then validate on the way in, because the model can produce well-formed requests with impossible values — a limit of 100,000, a date in 1900, an ID that does not exist.
Validation is not distrust of the model. It is the same discipline you would apply to any external input, and model output is external input.
Errors are instructions
This is under-appreciated. The error string you return is read by the model and determines its next move.
Poor:
Error: request failed
Good:
Error: no order found with id 4471. Order ids are 6-digit numbers. Use
search_orders_by_emailif you only have the customer's email.
The second tells the model what was wrong, what valid input looks like, and what to try instead. Agents recover from good errors and loop on bad ones.
Blast radius
Assume the agent will be wrong, and that at some point it will be wrong while following text it read from an untrusted source. Design so that neither is a disaster.
Read-only by default. Most agent tasks are answering questions. An agent that cannot write cannot corrupt anything, whatever it is persuaded to attempt.
Separate identity. Its own account, its own credentials, its own audit trail. Never a human's.
Scope every credential. One project, one mailbox, one table, specific fields.
Stage writes. Create drafts rather than sending; propose changes rather than applying them. A human confirms.
Quantitative limits. Maximum records touched per run, maximum spend, maximum messages. A bug that would have sent 10,000 emails sends 10 and stops.
Reversibility. Soft-delete rather than delete. Keep the previous version. Make undo cheap.
Test the wrong path
Evaluate tools against bad input on purpose: missing parameters, wrong types, values out of range, results that do not exist, a tool that times out, and a tool result containing text that reads like an instruction to the agent.
What the agent does with each of those is a design property of your tools, not a property of the model. If it recovers sensibly, you built them well.