The Tool and Action Plane

A deep dive on the Tool and Action plane. Why standardization changed the economics, why composability changed what agents can do, and why controllable autonomy is the discipline that turns capability into value.

By Abbas Raza, CTO, ReFocus AI

This is the fifth piece in a series on enterprise multi-agent architecture. The flagship laid out five planes and a Trust Fabric. The second piece went deep on the Agent plane and the discipline of harness engineering. The third went deep on the Model plane and the AI gateway. The fourth went deep on the Memory and Knowledge plane and the discipline of curating before storage. This piece goes inside the Tool and Action plane and stays there.

The eight-application day

A senior analyst inside a Fortune 500 procurement organization begins her Monday morning by opening eight different systems in sequence. The vendor system-of-record. The SEC filings archive. The cyber-incident data source. The credit-rating provider. Two carrier portals with no API coverage. The sanctions screening service. The internal risk taxonomy tool. She spends the first two hours of her day copying identifiers between them, reconciling formats, and assembling a picture that no single system holds. By the time she has a coherent view of one vendor, she has performed roughly forty distinct operations across those eight systems.

She does this for a hundred and forty vendors a quarter. The pattern is familiar to anyone who has watched knowledge work happen in a large enterprise. AWS research on enterprise workflows reports that knowledge workers navigate eight to twelve different web applications during standard workflows. The work is not intellectually hard. It is operationally expensive. Every system has its own credentials, its own quirks, its own version of the same entities under slightly different names. The value is not in any one system. It is in the composition across systems, performed patiently, one identifier at a time.

This is the work the Tool and Action plane is built for. Not the reasoning, which lives in the Model plane. Not the recall, which lives in the Memory and Knowledge plane. Not the runtime discipline, which lives in the Agent plane. The Tool and Action plane is where autonomous software actually touches the systems, the data, and the workflows that carry the business. It is where an agent stops being an articulate observer and becomes software that operates.

Every plane in the reference architecture has one core purpose. The purpose of this plane is doing.

The thesis

The Tool and Action plane is the substrate where autonomous software actually does work in the world. Its core value is threefold: it standardizes how agents talk to systems, it makes capability composable across those systems, and it gives you controllable autonomy over what agents are allowed to do with that composed capability.

Standardization matters because without a protocol, every agent needs a bespoke adapter for every system, and the integration problem grows as the product of your agents and your tools. Composability matters because every real business outcome spans systems, and a plane that lets agents chain across them without custom code is what turns “an agent that can do one thing” into “an agent that can accomplish an outcome.” Controllable autonomy matters because doing work in the real world means writing to production systems, and the difference between an agent that produces value and an agent that produces incidents is whether the architecture lets you dial autonomy in and out, action by action.

Security lives inside controllable autonomy as one of its disciplines. So does safety. So does reliability. So does governance. A serious Tool and Action plane treats all four as facets of the same underlying idea: making autonomous action controllable at the architectural layer rather than hoping the agent gets it right.

The remainder of this piece defends each of the three properties and shows what they mean architecturally.

What changed in 2025 and 2026

Six inflection points reshaped what serious looks like on this plane.

MCP became the industry standard. Anthropic launched the Model Context Protocol in November 2024. In eighteen months it went from a company protocol to industry infrastructure. By Anthropic’s December 2025 ecosystem update, monthly SDK downloads across Python and TypeScript had passed 97 million, more than 10,000 active public MCP servers had shipped, and adoption spanned Claude, ChatGPT, Gemini, Microsoft Copilot, GitHub Copilot, Cursor, Windsurf, VS Code, and Zed on the client side. On the server side, Slack, GitHub, Google, Salesforce, Stripe, HubSpot, Shopify, Notion, Linear, Sentry, Figma, and Cloudflare had published official or community-maintained servers. The category consolidated fast because the underlying economic pressure was intense.

Governance moved out of Anthropic. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, making the protocol vendor-neutral and community-governed. The precision matters: not just “donated to the Linux Foundation” in the way I loosely said in the flagship, but donated to AAIF under LF. AAIF is where the working-group governance actually lives.

