An agent without tools is just a chatbot. Tools are what transform LLMs from conversation partners into systems that take action, retrieve information, and interact with the world. But every tool an agent needs is an integration that someone has to build, test, secure, and maintain. This integration work - the tool integration tax - is often the largest hidden cost in agent development. Understanding what it actually takes to integrate tools helps you make informed decisions about where to invest your engineering effort.
What Tools Actually Require
The demo version of a tool is deceptively simple. Call an API, return the result. A few lines of code. But production-ready tools require substantially more.
Consider building a Slack integration. The straightforward path is getting an API token and calling the Slack API. In practice, you need OAuth authentication so the agent can act on behalf of users. OAuth means implementing the authorization flow, redirecting users through consent screens, handling callback URLs, and receiving tokens. Those tokens must be stored securely - encrypted at rest, accessible only to authorized systems, associated with the correct users.
Tokens expire. Your integration needs to detect expiration and refresh tokens automatically. Refresh can fail if users revoke access, requiring graceful handling that prompts re-authorization rather than crashing.
API calls need error handling. Rate limits require backoff and retry. Service outages need graceful degradation. Input validation protects against malformed data. Output parsing handles API format changes.
Multiply this by every tool your agent needs. A typical agent might need web search, email, calendar, document storage, and a few domain-specific integrations. Each one carries this overhead.
The Math of Building Tools
Honest estimates of tool integration effort look something like this:
Simple read-only API with API key authentication takes one to two days. Web search, weather data, simple lookups - these are the easiest category.
OAuth-based integrations take one to two weeks each. Slack, Google, Microsoft, Twitter - any service where your agent acts on behalf of users requires the full OAuth machinery.
Complex integrations with multiple operations, webhooks, or real-time features can take three to four weeks. Full-featured calendar management, comprehensive CRM integration, or complex workflow automation falls here.
Maintenance runs two to four days per integration per year. APIs change, auth flows update, deprecations require migration. This ongoing cost is easy to underestimate.
Ten OAuth integrations represents roughly ten weeks of initial development plus four weeks of annual maintenance. That is engineering effort not spent on agent logic, user experience, or business features.
What Agents Commonly Need
Tool requirements vary by use case, but common categories emerge.
Information retrieval tools find data the agent needs. Web search, document retrieval, database queries, knowledge base lookups. These provide the raw material for agent reasoning.
Communication tools let agents interact with the world. Email sending and reading, Slack messaging, calendar scheduling, notification systems. These enable agents to reach people and systems.
Data processing tools transform and analyze information. Code execution for computation, file format conversion, image processing, text extraction from documents. These extend agent capabilities beyond what LLMs do natively.
Action tools create real effects. Creating records in databases, updating CRM entries, deploying code, making purchases. These are high-consequence tools that require careful design.
AI and generation tools access specialized AI capabilities. Image generation, voice synthesis, transcription, translation. These leverage external AI services for tasks beyond the core LLM's abilities.
Most production agents need tools from several categories. A customer service agent might need communication tools, information retrieval, and CRM integration. A research agent might need search, document processing, and data analysis. The specific mix depends on the use case, but the breadth is usually wider than initial estimates suggest.
The Library Alternative
Instead of building every integration from scratch, you can use a platform that provides tools as pre-built capabilities.
Pre-built tools offer several advantages. Immediate availability means you can add tools in minutes rather than weeks. Maintained integrations mean someone else handles API changes, auth updates, and bug fixes. Tested implementations have been used by many customers, surfacing and fixing issues you would otherwise discover yourself. Consistent interface means all tools work the same way within your agent system.
The trade-off is less customization. Pre-built tools provide common operations. If you need highly specialized behavior, custom development may still be necessary.
The practical approach is using pre-built tools for common integrations and building custom tools only for genuinely unique requirements. Slack, Google, Microsoft, common AI services - these are commodity integrations where building custom provides no competitive advantage.
When Custom Tools Make Sense
Despite the cost, custom tools are the right choice in specific situations.
Proprietary systems that only your organization uses require custom integration. Your internal databases, custom APIs, and business-specific services are not covered by any pre-built library.
Specialized logic beyond what pre-built tools offer might need custom implementation. If you need particular validation, transformation, or business rules applied to tool operations, custom code provides that control.
Security requirements may demand custom implementations. If your security team requires specific patterns, specific encryption, or specific audit trails that pre-built tools do not provide, custom development enables compliance.
Novel capabilities that do not exist in tool libraries must be built. If your agent needs to interact with a new service or perform a unique operation, you are building it yourself regardless.
The key distinction is whether the integration is standard or unique. Standard integrations to common services are commodity work - building them provides no advantage and consumes resources. Unique integrations to proprietary systems are necessary investments. The decision framework is straightforward: use pre-built for common, build custom for unique.
The Hidden Costs of Integration Debt
Beyond initial development, tool integrations accumulate hidden costs over time.
Security vulnerabilities in integration code require patching. OAuth libraries have CVEs. API clients have bugs. Every integration is code that needs security maintenance.
API deprecations force migration work. Services evolve their APIs, deprecating old versions. Integrations must be updated to continue working.
Credential management complexity grows with integration count. More integrations mean more credentials to secure, rotate, and monitor. The attack surface expands.
Debugging complexity increases when problems might be in any of many integrations. Narrowing down which integration is misbehaving takes time.
Knowledge concentration becomes a risk when only certain team members understand certain integrations. Team changes can leave integrations unmaintained.
These costs are real but often invisible because they emerge gradually. Teams that build many custom integrations find themselves increasingly constrained by maintenance burden.
Evaluating Tool Platforms
If you decide to use pre-built tools, several criteria matter for evaluating platforms.
Coverage determines whether the tools you need are available. Breadth across categories matters more than depth in any single category. A few missing integrations can still require custom work.
Quality determines whether tools actually work reliably. Pre-built tools that fail frequently are not better than no tools. Look for platforms with production track records.
Security determines whether you can trust the platform with credentials and data. OAuth token handling, encryption practices, access controls - these matter for production use.
Cost model determines whether the economics work. Per-tool pricing, per-call pricing, or flat subscription - the best model depends on your usage patterns.
Customization determines whether tools can be adapted to your needs. Can you adjust parameters, add validation, or modify behavior? Some customization is usually necessary.
For teams building agents that need tools, inference.sh provides over 150 pre-built tools covering common integration needs. OAuth is handled at the platform level. Tools are maintained and updated. You add tools to your agent and focus on what the agent should do, not on building integration infrastructure.
The tool integration tax is real and substantial. Paying it makes sense when integration provides unique value. For commodity integrations, using pre-built tools frees your engineering effort for work that actually differentiates your agent.
FAQ
How do I estimate tool integration effort for planning purposes?
Start with categorization. API-key-based read-only integrations take one to two days. OAuth integrations to major platforms take one to two weeks each - this covers most services where agents act on behalf of users. Complex integrations with multiple operations, webhooks, or real-time features take three to four weeks. Add two to four days per integration annually for maintenance. Sum across all required integrations. Compare to using pre-built tools: onboarding time plus configuration time, typically hours to days rather than weeks. The ratio usually strongly favors pre-built for common integrations.
What happens when a pre-built tool does not do exactly what I need?
Options depend on the gap. Minor customization often comes through configuration - adjusting parameters, adding filtering, or modifying output formatting. Major customization might mean wrapping the pre-built tool with custom logic that pre-processes inputs or post-processes outputs. If the gap is fundamental - the tool cannot do what you need - consider whether a different pre-built tool exists or whether custom development is justified. Sometimes the answer is designing agent behavior around available tools rather than building tools around desired behavior. Evaluate trade-offs: custom tool development cost versus accepting some limitation in capability.
How do I handle tools that need different credentials for different users?
Per-user credentials require credential isolation infrastructure. Each user's tokens must be stored separately, accessible only when that user's agent is executing. The platform must route credential injection based on user context. Most OAuth-based tools inherently support this because the OAuth flow produces per-user tokens. The complexity is in storage and routing. Pre-built tool platforms typically handle this through their OAuth management. Custom implementations must build this infrastructure explicitly. Never share credentials across users even if it seems convenient - the security and privacy implications are severe.