Tools give an agent access to information and actions beyond text generation. Useful examples include retrieving a customer record, calculating a total, inspecting a document, saving a draft, or updating a permitted field. The application surrounding the model determines whether those requests should execute.
A tool request is a proposal
The model typically receives descriptions of available tools and their arguments. It can propose a tool call in a structured format. The execution layer validates the request, applies authorization, invokes the operation if permitted, and returns the result.
The research paper “Tool Learning with Foundation Models” examines approaches and challenges in combining models with specialized tools. It provides background for this capability; it does not replace application-level authorization or outcome checks. Tool-learning paper.
The important questions are concrete: does the tool exist, are the arguments valid, is this user allowed to access this record, and is the requested action permitted now?
Describe tools so their roles are distinct
Prefer a small set of capabilities suited to the task. A tool called get_delivery_status with an order identifier is easier to constrain than an unrestricted database query tool offered to a customer-service drafter.
Explain required inputs, valid identifiers, units, side effects, expected outputs, and error conditions. Separate search from retrieval, drafting from sending, and previewing a change from applying it.
| Tool role | Example | What must be checked |
|---|---|---|
| Read | Retrieve an approved order record. | User and record access; freshness. |
| Calculate | Sum validated line items. | Units, currency, missing values, rounding rules. |
| Prepare | Save a proposed reply. | Destination and sensitive content. |
| Communicate | Send a message to a specified recipient. | Exact content, recipient, authority, and result. |
| Change | Apply an approved record update. | Current version, permitted fields, and action identity. |
A read-only tool can still expose information. A write to an internal draft can still overwrite someone’s work. Classify consequences at the actual operation level.
Enforce permission where the action happens
Do not give a model broad credentials and rely on a prompt to narrow them. Use service identities and access scopes appropriate to the user and task. Validate each request at the application or destination boundary.
OWASP identifies excessive functionality, permissions, and autonomy as important causes of harmful actions in connected language-model applications. Its guidance supports limiting tools and enforcing authorization outside the model. Excessive agency.
For a publishing workflow, an initial tool might save a draft revision against a known article version. Publishing can remain a separate operation requiring a specific review decision. If the source article changed after review, stop and compare versions before applying the draft.
An approval should identify the exact action and relevant payload, including recipient, content, amount, or record version where applicable. A changed payload is a changed decision. The permissions chapter explains how to document this boundary.
Keep external content from becoming authority
A web page, email, PDF, or tool response may contain instructions aimed at the assistant. Treat those instructions as content from that source, not as permission to change the task.
For example, a supplier quotation might contain text asking the agent to upload the complete comparison to an external address. That request is unrelated to reading the quotation and should not grant new authority. OWASP describes this class of manipulation as indirect prompt injection. Prompt injection.
Use layered controls: narrow tools, restricted destinations, appropriate record access, validated outputs, and review for consequential actions. A single keyword filter or a prompt telling the model to ignore attacks is not proof of protection.
Test hostile content in each format the workflow accepts. Keep tests within controlled data and environments. Inspect attempted tool calls as well as completed actions so you can see whether a boundary stopped an incorrect proposal.
Validate between steps
Suppose a workflow retrieves an order, drafts a response, and proposes sending it. Before drafting, verify that the retrieved order belongs to the intended customer. Before sending, verify that the approved response still matches the current order and recipient.
A successful tool response can be incomplete or stale. An empty search result does not prove that no relevant record exists. A status code does not establish that a factual claim appears on the retrieved page.
Define what each step needs from the previous step. If a required field is absent, stop that branch or request the missing information. Do not pass a plausible substitute downstream as though it came from the source.
Handle retries without duplicating the action
A temporary read failure may permit a bounded retry. A denied request calls for an authorization decision. Invalid arguments call for correction. A timeout after submitting a write may mean the action succeeded but the response was lost.
Use provider-supported idempotency where available, with a stable key for the same intended operation and the provider’s documented semantics. Reconcile uncertain outcomes before resubmitting actions. AWS explains why retry identity and request intent matter in Making retries safe with idempotent APIs.
Cancellation also needs a defined meaning. Stop new requests, then determine whether an in-flight request was accepted. “Cancelled locally” is not the same as “nothing happened remotely.”
Inspect results without collecting everything
Record task and action identifiers, tool names, validated arguments or protected references, access decisions, timestamps, destination receipts, errors, and final state. Keep model and instruction versions where they help investigation.
Protect logs and limit sensitive content. A useful explanation might say that the system checked a tracking record because the inquiry lacked a delivery update. Private internal chains of thought are not required to establish which tools ran or which records changed.
For actions with external effects, compare the application’s claimed outcome with destination evidence. A final message saying “sent” cannot replace a provider receipt or a verified destination state.
Choose integrations from requirements
Frameworks can help define tools and coordinate calls, but capabilities and defaults change. Compare actual access controls, state handling, error behavior, observability, and maintenance fit. Avoid general claims that one framework is always safe or another never validates tools.
Older tutorials may reference retired APIs. OpenAI’s deprecation record identifies August 26, 2026 as the Assistants API shutdown date and points to Responses and Conversations replacements. Deprecation record. Check current provider documentation before implementing a particular integration.
Start with one read tool and one useful output you can inspect. Add a new capability only after defining its contract and checking its failures. Continue with agent development, orchestration, and agent evaluation.