An AI agent becomes useful when it can reach beyond conversation and do work through tools. A model can reason, draft, compare, and explain. A tool lets it search a knowledge base, read a file, create a ticket, run a test, update a record, or ask a person for approval. The difference is not cosmetic. Without tools, an agent can only describe a path. With tools, it can travel part of that path.
That is why tool design deserves more attention than it usually gets. A weak tool can make a strong model look careless. A vague tool can turn a simple task into a guessing game. A broad tool can give an agent more authority than the workflow can safely absorb. A clean tool contract, by contrast, gives the model a handle it can understand, a boundary it cannot ignore, and an output the rest of the system can inspect.
If How AI Agents Work opens the machine room, tool contracts are the levers and labels inside it. They define what the agent may ask for, what the tool will do, what comes back, and what must happen before the action becomes real.
A tool is a contract, not a wish
A human can hear “check the customer account” and infer a dozen things from context. Which system matters? Which customer identifier is reliable? Should the check include payment status, support history, plan limits, recent changes, or only the one field mentioned in the ticket? If the human is unsure, they may ask a colleague or follow the team’s habits.
An agent needs those habits turned into machinery. The tool name, description, inputs, outputs, failure modes, and permission level are all part of the contract. The model is not just choosing a function. It is choosing a promise about what will happen next.
A tool called search tells the model almost nothing. A tool called search_approved_policy_documents tells it more. A tool called find_refund_policy_by_order_region is narrower still. The best name depends on the job, but the principle is stable: the tool should advertise the real boundary. If the agent must not search the open web for policy answers, the tool should not be described as a general search tool with a private instruction buried elsewhere.
The same applies to inputs. A tool that accepts a loose text blob forces the model to package meaning in prose and hopes the receiver understands. A tool that accepts structured fields makes the boundary visible. An order lookup might require an order ID and optionally accept a customer ID for cross-checking. A message drafting tool might require the audience, channel, tone, and source records. A deployment tool might require the repository, environment, commit, test status, and approval token. The point is not ceremony. The point is to remove room for a plausible but wrong interpretation.
Narrow tools are often stronger than broad tools
Agent demos often favor broad tools because they make the system look flexible. Give the agent a browser, a shell, a database connection, and an instruction, and it may perform a long task end to end. That flexibility has a place, especially in developer environments and exploratory work. But production workflows usually improve when the most important actions are represented by narrow tools.
A narrow tool carries policy in its shape. A refund tool can refuse refunds above a limit. A publishing tool can require an approval record for public pages. A customer lookup tool can redact fields the agent does not need. A scheduler can expose availability windows without exposing private calendar notes. These constraints are not signs of mistrust. They are how the system says, with precision, which part of the job has been delegated.
The AI Agent Permissions ladder is easier to apply when tools have clean edges. Reading a ticket, drafting a reply, preparing a refund, submitting a refund for approval, and issuing a small routine refund should not all be the same tool with different natural-language instructions. They are different levels of authority. If they are represented as different tools, the orchestrator can log them differently, gate them differently, test them differently, and explain them to a reviewer without reconstructing the agent’s intent from prose.
Broad tools still matter. A coding agent may need a shell. A research agent may need a browser. A personal agent may need to move through interfaces that have no clean API. But broad tools should usually be surrounded by narrower contracts where the stakes rise. Let the agent inspect freely in a sandbox. Ask for confirmation before it changes shared state. Route irreversible or obligation-creating actions through tools that know the policy.
Outputs should be boring and inspectable
The output of a tool is not just material for the model. It is evidence for the workflow.
If a tool returns a paragraph of natural language, the model has to parse it, remember it, and decide what matters. Sometimes that is fine. More often, a structured response is safer. A lookup can return a status, a timestamp, a source identifier, and a small set of fields. A search can return records with titles, snippets, dates, and stable links. A test runner can return pass or fail, the failing command, the affected files, and a log excerpt. A permission request can return approved, denied, expired, or needs more context.
Boring outputs make agents easier to debug. When a failure happens, you can ask whether the agent chose the wrong tool, passed the wrong input, received bad data, ignored a warning, or acted correctly on a flawed policy. That distinction is central to When AI Agents Fail . Without structured outputs, the trace becomes a fog of friendly prose.
Inspectable outputs also help the agent know what it does not know. A search tool can return “no approved source found” instead of an empty paragraph. A record lookup can distinguish “not found” from “permission denied” and “system unavailable.” A file reader can report that content was truncated. These details matter because agents often fail by smoothing over uncertainty. A good tool gives uncertainty a shape.
The tool should make the safe path easy
Good tool design is not only about blocking bad actions. It is about making the intended action the obvious one.
Consider an agent that drafts customer replies. If the only available tools are a ticket reader and a general text generator, the agent may quote sensitive details, skip policy references, or produce a reply that sounds confident but is not grounded. A better workflow gives it a policy retrieval tool, a customer-safe summary tool, and a draft tool that requires citations to internal sources. The model still writes, but the path nudges it toward grounded writing.
The same principle applies to software work. A coding agent should not have to remember every local convention from a long instruction. Some of that knowledge belongs in tools and scripts: run the focused tests, inspect the relevant diff, check formatting for touched files, find ownership notes, or open the project guide. The agent can reason over the result, but the tool should make the right evidence cheap to collect.
This is where tool design and delegation meet. How to Delegate to AI Agents focuses on assigning work clearly. Tool contracts make those assignments executable. A clear assignment says what done looks like. A clear tool set gives the agent a route to prove it got there.
Approval is part of the interface
Many teams treat approval as something outside the tool system. The agent drafts or prepares an action, then a person looks at the final answer and says yes or no. That can work for small tasks, but serious workflows need approval to be represented explicitly.
An approval-aware tool does not merely ask “continue?” It shows the proposed action, the source evidence, the actor, the affected object, the expected consequence, and the rollback path when one exists. The approval record then becomes part of the trace. If the agent later completes the action, the system can connect the action to the human decision that authorized it.
This matters because human review is not a vague mood. It is a handoff. In Human Review for AI Agents , the critical question is what the reviewer must inspect before agent output becomes trusted work. Tool contracts can make that inspection concrete. A reviewer should not have to infer what a tool is about to do from a polished agent summary. The tool itself should expose the exact action in plain terms.
Approval should also expire. If an agent asks to send a message, waits for an hour, retrieves new information, and then sends a different message under the old approval, the contract is weak. The approval should apply to a specific action or a clearly bounded class of actions. When the action changes, the approval should be renewed.
Idempotence and reversibility are design choices
Some tools are safe to retry. Others are not. An agent that runs a search twice has probably caused no harm. An agent that sends an email twice has created a social mess. An agent that charges a card twice has created a serious operational problem.
Tool contracts should say how retries work. A tool can accept an idempotency key so the same requested action is not performed twice. It can support a dry-run mode that reports what would happen without changing anything. It can separate preparation from execution, so the agent first creates a proposed change and only later applies it after approval. It can return a stable action ID that the trace can follow.
Reversibility deserves the same care. If a tool edits a document, can it show the diff before applying the change? Can it restore the previous version? If a tool updates a customer record, does it log the old value? If a tool archives a file, is that archive reversible or permanent? These questions are not only for engineers. They shape how much authority the agent should receive.
An agent with reversible tools can be allowed to move faster. An agent with irreversible tools needs tighter gates, clearer evidence, and a better reason to act without a person in the loop.
Test the contract, not only the model
Agent evaluations often focus on final answers. Did the agent solve the task? Was the response correct? Did it follow the instruction? Those questions are necessary, but tool-using agents need another layer of testing.
The contract itself should be evaluated. Give the agent a task where it should read but not act. Does it choose the read-only tool? Give it a task where a required field is missing. Does it ask for the field or invent one? Give it a stale source and a fresh source. Does it prefer the right one? Give it an action that crosses a permission boundary. Does it route through approval? Give it a failed tool call. Does it stop, retry safely, or explain the blocker?
This is the bridge to AI Agent Evaluations . A good evaluation set does not only score the final artifact. It watches the path. Tool calls are part of the answer because they show whether the agent used the authority it was given in the way the system intended.
Testing also reveals when a tool is too clever. If the tool hides important decisions inside backend logic, the agent may appear reliable until an edge case arrives. If the tool exposes too much raw complexity, the model may make avoidable mistakes. The right contract gives the agent enough control to be useful and enough structure to be checked.
The quiet test of maturity
The mature version of an agent system is not the one with the most tools. It is the one where each tool has a reason to exist.
A well-designed tool contract answers a few plain questions. What can the agent do with this? What must it provide first? What will the tool refuse to do? What comes back? What gets logged? What needs approval? What happens if the same request is repeated? What proof remains after the action?
When those answers are clear, the agent becomes less mysterious. It is still probabilistic in how it reasons and chooses, but the world it can act on is shaped by ordinary engineering. Names become boundaries. Inputs become commitments. Outputs become evidence. Approvals become records. Failures become diagnosable.
That is the practical work of building agents: not hoping the model always understands the job, but giving it handles that make the right job easier to do.
