Do not give every AI agent every tool

The first extra tool feels harmless.

A support agent gets ticket access. Then someone adds a browser session so it can check an order page. Then an MCP server connects the data warehouse. Then a developer points it at a local tool index. Then a workflow skill appears because it saves three clicks.

Each addition has a good reason. The mess shows up later, when the agent has more ways to act than the job actually needs.

That is the operations problem hiding behind agent adoption: not whether tools are useful, but whether every agent should see every tool all the time.

Most should not.

Capability sprawl is the new shadow IT

The best small signal I found this week was not a giant vendor launch. It was a tiny GitHub project with a boring, useful premise.

The AI Capability Registry describes itself as dynamic capability routing for AI agents. Instead of stuffing every agent with a static instruction block, a broad pile of tools, or every available MCP server, the registry tries to load the right skills, workflows, MCP servers, and integration instructions only when the current task needs them.

That sounds niche until you look at how agent work actually spreads inside a company.

A marketing team wants research and publishing helpers. Support wants ticket triage. Finance wants invoice follow-up. Engineering wants coding agents. Operations wants a browser agent for vendor portals. Nobody is trying to create a tangled tool estate. They are just approving one useful shortcut at a time.

The registry README names the problem clearly: teams need something between a minimal per-agent setup and everything-enabled-by-default capability sprawl. It also warns that connecting the full registry can use substantially more model context and tokens than a minimal static setup.

That warning matters. Every extra capability has a cost. It can add context, latency, ambiguity, review burden, and security surface. Sometimes the cost is small. Sometimes it is the difference between a narrow assistant and an undeclared operations system.

Tool access should be routed, not sprayed

There is a practical reason to route capabilities instead of enabling them by default: agents are literal about affordances.

If the tool is visible, the model may consider using it. If the integration instructions are loaded, they compete for attention. If the browser is available, the workflow may start browsing when a structured lookup would have been safer. If ten MCP servers are in reach, a simple ticket summary can become a tour through systems that did not need to be touched.

This is not only a security concern. It is a quality concern.

A small support classifier should not need the same context as a refund investigator. A refund investigator should not need the same tools as an account-change agent. A browser agent checking public order status should not inherit the same capabilities as an internal finance workflow.

The capability set should follow the job.

A useful first catalog can be simple:

The catalog is not busywork. It lets a manager, operator, developer, and security reviewer argue about the tool list before the agent uses it.

Local tool indexes make the upside obvious

The capability-routing problem is not theoretical. Tool lists are already getting huge.

Open Agent Tools Coder says it supports more than 141,000 tools through open-agent-tools retrieval indexes. The project uses local indexes so smaller self-hosted models can use already-written source code instead of spending frontier-model tokens rebuilding work that exists on disk.

That is an interesting engineering direction. It points to a future where small models do more useful local work because they can find the right function, file, or command at the right moment.

It also makes the operator question impossible to ignore.

If an agent can theoretically choose from thousands of local capabilities, the important control is no longer a single allowlist written once. It is routing: which subset is available for this job, under this role, in this repo, with this level of review?

The answer will not be the same for every team. A local coding agent working in a test repo can have a wider sandbox. A customer-facing workflow needs a narrower set. A finance workflow needs stricter write controls. A marketing draft workflow may need source links and brand rules but no production credentials.

The capability list is becoming infrastructure. Treat it that way.

Browser agents raise the stakes

Browser automation is where loose capability routing gets expensive.

Libretto's map of AI browser automation tooling describes a fragmented surface: browser automation frameworks, agent browser tools, browser agents, cloud infrastructure, and agent-assisted automation. Buyers may think they are approving one category called "browser agent." In practice, they are approving a stack of decisions.

Which browser session? Which profile? Which credentials? Which pages? Which actions? Which files can be downloaded? Which form submissions are allowed? Which actions stop for review?

Those are capability-routing questions.

A browser agent that reads a vendor invoice portal is not the same as one that can submit payment changes. A browser agent that checks public competitor pages is not the same as one that opens a logged-in customer account. A browser agent that drafts a form is not the same as one that clicks save.

The tool name hides the difference. The route should expose it.

This is where BaristaLabs' usual advice still applies: keep the first workflow narrow, define the data boundary, put risky actions behind an approval policy, and leave an agent receipt for anything customer-visible or system-of-record adjacent.

Open schemas help, but the operating habit matters more

Open Envelope's schema docs show another part of the same shift. The project describes an open standard for composable AI agent team definitions: agents, roles, hierarchy, escalation paths, required secrets, and adapters. It also emphasizes editor validation, local validation, CI/CD checks, version control, access policy, human gates, scheduling, run events, webhooks, idempotency, rate limits, and security/isolation.

That is useful because it makes agent teams inspectable.

In the Hacker News discussion, Open Envelope's author described the schema as a portable declaration for "roles, supervisor/sub-agent hierarchy, access policies, human gates, schedules." Another commenter raised the right caveat: a static team definition does not solve runtime hazards by itself. Two agents can read the same artifact, one can update it, and the other can keep acting on a stale version.

That is exactly why capability routing should not be treated as paperwork.

The catalog says what should be available. The runtime still has to enforce it. The review flow still has to catch exceptions. The logs still have to show what happened. The team still has to remove tools that create noise or risk without value.

A five-step routing habit for small teams

You do not need a full platform to start. You need a habit that prevents tool access from becoming invisible.

First, list the agent workflows you actually run. Not the tools. The jobs. Ticket triage, refund drafts, invoice follow-up, lead enrichment, reporting, QA review, vendor portal checks.

Second, list the capabilities each workflow uses. Read tools, write tools, browser sessions, MCP servers, local indexes, shared drives, inbox access, customer records, analytics exports, scheduling triggers, notification channels.

Third, mark the default status of each capability:

• Approved: safe for the named workflow as designed.
• Candidate: useful, but not reviewed enough for production.
• Restricted: allowed only with human approval or a narrower role.
• Denied: not needed for this workflow.

Fourth, make new capabilities go through the same review path as other operational changes. A new MCP server is not "just a connection." A new browser profile is not "just convenience." A new write tool is not "just one endpoint." Each one changes what the agent can attempt.

Fifth, prune. Capability catalogs should get smaller after pilots, not only larger. If a tool is never used, remove it. If a tool creates bad suggestions, restrict it. If a workflow only needs three capabilities, do not load twenty because they are available.

The best agent setup is not the one with the longest tool list. It is the one where the tool list matches the work.

The first question before the next tool

Before you add the next integration, ask a boring question:

What job needs this capability, and which jobs should never see it?

That one question turns AI adoption from a pile of shortcuts into a managed workflow. It forces the team to name the role, the route, the review status, and the risk before the capability becomes ambient.

For small teams, this is a practical way to stay fast without letting every pilot become shadow infrastructure. Use the Responsible AI hub to define review expectations, connect the tool list to a narrow process automation path, and keep the catalog small enough that people can still understand it.

If your agent pilot has become a growing shelf of tools, browsers, MCP servers, and helper scripts, talk to BaristaLabs. We can help turn the pile into a route.