The protocol matured. In March 2026, the maintainers published a 2026 roadmap organized around four priorities: transport evolution, agent communication, governance maturation, and enterprise readiness. In May 2026, the 2026-07-28 release candidate arrived. It is the largest revision since launch. A stateless core that scales on ordinary HTTP infrastructure. Extensions for server-rendered UIs (MCP Apps, SEP-1865) and long-running work (Tasks). Authorization aligned with OAuth 2.1 and OpenID Connect. W3C Trace Context propagation documented explicitly (SEP-414). A formal deprecation policy so the protocol can evolve without breaking what teams have already built.

Enterprise adoption crossed the production threshold. Stacklok’s 2026 State of MCP in Software report surveyed one hundred senior technical leaders and found 41 percent of software organizations in limited or broad production use of MCP servers, with 45 percent in the pure-software cohort. This is not experimentation. It is production.

Browser automation matured into a first-class action modality. Browser Use reached 89.1 percent on the WebVoyager benchmark across 586 web tasks. OpenAI’s Computer-Using Agent hit 87 percent on the same benchmark. Skyvern 2.0 reached 85.85 percent with a specialty in form-filling. Stagehand v3 shipped in February 2026 as a complete rewrite talking directly to Chrome DevTools Protocol, 44 percent faster than its predecessor. Google shipped an early preview of WebMCP in Chrome Canary in February 2026, developed jointly with Microsoft through the W3C. Browser action stopped being a fallback and started being an equal-class endpoint alongside MCP.

The security surface got named. OWASP published the Top 10 for Agentic Applications in December 2025, peer-reviewed by NIST, the Microsoft AI Red Team, and AWS. The taxonomy formalized what red teams had been finding all year: prompt injection through tool output (LLM01), supply chain vulnerabilities (LLM05), agent goal hijack (ASI01), and their cousins. Named threats produce named mitigations. The mitigations became architectural conventions on this plane.

Six shifts. One direction. The Tool and Action plane went from a wild frontier eighteen months ago to a governed infrastructure layer with named standards, named products, and named consequences. The economics of building agents that do useful work changed with them.

Standardization: from N times M to N plus M

Before MCP, integrating an agent with an enterprise system meant writing a bespoke adapter for every combination of model, provider, and tool. If you had N agents talking to M tools, you had roughly N times M integration pairs to maintain. Adding a new tool meant writing N adapters. Switching model providers meant rewriting M. Every organization I know that built agents in 2023 and 2024 hit a wall around the fifth or sixth tool because the maintenance cost of the adapter layer grew faster than the value the tools added.

MCP replaced that with a protocol on top of APIs. A single client can talk to any MCP server. A single server exposes tools to any MCP client. The N times M problem becomes N plus M. Every additional agent or tool adds one integration, not N or M.

This is the “USB-C for AI” framing that has become the standard shorthand. It is accurate. The protocol standardizes how an agent discovers what tools are available, how it calls them, how they authenticate (OAuth 2.1 as of the June 2025 spec), and how results flow back through a JSON-RPC base protocol. Server-rendered UIs (MCP Apps), long-running work (Tasks), and human-in-the-loop patterns (Sampling and Elicitation) round out the surface.

The reason to care about this at an executive level is not the protocol details. It is the strategic consequence. Standardization changes the economics of building agent-driven products. The unit cost of adding a new capability drops by roughly an order of magnitude when every tool speaks a common protocol. The unit cost of switching model providers drops by roughly the same amount, for the same reason I argued in the Model plane piece. The unit cost of onboarding a new team to build their own agents drops because the plumbing they inherit is already in place. Every one of these unit-cost drops compounds across quarters.

The strategic bet is durable because the industry converged. Anthropic launched it. OpenAI added native MCP support in early 2026. Google followed for Gemini. Microsoft integrated it across Copilot. AWS supports it in Bedrock. In mid-2026, building any new agent integration on a non-MCP protocol requires a specific reason. There will be edge cases, and the piece touches on them below, but the default is MCP and it will remain the default for the foreseeable future.

Composability: what the plane makes possible

