An agent without tool access is a chatbot. The real power comes from connecting it to the systems your business already uses — email, spreadsheets, CRMs, APIs.
The Tool Interface
Every tool an agent calls should have a consistent interface:
type Tool = {
name: string;
description: string;
parameters: Record<string, unknown>;
execute: (args: Record<string, unknown>) => Promise<ToolResult>;
};
The LLM doesn't care what the tool does internally. It only needs the name, description, and parameter schema to decide when to call it.
Authentication Patterns
Tools need credentials. Never hardcode them.
- OAuth for user-facing tools (Gmail, Slack, Google Sheets)
- API keys for internal services
- Service accounts for admin-level operations
Store tokens in a secure vault or encrypted database. The agent should never see raw credentials — only a token reference that the tool resolver swaps at runtime.
Error Recovery
Tools fail. APIs return 429s. Rate limits hit. Services go down. The agent needs to handle all of these gracefully.
Implement a retry policy with exponential backoff. After three failures, surface the error and let the agent decide whether to try a different approach or escalate to a human.
Real-World Example
Consider an agent that processes support tickets:
- Reads the ticket from Zendesk API
- Searches the knowledge base for relevant articles
- Drafts a response using the LLM
- Writes the draft to Google Docs for review
- Emails the customer when approved
Each step is a separate tool with its own auth, rate limits, and error handling. The agent orchestrates the sequence, retrying failed steps and escalating when necessary.