The agent sees a list of tools, each with a name, description and inputs. When it needs to act, the model emits a structured request to call one tool with specific inputs. The runtime performs the call and returns the result, and the model decides what to do next. In a governed setup, every call is checked before it runs.
What does a tool look like to the agent?
To the model, a tool is a short specification: a name such as look_up_order, a sentence or two on what it does and when to use it, and a list of inputs with their types. The model never sees the code behind it, the credentials it uses or the system it reaches.
Tools are the agent's only way to affect anything outside its own text. Reading a record, drafting an email, sending it, updating an account, all are tools. The concept is defined in what tool use is.
What happens during a single tool call?
- The model decides a tool would help and produces a call: the tool name and inputs, in a structured format.
- The runtime receives the call. In a governed setup, it passes it to the governing layer first.
- The governing layer checks the call against the agent's bounds and files a verdict.
- If allowed, the tool runs, using credentials the platform holds.
- The tool returns a structured result: data, a confirmation, or an error.
- The result goes back into the model's context, and the model decides its next step.
If the verdict is held, the result the model sees says so, and the agent moves on or waits. If refused, the model is told the call was outside its bounds.
Where do tool calls go wrong?
Wrong tool. With several similar tools, the model may pick one that almost fits. Fewer, more distinct tools help; see how many tools an AI agent should have.
Wrong inputs. The model may pass a customer number in the wrong format, or an amount it inferred rather than read. Typed inputs with validation catch format errors; source checks catch inferred values.
Steered calls. Text in an input, such as a customer's email, can suggest a tool call. The model may follow it. The governing layer's check is what stops a steered call from taking effect.
Overreaching tools. A tool that does too much cannot be bounded precisely. Design guidance is in how to design tools for AI agents.
What may the agent do with tools, and what stays with a person?
| Tool | Agent | Person |
|---|---|---|
| Look up an order | Calls it freely within its data scope | None |
| Draft an email | Calls it at depth 2 | Reviews and sends |
| Send an email | Only if certified at depth 3 for that kind of message | Approves anything outside it |
| Issue a refund | Within its depth and the customer's limit | Approves above the limit |
| Change payment details | Drafts the change | Verifies and approves |
Email deserves particular care because it speaks for the business; how to let an AI agent use email on your behalf covers it.
What does this look like in practice?
Take a support agent at an online retailer handling "where is my order?". It calls look_up_order with the order number from the customer's message. The result shows the parcel stuck at a depot for five days. It calls get_carrier_status, which confirms it. It calls draft_reply with an apology and an offer to resend.
Then it calls create_replacement_order. The governing layer checks: the agent is certified to depth 3 for replacements under a set value, and this order is below it. Allowed. The replacement is created, the result returns a new order number, and the agent includes it in the reply. Had the order been above the value, the replacement would have been held for a team leader and the agent's reply would say a colleague will confirm.
Where does an API gateway fit?
Tools often reach systems through an API gateway, which handles transport, rate limits and system credentials. The governing layer decides; the gateway carries. The pattern is covered in how to put an API gateway in front of an AI agent's tools. The full governing design is in the governed agentic operating system guide.
Questions people ask
Can an agent call several tools at once?
Many models can request several calls in one turn, such as two lookups in parallel. Each call is checked on its own, and calls with side effects are best run one at a time.
Does the agent know whether a tool call succeeded?
Only if the tool returns a clear result. Tools should report what changed and the new state, so the agent does not assume success.
Can a tool call another agent?
Yes. Delegating to another agent can be exposed as a tool. The receiving agent still acts within its own bounds, and the handoff is recorded like any other call.