Give an agent a thousand tools and it will pick the wrong blade

Nathan Labenz opens by calling Composio a Swiss army knife for AI agents: more than 50,000 tools across 1,000-plus apps, one interface, ready to plug into whatever you are building. Karan Vaidya, the company's CTO, does not reject the metaphor. He tightens it. At this point in the model curve, he says, if you actually provide a thousand tools to the agent, it will probably use the wrong blade and "suicide via context overload." The catalog is the inventory. It is not the product.

What Composio sells, in his phrasing, is an agentic tool execution layer — the harness you would otherwise have to build around Claude Code, Codex, or a production agent. A few meta-tools sit in front of the catalog so the runtime never sees the whole drawer. Authentication and authorization are managed, with scopes the model is allowed to use. Just-in-time discovery and dynamic calling load only the tools the current job needs. Triggers notify the agent when an email arrives, a Slack message lands, or a pull request is opened.

The integrations themselves are not a human factory. They are built by an internal agentic pipeline that fetches the developer app and credentials, creates actions, finds dependencies, and tests them against real scenarios and edge cases. The team that owns that pipeline is three people. The company is about 15. Last month the pipeline spent roughly $100,000 on tokens — already more than the human cost, and, Karan says, a multiple of human capital even for internal development. Token spend is the production line. People are there to supervise it.

Labenz sees two users who want different slices of the same stack. One is the individual who already reaches for Claude Code before Gmail, and who just spent a painful afternoon creating a Google Cloud app so a teammate could touch Drive. Slack permissions are worse. For that person, one MCP server — `connect.composio.dev/mcp` — plus auth that can be finished from the chat or the dashboard is the whole pitch. The other user is a developer shipping a production agent, for whom managing OAuth across a thousand apps is the unfun part, and a dynamic tool surface can make the product itself feel unwieldy.

Karan calls it a bifocal product. On the prosumer side, Claude Code, OpenClaw, and similar runtimes get one MCP and the ability to connect a new app by asking. On the developer side, the same harness ships as MCP, API, or SDK, and also as pieces: discovery that can wrap Composio tools and the customer's own, a workbench sandbox whose auth Composio still holds, or just auth and actions if the customer wants to own the rest. Governance, observability, and auditability live in the dashboard. AWS, Zoom, Glean, and Airtable are named as customers building core agent products on top, including a self-hosted deployment inside AWS's own VPC.

Asked what those companies actually beat the team up on, he starts with least privilege. You can grant an agent read on email and withhold send, and you can do the same action by action on Slack and the rest of the knowledge-work suite. Before a tool runs, hooks can inspect the call and force a human in the loop. After it runs, hooks can inspect the payload before the model sees it. SOC 2 and the usual compliance pack are table stakes. For the data that still should not leave the building, they self-host in the customer's VPC.

Labenz is trying to unclutter a mental model. Claude Code on a laptop runs bash locally; Anthropic's search tool runs on their infrastructure; results bounce both ways. So what should run in Composio's sandbox, and what should stay on the customer's machine? Karan's answer is not "bring us the whole app." The sandbox is a place where the model has to write very little code, because auth and a set of tool-calling primitives are already in the image. The same Docker-style environment is coming to local machines so internal tools can sit beside Composio's.

The motivating failure is function calling at volume. If you want an agent to process 10,000 emails, a hundred of them will already overload context. The sandbox lets the agent write a program that calls the apps in a loop. File sharing is the other deterministic chore they have baked in: mounted folders whose contents are uploaded to S3 and turned into shareable links, so a report over 10,000 emails or a Stripe dump is just a copy into that directory. Karan calls it inception, and he means it literally: the model writes code that itself calls a model. That is how you get through 10,000 emails, or a million, without asking the outer loop to watch every message.

The first wave of MCP, Labenz says, was APIs in a thin wrapper: a hundred tools as a hundred function descriptions sitting in the system prompt. Karan's line is that attention is not free, even at a million tokens, and five million will not make a stuffed window a good idea. Composio's first layer of smartness is that the model never sees the 50,000. It sees a few tools; more are added to context as the job unfolds. Claude Code sits in the middle as an "intelligent mediator," so a user who says "connect Google Drive" usually hits the auth-management tool rather than a vague search against the catalog.

The second layer is live repair. If the agent cannot parse a tool description, or keeps erroring, the same pipeline that built the integration is invoked at runtime. A new version is generated and swapped into the agent's context. The same tool can exist in tens of thousands of versions. Generic fixes — last week they found Google Calendar cases where the official docs were simply wrong, discovered only because agents poke APIs in ways humans never did — go out to everyone. Personalized upgrades stay with the user whose usage pattern justified them. Skills, the layer that locks in a behavior someone already likes, are changed much more slowly.

The third layer is trajectory compression. Agents often take a zigzag path to an outcome. Because Composio has the full trace — what ran, what the use case was — it turns that zigzag into a reusable skill, and does just-in-time skill discovery the same way it does tools. Failures become dos and don'ts, injected up front: these are the pitfalls for this tool in this kind of job. That is the definition he keeps returning to. "Harness is nothing but context. You have to engineer the context."

Asked for examples of intent that actually resolved, Karan does not offer a single API call. People now hand over whole Gmail access and say: go through last month, archive what is not useful. The agent writes code, uses a model to judge, and batches the archive. His own OpenClaw does recruiting. It walks GitHub, looks for strong commits on agent-framework, Python, and TypeScript repos, enriches location, email, LinkedIn, and other social data, and reaches out from an address that belongs to the agent. In the last week or two that pipeline had set up 30 to 40 calls. A sales version of the same pattern finds the people, drafts the mail, and stops at the send button.

