At ten tools, an agent is capable. At a hundred tools, an agent is powerful. At a thousand tools, an agent is dangerous — not because it has too many capabilities, but because the combinatorial space of tool interactions becomes impossible to reason about. The Action Mesh was designed to solve this problem at scale.
The key architectural decision we made early on was to separate tool registration from tool selection. Any team in an organization can register a tool with the Action Mesh by providing a typed schema, a description written in natural language, and a set of capability tags that describe what the tool can affect (read-only, writes-database, sends-external-request, accesses-pii, and so on). Registration is a pull-request-like workflow with a review step, not a runtime API call. This means that the catalog of available tools is always in a known, approved state.
Tool selection happens at task planning time. When the Intent Layer receives a user request, it does not have access to the full tool catalog. Instead, it queries the Action Mesh's semantic index, which returns a ranked list of relevant tools along with their schemas and capability tags. The runtime then restricts the agent's tool access to this returned set, plus any tools explicitly required by a named workflow. This bounded context dramatically reduces the risk of an agent reaching for a tool it was never intended to use.
The capability tag system has proven to be the most valuable part of the design for enterprise customers. Security teams can define policies at the tag level — for example, no agent operating in the customer-support role can use tools tagged sends-external-request unless the task was initiated by a verified supervisor. These policies are enforced by the runtime before any tool is invoked, not by the model, which means they cannot be reasoned around. Policy violations are written to the Audit Log and trigger an escalation event rather than silently failing, giving security teams the visibility they need to respond quickly.