Standardization is necessary but not sufficient. The reason it matters is that it enables composability, which is what actually creates value.

An agent that can call one tool well is an assistant. An agent that can chain across seven or eight tools in a single reasoning step is an operator. The move from assistant to operator is where the business value lives, because every real workflow spans systems.

Consider what “assemble a current view of vendor risk” actually requires. The vendor’s identifier in your system of record. Their SEC filings for the last four quarters. Any cyber incidents attributed to them or their subsidiaries in the last twelve months. Their credit rating and the trajectory of that rating. Whether they appear on any sanctions lists. The current status of their SOC 2 report. The commercial history you have with them. The list of customers currently exposed to them. No single system holds any of this. The value is entirely in the composition. A human analyst does this work in two hours, spread across eight applications. An agent operating over a composable Tool and Action plane does it in ninety seconds and returns a structured result.

The compounding effect is where the economics become interesting. Composability is not linear in the number of tools. It is combinatorial. Two composable tools give you two workflows. Ten composable tools give you thousands of possible chains. Twenty give you millions. This is why the enterprise agent market moved so fast in 2025 and 2026. Every new tool published to the ecosystem multiplied the possibility space for every agent that could reach it.

The architectural discipline that produces this compounding is that no tool integration should be written twice, and no agent should have to know the details of any specific tool implementation. Tools speak MCP. Agents call tools through the gateway. The gateway hides transport, authentication, and quirks. The agent reasons about capabilities, not about implementations. The plane’s job is to hide the mess so the reasoning above it can compose.

An adjacent capability worth naming here is Agent-to-Agent communication. Where MCP standardizes agent-to-tool, the emerging A2A protocol standardizes agent-to-agent. In an environment where agents from different organizations transact, coordinate, or subcontract to each other, the composability problem stops being about tools and starts being about agents themselves. The A2A specification is early in mid-2026. The design principles echo MCP: a JSON-RPC-based protocol, capability discovery, authentication, versioning. The gaps A2A fills include long-running task coordination and cross-organizational trust. Complementary technologies for agent payments (x402, Stripe MPP) are emerging alongside it. For a CTO, the pragmatic posture is to assume A2A will matter within eighteen months and to design the Tool and Action plane so a new protocol becomes another endpoint category behind the same gateway, not a rebuild.

Browser automation as a first-class action modality

Composability requires reaching every system where value lives. Some of those systems have APIs. Many do not, or their APIs cover only a fraction of what the UI exposes. In healthcare, EHR portals are the operational surface for scheduling, records, and prior authorization, and the API coverage is famously incomplete. In insurance, carrier portals are the substrate for quoting, endorsement, and renewals, and the API coverage varies dramatically by carrier. In finance, legacy systems and vendor portals are where a lot of the actual work happens, and the API surface can lag the UI by years.

If your agents are going to operate where the work actually happens, they will be driving browsers. This is not a hack. It is a permanent component of a serious agent architecture.

The 2026 capability picture is mature. Browser Use hits 89.1 percent on WebVoyager. OpenAI’s Computer-Using Agent hits 87 percent. Skyvern 2.0 hits 85.85 percent. Stagehand v3 is 44 percent faster than its predecessor. AWS Bedrock AgentCore ships Browser, Code Interpreter, and Identity services as first-class primitives.

WebMCP matters more than any of the benchmark numbers because it changes the trajectory. The Chrome Canary preview shipped in February 2026, developed by Google and Microsoft through the W3C. WebMCP is a protocol for structured AI agent interaction with websites: a Declarative API for HTML forms and standard page elements, and an Imperative API for dynamic JavaScript-driven interactions. The direction of travel is websites explicitly supporting agents rather than agents scraping websites. Once WebMCP is broadly adopted, the browser becomes a first-class action surface in exactly the way MCP made the tool ecosystem a first-class surface.