Labenz's fear is context in the wrong place. He has a local database of five years of email, Slack, DMs, and call transcripts — about a gigabyte, with passwords and recovery codes almost certainly inside it — and he will not throw that into a random cloud container. Karan's answer is profiles, not one agent with every key. A research agent gets read-only access to a lot of data and no permission to send or execute. An outbound agent gets write permissions and almost none of the sensitive corpus, plus human-in-the-loop guardrails. Different Claude Codes, OpenClaws, and Codexes, mixed on purpose.

The industry story Labenz has been absorbing is that frontier models climb the same benchmark curve but diverge in feel, and that divergence is stickiness and pricing power. Karan's view runs the other way. If a skill is detailed enough — the path, the trajectory, the grain of the outcome — a model that follows instructions will produce a consistent trace. The working pattern inside Composio is the one a lot of teams already use: let Opus write the skill, then swap to Sonnet to run it. He does that himself for speed. Haiku does not hold up. GPT gets 90 to 95 percent of skills working out of the box; the remaining 5 to 10 percent snag on behavioral quirks.

Those quirks are not abstract. When a job needs polling, Anthropic models write code and wait; GPT stops and asks the user. Habits like that get baked into how a skill is structured, and a swap then feels off. Composio's positioning is the opposite of lock-in: one harness, Anthropic today, OpenAI tomorrow, an open-source model when it is ten times cheaper, with auth and skills in one place and, he claims, about 99 percent reliability after the switch. Enterprises want that optionality because the leaderboard rotates. Skills are addictive, and if they encode one model's manners they are also hard to port, because the manners are not structured.

They are already building the translation layer Labenz wanted after pasting an Anthropic skills post into Claude Code and asking it to rewrite his own. Metrics and benchmarks exist; some of the conversion already runs. Getting from 95 percent to 100 percent is the hard problem, and it is the one they have pointed the work at. Labenz says his worldview is moving in the conversation: more commoditization, less pricing power, skills as the asset and the model as a replaceable executor.

Browsing Composio's catalog, Labenz notices a second class of tool: not a wrapper on an old API, but something built for agents. Karan will not pick winners among partners. Memory is the largest category — Mem0, Zep, Supermemory. Payments have Skyfire, with commerce calls up as background OpenClaw agents try to buy things; Shopify is bending the same way. Search is the other high-frequency bucket: Exa, Firecrawl, Tavily. Traditional systems of record still dominate usage, because that is where the data lives: Slack, Salesforce. The strategy is to plug all of them in and let the user choose.

On who the AI wave actually strengthens, he splits the stack. Core infrastructure — AWS, Cloudflare — gets stronger, because more software will be built on it and dependence only rises as people chat with agents more than with coworkers. Rebuilding those layers is not a startup afternoon. SaaS is a different fight: a mini clone of Slack can serve a small team that never used the complexity it was paying for, but in most cases the interface for using the old apps will change, and incumbents are not slow. Salesforce and Slack are shipping agentic surfaces. Composio works with the startups building those surfaces and with the incumbents doing the same.

The sharp case is Intercom. Labenz is a customer. Fin resolves something approaching 70 percent of tickets across Intercom's base, at 99 cents a ticket, with a speed his own staff cannot match. Composio lists 133 Intercom tools. His napkin math is that a custom skill on those tools might cost on the order of 10 cents in tokens — an 80 to 90 percent save — and would be tuned to his business. Karan does not dodge. Fin is a good product; Composio used it when the prosumer surface launched, because a lot of companies do not want to spend the time. The split is customizability: if you build, you can pin the agent to particular tools and skills and bolt on the rest of the catalog. He does not expect a mass movement. It will happen in bits. Friction will keep falling, and the build-versus-buy line will inch toward build.

Labenz offers a conceptual cut: a tool serves your interest, an agent may represent someone else's. Karan answers with context, not philosophy. If the main agent has the calendar and you delegate booking to a sub-agent that cannot see the board meeting, you get a collision and a "what happened" morning. Light, one- or two-step work should be a tool in the main agent's hand. Exploratory, context-heavy work — deep research, parallel streams that condense back — is where sub-agents earn their keep. Composio already ships some tools that are agents internally: natural language in, a session ID back, a conversation you can continue. In production he points at Claude's team-of-agents, sharing a task list, and at an internal open-source orchestrator that lets one engineer steer 20 to 30 Claude Code or Codex instances.

The company is still hiring in San Francisco, because agents do not yet run without supervision, and the bar is high enough that the bot feels slow. The scaling law he will own is not "headcount goes to zero." At a startup already this AI-first, they need more humans in order to spend more tokens. At incumbents, human capital still dwarfs token spend; as models improve, that ratio moves toward tokens. On the business side, Labenz wants them to resell generic APIs — Brave Search, Perplexity, Brandfetch — instead of making him paste in keys. That product is coming as premium toolkits: one wallet, one dashboard, credits at Composio, so users are not maintaining a pile of accounts and bills.

The last debate on his mind is MCP versus CLI, because it hits the product. They are launching a universal CLI so you do not install one for GitHub, one for Vercel, one for everything else. He still expects a multipolar world. GitHub CLI has been in pretraining for years; models use it well. MCP is now in post-training because Claude Code and Codex use it constantly. Accuracy will not crown a single winner. MCP, he thinks, still wins on control, observability, and auditability, which is why enterprises lean that way. Labenz's edit is that both will mature into two sides of the same coin. Karan agrees, and adds the deciding input: wherever tokens get spent, traces accumulate, and that side gets trained better.