Tool Use in AI Agents: How Agents Interact with the World
You’ve just wired up an AI agent to your codebase. It can answer questions. Now you want it to actually do things — search, call an API, place an order. That gap between “generates text” and “takes action” is exactly where tool use lives.
Quick answer: Tool use is the mechanism by which an AI agent calls external functions — APIs, databases, code runners, payment endpoints — to take real-world actions. The LLM outputs a structured function call, the runtime executes it, and the result feeds back into the model’s context. A single task can chain dozens of tool calls. The model decides what to call; your infrastructure decides whether it’s allowed to.
What Tool Use Actually Means
Tool use is not a feature baked into the model — it’s a runtime pattern. The LLM outputs a structured JSON object that says “call this function with these arguments.” Your application intercepts that output, runs the real function, and appends the result to the conversation. The model never directly executes anything; it only requests execution.
This distinction matters. It means the safety boundary isn’t in the model — it’s in the layer between the model’s output and your infrastructure.
The Four Categories of Tools Agents Use
Most agent tools fall into one of four buckets:
| Category | Examples | Risk Level |
|---|---|---|
| Read-only data | Web search, database lookup, document retrieval | Low |
| Compute | Code interpreter, math engine, data transformation | Medium |
| Write / mutate | File system writes, CRM updates, email sends | High |
| Payment / financial | API purchases, SaaS subscriptions, agent-to-agent fees | High |
Payment tools are the highest-stakes category because mistakes are immediately financial and often irreversible. An agent that calls a search API in a loop wastes compute. An agent that calls a payment API in a loop drains real money.
The risk gradient above is why you shouldn’t treat all tools as equal. Read-only tools can be handed out liberally. Payment tools need explicit per-agent authorization, spending caps, and revocation.
How the Tool Call Loop Works
Here’s a minimal tool call cycle in plain terms:
1. User sends goal → LLM
2. LLM outputs: { "tool": "search_web", "query": "current ETH price" }
3. Runtime intercepts, calls actual search API
4. Result appended to context: "ETH is $2,341 as of 14:02 UTC"
5. LLM continues reasoning with new information
6. Repeat until LLM outputs a final answer (no tool call)In practice, frameworks like LangChain, CrewAI, Mastra, and AutoGen handle steps 2–5 automatically. You define the tools as functions with typed schemas; the framework manages the loop.
The schema quality is what makes or breaks reliability. A tool described as “does payments stuff” will be called unpredictably. A tool with a precise description, typed parameters, and explicit constraints gets called correctly.
# Example: tight tool schema beats a vague one
{
"name": "pay_api_invoice",
"description": "Pay a specific API invoice by invoice ID. Use only when the user has explicitly confirmed payment. Do not call speculatively.",
"parameters": {
"invoice_id": { "type": "string", "pattern": "^inv_[a-z0-9]{16}$" },
"amount_usd": { "type": "number", "minimum": 0.01, "maximum": 500 }
}
}The maximum field isn’t just documentation — if your runtime enforces the schema, it’s a hard cap.
Why Tool Permissions Are Not an Afterthought
Every tool an agent can call is a capability it can misuse. The standard failure mode isn’t a rogue agent — it’s an agent that loops, misinterprets a goal, or gets manipulated through the data it reads (prompt injection via a malicious webpage or API response).
The “blast radius” principle is simple: an agent should only be able to break things within its own scope. That means:
- One set of credentials per agent, not shared master keys
- Spending caps enforced at the infrastructure level, not just in the prompt
- Revocation that doesn’t require rotating keys across your entire stack
Telling an agent “don’t spend more than $50” in a system prompt is not a spending cap. It’s a suggestion the model can reason around. A real cap lives in the payment layer, not in natural language.
If your agents are making payments — to APIs, SaaS tools, or other agents — ATXP gives each agent its own payment identity with a hard spending limit and one-click revocation. No shared credentials. No runaway spend.
Tool Use Across Agent Frameworks
The underlying loop is the same across frameworks; the syntax differs:
| Framework | Tool Definition Style | Payment Protocol Support |
|---|---|---|
| LangChain | @tool decorator or StructuredTool | x402 via custom tool |
| CrewAI | BaseTool subclass | Custom integration |
| Mastra | TypeScript function + schema | x402 native |
| AutoGen | FunctionTool + JSON schema | Custom integration |
| OpenAI SDK | tools array in API call | Custom integration |
x402 (the HTTP-native payment protocol) and Stripe ACP are the two most developer-relevant payment protocols right now. x402 embeds payment negotiation directly in HTTP headers — an agent can hit a paid endpoint, receive a 402 Payment Required response, pay, and retry, all without human intervention. That’s the architecture that makes fully autonomous agent payments possible.
What Good Tool Governance Looks Like
Solid tool governance comes down to three practices:
- Minimal tool surface. Only expose tools the agent needs for its specific task. A support agent doesn’t need a payment tool.
- Hard enforcement outside the model. Spending caps, rate limits, and permission checks should live in middleware or infrastructure — not in the system prompt.
- Per-agent identity. Each agent gets its own credentials. Compromise one agent; revoke one set of keys. Done.
These aren’t best practices for edge cases. They’re baseline hygiene for any agent that touches external systems.
The Bottom Line
AI agent tool use is the mechanism that turns language models into systems that do things. The model outputs intent; your runtime and infrastructure enforce constraints. Getting the tool schemas right improves reliability. Getting the permissions right limits damage.
The more autonomous your agents become, the more the permission layer matters — especially for payment tools. Text generation mistakes are editable. Payment mistakes aren’t.
If you’re building agents that pay for things, ATXP gives you the identity, limits, and revocation controls to do it without sharing your master credentials or relying on prompt-based guardrails.