A legal dimension is worth naming, because it is coming for any CTO whose agents will drive third-party sites at scale. In late 2025, Amazon obtained a preliminary injunction against Perplexity’s Comet browser. The judge found Amazon likely to succeed on its claim that Perplexity violated the federal Computer Fraud and Abuse Act, drawing the distinction that matters: Comet accessed Amazon accounts “with the Amazon user’s permission, but without authorization by Amazon.” The Ninth Circuit stayed the injunction while the appeal proceeds. Perplexity filed a 96-page opening brief in April 2026 arguing the CFAA does not apply to an AI assistant running locally on a user’s device. The case is unresolved. The precedent forming is that a user’s permission to act on their behalf does not automatically override a website owner’s terms of service. If you are planning to build agents that drive third-party sites at scale, this is an issue for your general counsel, not just your architects.

Architecturally, browser action sits behind the same gateway as MCP tools. Sandboxed sessions with per-user identity. Consent flows for third-party access. Audit trails at the browser action level. Human-on-the-loop for anything transactional. The composability story treats browser action as an endpoint category alongside MCP servers, REST APIs, and A2A, not as a separate concern.

Controllable autonomy: the discipline that turns capability into value

Standardization and composability give you an agent that can, in principle, do a great deal. The next question is what it should be allowed to do, when, on whose authority, with what oversight, and with what recovery when it gets something wrong. This is the domain of controllable autonomy, and it is the third property of a serious Tool and Action plane.

Controllable autonomy is not about preventing the agent from acting. That framing is the mistake I see teams make when they first take the discipline seriously. The correct framing is that the plane provides architectural mechanisms for calibrating how much autonomy a given action is allowed to carry. The mechanisms are the same across security, safety, reliability, and governance because the underlying problem is the same: bound the consequence space of autonomous action so that the difference between “the agent got it right” and “the agent got it wrong” is not the difference between profit and catastrophe.

Six architectural disciplines make autonomy controllable. Every one of them belongs at the gateway or in the tool contract, not in each agent’s prompt.

Idempotency by default. Every write action requires an idempotency key. Repeated invocations with the same key produce the same result, not multiple side effects. This is not a nice-to-have. Agents retry. Harnesses recover from crashes. The same action is dispatched twice under normal operation. Without idempotency, controllable autonomy is impossible because the consequence space of a single decision is unbounded.

Dry-run mode on destructive actions. Any tool that mutates production state should also expose a mode that returns what would happen if the action ran, without executing it. The agent can preview. The harness can validate. The human oversight layer can review. In practice, this shifts the failure mode from “the agent did the wrong thing” to “the agent proposed the wrong thing and the gate caught it.” That is the correct place for that failure.

Read-only first, graduated write. New tools are exposed to agents in read-only mode first. Write access is added action-by-action, each one instrumented, reviewed, and gated on a run history that shows the agent uses it correctly. This is how you avoid the failure mode where an agent gets access to something it should not have because it was easier to grant the whole scope than to enumerate specific actions.

Just-in-time credentials. Credentials are minted at the moment of use, scoped to the specific action, and expire in minutes rather than days. The tokens themselves never enter the agent’s context window. The agent receives the results of an action, not the credentials that performed it. This is the single discipline that eliminates the largest category of credential-exposure risk, and it lives at the gateway.

Human-on-the-loop for high-consequence actions. The MCP specification’s Sampling and Elicitation features exist precisely for this. A destructive database migration, a large financial commitment, a customer-facing communication can pause for explicit human confirmation. The pattern is not “review the agent’s log at end of quarter.” It is “the agent stops and asks before it does something you would want to know about.”

Every action traced end to end. From the user’s request, through the agent’s reasoning, through the model call, through the gateway, through the tool, through downstream side effects, back to the user’s screen. W3C Trace Context propagation, now standardized in the 2026-07-28 RC, makes this possible with off-the-shelf tracing infrastructure. Teams that skip this discipline spend their time doing forensics after incidents. Teams that build it spend their time preventing them.

These six disciplines are the mechanics of controllable autonomy. They are what makes the difference between an architecture that lets you trust agents with reading a document today and posting a general ledger entry next quarter, and an architecture that never lets you cross that threshold safely.

The MCP gateway as the load-bearing element

