Tools are not the bottleneck anymore

Enterprise AI teams are quickly moving past the question of whether agents can call tools. The more interesting question is whether an agent should call a particular tool in a particular context.

Modern agent systems are gaining access to APIs, MCP servers, workflows, internal platforms, data products, search indexes, automation scripts, and other agents. In isolation, this looks like progress. More tools should mean more capability. More integrations should mean more useful agents.

But at enterprise scale, the relationship is not that simple.

Every new tool expands what an agent can do, but it also expands the decision surface. A supervisor agent may need to choose between similar workflows. A coding assistant may need to decide whether to search documentation, inspect logs, open an issue, run a deployment tool, or ask for human approval. A business-facing agent may need to decide which system is authoritative, which data boundary applies, and whether the user has the right permission for the requested action.

The hard part is no longer only tool execution. It is knowing what should be executed in the first place.

That is the space I think of as capability resolution.

More tools create more ambiguity

A simple agent with five tools can often rely on prompt instructions and tool descriptions. The model can read the list, infer intent, and select a reasonable function. This works well enough for demos and constrained workflows.

The problem changes when the tool set grows.

Once an agent has dozens or hundreds of possible capabilities, tool selection becomes fragile. Tools overlap. Names are inconsistent. Descriptions are written by different teams. Similar capabilities may have different risk levels, data scopes, authentication requirements, freshness guarantees, or operational owners.

At that point, “just give the agent more tools” stops being a scaling strategy.

More tools increase potential capability, but they also increase ambiguity. If that ambiguity is resolved only inside the agent loop, the system becomes harder to predict. The agent has to reason through too many options at the same time it is trying to solve the user’s task.

The failure mode is subtle. The system may appear intelligent because it keeps trying. But the retry loop can hide the fact that the first decision was wrong.

Tool selection becomes a platform problem

At small scale, tool selection feels like prompting. At larger scale, it becomes a retrieval, ranking, policy, and context problem.

The system needs to retrieve relevant capabilities from a larger catalog. It needs to rank them based on fit. It needs to understand whether the capability matches the user’s intent, the agent’s task, and the current environment. It needs to account for constraints such as region, data scope, freshness, authentication, risk tolerance, and operational maturity.

It also becomes a governance problem.

Enterprise platforms need to answer not only “which tool did the agent call?” but also “why was this capability selected?” and “what alternatives were considered?” Without that trace, agent behavior is difficult to debug and difficult to trust.

This is why capability resolution should not be treated as an incidental prompt inside an agent loop. It deserves to be a first-class platform layer.

The missing layer

Capability resolution is the layer between an agent’s intent and a tool’s execution.

It does not execute the tool. It does not run the workflow. It does not replace the agent. It helps the system decide which capability is the best fit before execution begins.

A useful resolution layer should consider the user intent, the agent task, the constraints, the authentication and risk preference, and the environment context. It should return ranked candidates, not just a single tool name. It should explain why a capability is a fit, what permissions it needs, what risks it carries, and what conflicts exist.

That gives the agent a better starting point. It also gives the platform team a better control point.

Before execution, resolve capability

The next phase of agentic AI will not be won only by giving agents longer tool lists. It will require better systems for deciding which capabilities should be used, under which constraints, with what risks, and with what explanation.

Execution matters. But before execution, there is a decision. That decision needs architecture.

Capability resolution is the missing layer between agents and tools. It is where intent becomes a ranked set of possible actions. It is where platform policy meets runtime context. It is where an enterprise can reduce ambiguity before an agent acts.

This is the problem space I am exploring through Lattivia.

The goal is not to build another place to list tools. The goal is to make agent systems more reliable before they act.