Everything the plane needs to do (standardization, composability, controllable autonomy) has to happen somewhere. The where is the MCP gateway. It sits between your agents and every downstream MCP server, REST API, browser session, and A2A endpoint. Every tool call from every agent goes through it. Everything downstream trusts only the gateway, never the agent directly.

The gateway is where the plane’s three core properties become architecturally real. Standardization lives in the protocol translation the gateway performs across MCP servers, REST APIs wrapped as MCP tools, browser sessions, and A2A endpoints. Composability lives in the tool discovery and authentication the gateway provides so any agent can reach any allowed tool through a single interface. Controllable autonomy lives in the six disciplines the gateway enforces: identity and SSO for every call, JIT tokens scoped to specific actions, tool allowlists per agent and per role, action discipline (idempotency, dry-run, read-only first), blast radius caps per tool and per tenant, and end-to-end audit and trace.

The 2026 market for MCP gateways is real and consolidating. Arcade, Composio, Bifrost from Maxim AI, MCP Manager from Usercentrics, MintMCP, IBM Context Forge, Obot, and TrueFoundry are the names I see most in serious enterprise evaluations. The choice between them is real but secondary to the choice that comes first, which is to have a gateway at all. Direct agent-to-tool connections at any real scale in 2026 is an architectural anti-pattern, for the same reason direct application-to-database connections without a connection pool became an anti-pattern twenty years ago: it does not survive contact with production.

Where security fits

Security is one dimension of controllable autonomy, not the framing of the plane. But it is a dimension that has moved fast enough in the last six months that a serious piece has to name what has changed.

Between late 2025 and mid-2026, the threat surface got specific. OWASP published the Top 10 for Agentic Applications in December 2025. Check Point Research disclosed CVE-2025-59536 in Claude Code (CVSS 8.7), a configuration injection flaw via the Hooks mechanism. Cursor’s MCPoison and CurXecute vulnerabilities (CVE-2025-54136 and CVE-2025-54135) put tool poisoning on the map. CVE-2026-30615 in Windsurf and CVE-2026-27124 in FastMCP added prompt injection to RCE and OAuth misimplementation to the taxonomy. The postmark-mcp package became the first confirmed malicious MCP server in the wild by silently adding a BCC recipient to every email sent through it. In February 2026, the Sandworm_Mode campaign industrialized npm typosquatting against Claude Code, Cursor, and Windsurf. OX Security reported roughly 200,000 potentially vulnerable instances across the ecosystem and demonstrated that nine of eleven MCP registries accepted a proof-of-concept malicious package with no verification. In April 2026, CyberArk extended the tool poisoning family to full schema poisoning: attacks on parameter names, enum values, and response schemas, not just tool descriptions.

The pattern across these incidents is that autonomy plus a shared protocol expands the consequence space of a single compromised component, and that consequence space needs architectural containment. The containment already exists in the six disciplines of controllable autonomy above. JIT credentials cap the blast radius of a compromised server. Tool allowlists constrain which tools an agent can reach. Signed manifests and boot-time schema verification catch rug pulls and schema poisoning. End-to-end trace makes forensic recovery tractable when an incident does happen. The security architecture is not separate from the controllable autonomy architecture. It is the same architecture, viewed from a different angle.

The practical implication is that CTOs who put the gateway in place, adopt JIT credentials, enforce idempotency and dry-run at the tool contract, and instrument end-to-end trace have most of the security discipline they need to withstand the threat surface as it exists today. The specific threats will keep shifting. The architectural mitigations were valuable before the threats emerged and remain valuable as the threats evolve.

A worked example: the Risk Reassessment agent’s Tool and Action plane

Recall the Risk Reassessment agent from the harness, model, and memory pieces. Its job is to assemble a current view of a vendor’s risk profile by pulling SOC 2 history, security incident records, financial filings, and fresh external signals, then producing a structured risk score.

The composition it performs in one reassessment run is the value the plane creates.

The agent calls fourteen distinct tools across a typical run. Three are MCP servers built in-house: the vendor system-of-record, the SOC 2 archive, and the internal risk taxonomy service. Six are third-party MCP servers wrapped through commercial connectors: the SEC filings API, the cyber-incident data source, the vulnerability database, the news signal aggregator, the credit-rating provider, and the sanctions screening service. Three are traditional REST APIs that predate MCP and are exposed through a gateway-side adapter presenting them as MCP tools. Two are browser-automation flows against carrier portals that do not have API coverage, running in sandboxed Chrome sessions with per-user consent.

The composability point is not that any single one of these tools is impressive. It is that in ninety seconds the agent has assembled a coherent picture that a human analyst would spend two hours producing across the same fourteen systems. The reasoning above the plane is one third of the value. The composition the plane enables is the other two thirds.

Controllable autonomy shows up in the way the plane holds together at scale. The agent runs read-only against ten of the fourteen tools and never asks for more. Two tools have dry-run modes that the agent uses to preview any submission against a carrier portal before executing. Two tools require explicit human confirmation on final submission, which the harness surfaces through a workflow-native UI. Every call carries a JIT token scoped to the specific action, minted at the moment of use, valid for four minutes. Every action is traced end to end. When the schema drift detection on the news signal aggregator noticed a change in the tool description on a Tuesday morning, the aggregator was removed from the allowlist within an hour. No agent had used the changed version. The incident cost was zero. But the value the plane produced the day before, and the day after, was several thousand vendor reassessments performed at roughly one three-hundredth the analyst-hours the same work would require without composable, controllable, standardized tool access.

That is what one agent’s Tool and Action plane looks like when it works. The value is composability at scale, held together by controllable autonomy.

The 90-day move

If you are reading this and wondering where to begin, here is what I would do this quarter.

Stand up the MCP gateway. Pick one, install it, route every tool call in your agent codebase through it within four weeks. No exceptions. Everything goes through it. This is the keystone investment for this plane, the same way the AI gateway was for the Model plane.
Move to just-in-time credentials. Any tool that currently uses a long-lived token or API key gets rewired to mint tokens at the moment of use, scoped to the specific action, expiring in minutes. The agent never sees the credential.
Enforce idempotency and dry-run at the tool contract level. Every write action requires an idempotency key. Every destructive action exposes a dry-run mode. Build this into the tool definition, not into individual agent prompts.
Instrument audit and trace end to end. W3C Trace Context propagation through the gateway to downstream tools. Integration with your existing SIEM and APM. Every action tied back to the user, the agent, the model, and the intent.
Design browser action as a first-class modality. Sandboxed sessions, per-user identity, consent flows, human-on-the-loop for anything transactional. Do not treat it as a stopgap. It is a permanent component of the plane.

That is roughly a quarter of focused work for a small team. The payback shows up immediately as reduced integration cost, and compounds as your agents start composing across more tools and taking on higher-consequence actions that would have been unsafe without the discipline.

What this means

The flagship made the case that the model is not the product. The architecture is the product. The harness piece refined that claim into the runtime scaffolding that turns a model into a reliable agent. The model piece refined it into the substitutable, tiered portfolio that absorbs model market churn. The memory piece refined it into the four typed memory stores and the discipline of curating before storage. This piece refines it into the standardized, composable, controllable action surface where autonomous software meets your production systems.

You are not building a chatbot with tool calls. You are building a system that operates against your business, your customers, and your data, autonomously and at scale. The Tool and Action plane is the surface on which that operation happens. Standardization changes the economics of building it. Composability changes what it can do. Controllable autonomy changes what you can trust it with. The three properties are not independent. They are the same discipline expressed at different levels.

Stand up the MCP gateway. Move to just-in-time credentials. Enforce idempotency and dry-run at the tool contract. Instrument end-to-end trace. Design browser automation as a first-class modality. Watch A2A. Assume the threat surface will keep expanding, and design so that the same architecture that produced value yesterday continues to produce it as the surface evolves.

The sixth and next-to-last piece in this series goes deep on the Orchestration and Experience plane: how narrow agents compose into outcomes, why the topology of composition matters more than the individual agents, and why chat is the prototype for the interface rather than the interface itself. The Trust Fabric closes the series after that.