Beyond Chatbots: How Enterprises Should Actually Deploy AI Agents

#Why does this conversation need a new starting point?

A customer contacts a large enterprise on a Tuesday afternoon. She wants a refund on a service charge she was billed twice. The request routes to an AI agent, which is the kind the company just rolled out and the kind every industry is talking about.

In the version of this story the company wants, the agent listens, pulls up her account, confirms the duplicate charge, issues a refund of thirty-two dollars, and tells her the credit will appear in two business days. The interaction takes ninety seconds, and she ends the call satisfied. The company just handled a service request at a fraction of the cost of a human representative.

In the other version of the story, which uses the same underlying technology, the customer mentions near the end of the call that she has been frustrated with her account in general. The agent interprets this as a request for goodwill, and it refunds not just the duplicate charge but every fee on her account for the last six months, which totals $847. It then offers her a complimentary upgrade to a premium tier she does not qualify for. None of this was authorized, and none of it reflects company policy. The agent took these actions because, in the moment, they seemed reasonable based on what the customer said.

Now multiply that scenario across ten thousand interactions a day.

Both versions are possible from the same underlying technology, and the architectural choices an enterprise makes determine which version it actually gets. The answer is not that the company should use a smarter AI. The answer is that the company needs a specific way of assembling the AI, the enterprise systems, and the rules that connect them. This post walks through that assembly.

#What is an AI agent, really?

The phrase "AI agent" is doing a lot of work in industry conversations right now, and it often hides what is actually different about the technology. A chatbot produces words. An agent takes actions.

A chatbot can tell a customer that her account information is available in the mobile app. An agent can look up the information and read it back to her. A chatbot can explain how to file a support ticket. An agent can open the ticket, attach the documentation, and email her a confirmation number. The difference is small in description and enormous in consequence, because the agent is actually doing things inside the enterprise's systems. The agent has hands.

Once a system has hands, the question every executive needs to ask shifts. The old question was whether the chatbot's answers were accurate. The new question is what the agent is allowed to do, and what happens when it does the wrong thing. This shift is the reason an enterprise's existing AI governance framework, which was built for models that produced predictions and recommendations, is incomplete for agents.

Most companies today are running into one of two failure modes. The first failure mode is the chatbot that cannot do anything useful, because customers are unimpressed and employees route around it. The second failure mode is the agent that can do too much, because it is connected directly to enterprise systems with little governing what it is permitted to do. The refund story above is an example of the second failure mode.

#Has the threat model actually changed?

Engineering leaders are accustomed to a threat model in which the credential is the gate. An API key authenticates a caller, and the caller is presumed to act in accordance with the application logic that wraps the credential. The application code defines the legal action space, and the credential merely opens the door to that code.

AI agents invalidate this presumption. An agent that holds a credential is not running deterministic application logic. The agent is running a probabilistic policy derived from natural-language inputs, some of which originate from end users, some of which originate from retrieved documents, and some of which originate from upstream tool results. Each of these input sources is a potential injection vector. The agent's selection of which tool to call, and with which arguments, is the output of a model whose decision boundary is not fully specified and not fully testable.

The consequence is that the credential no longer bounds the action space. A correctly authenticated agent can issue a correctly formed API call that the company never intended the agent to make. The security industry has begun to describe this property as the collapse of the authentication-authorization distinction at the agent boundary. The agent is authenticated, and from the perspective of the downstream system the call is authorized, but neither property tells the company whether the action was appropriate.

There is a related architectural point worth naming directly. MCP, as a connection protocol, concentrates trust in a single artifact, which is the authentication token the server holds for the underlying system. If that token is valid and the call is well-formed, the action proceeds. The token is therefore a single point of failure, and any compromise or misuse of the agent above the token translates directly into action against the downstream system.

The architectural response to this shift is to move the authorization decision out of the agent's runtime context and into a layer the agent cannot influence. The agent should not see API surfaces that it is not permitted to use, because any surface the agent sees is a surface the agent can be induced to call.

#What does the right architecture look like?

The architecture has three layers, and each layer plays a distinct role. The first layer is Connection, which standardizes how agents talk to enterprise systems. The second layer is Capability, which sits above the connection layer and exposes only the narrow, permissioned, business-aware actions an agent is allowed to perform. The third layer is the Control Plane, which governs which agent receives which capability, logs every invocation, monitors performance, and enables rollback.

A single example will make the three layers concrete. Imagine a sales representative talking to her AI assistant. She says, "Add a new prospect record for Johnny Walker, phone number 555-0142, met him at the Chamber of Commerce lunch last week." She wants the AI to do something specific, which is to create a record in the company's customer relationship management system.

For this simple action to happen safely, three different things need to be true. The AI needs to be able to communicate with the CRM system at all, which is the job of the Connection layer. The AI needs to be limited to appropriate actions once connected, because the CRM can do hundreds of things including deleting records and exporting customer lists, and that limitation is the job of the Capability layer. The company needs to see what happened, decide who is allowed to do what, and reverse course if something goes wrong, and that responsibility falls to the Control Plane. The next three sections take each layer in turn.

#How does the Connection layer work?

The integration problem MCP solves

A large enterprise runs on dozens of systems. The ERP platform is one system. The CRM is another. The HR information system, the support and ticketing platform, the document repository, the data warehouse, and dozens of smaller line-of-business applications are all separate. Each of these systems has its own API, its own authentication model, and its own data schema.

Until recently, connecting an AI to these systems meant writing a custom integration for each system, for each AI use case. The company ended up with what the industry calls the N-by-M problem, in which N agents need to talk to M systems, and the number of integrations grows as the product of the two. The integrations were inconsistent, the audit trails were inconsistent, and the cost of every new use case was high.

What MCP is and how it works

The industry has now converged on an open standard called the Model Context Protocol, which is usually shortened to MCP. The protocol originated at Anthropic in late 2024, and every major AI provider has since adopted it, including OpenAI, Google, Microsoft, and AWS. In December 2025, the protocol was transferred to the Agentic AI Foundation, which is part of the Linux Foundation. The protocol is now the de facto standard, in roughly the way USB became the standard for connecting devices to computers.

The architecture of MCP is straightforward. There are three roles. The Host is the AI application the user interacts with. The Client is created by the host and maintains a one-to-one connection to a single MCP server. The Server is a lightweight process that wraps a specific system or data source and exposes it through the protocol. Communication happens over JSON-RPC 2.0, and remote MCP servers use OAuth 2.1 for authentication. MCP servers expose three primitives, which are Tools, Resources, and Prompts. Tools are actions the agent can take. Resources are read-only data the agent can retrieve. Prompts are reusable templates that shape how the agent reasons about a task.

What MCP delivers and what it does not

The practical benefit of MCP for the enterprise is that connection becomes a commodity. The company builds one MCP server for each underlying system, and any approved AI agent can then talk to that system through the same standardized interface. The integration cost drops. The authentication and audit chokepoints become consistent. The choice of AI vendor becomes decoupled from the integration work the company has already done, which means the company is not locked in if a better model appears next year.

There is a critical limitation to MCP that determines everything about the layer above it. An MCP server, by default, exposes the full set of actions the underlying system can perform. An MCP server connected to the CRM can read every record, create every record, delete every record, and export every record that the underlying credentials permit. MCP standardizes how the AI connects to the system. MCP does not, by itself, narrow what the AI is permitted to do once connected. For a regulated or risk-sensitive enterprise, that gap is the entire problem. The next layer is the answer.

#How does the Capability layer narrow the agent's reach?

What a capability actually is

The Capability layer is the answer to the question that MCP leaves open. The principle is simple to state. The agent should be granted only the specific actions required for its job, and never the raw system underneath.

A capability is a curated action that the enterprise has explicitly defined and approved. A capability has a clear business purpose, such as "issue a standard refund of up to $500 to a verified customer who is within the return window." A capability has defined inputs and defined outputs. A capability has business rules baked in, such as the return-window check, the customer eligibility check, and the dual-control threshold. A capability has explicit constraints, such as the maximum dollar amount, the allowed customer segment, the permitted time of day, and any other rule the company wants to enforce.

The difference between an MCP tool and a capability is the difference between an instrument and an authorized procedure. An MCP tool is a thin wrapper over a system action. A capability is a business action the enterprise has defined, governed, and approved.

The refund example, revisited

Consider the refund story from the start of this post. In the version that goes wrong, the AI is connected to the billing system through a generic refund tool, and the AI decides how much to refund based on its interpretation of the conversation. In the version that goes right, the AI is granted a specific capability called issue_duplicate_charge_refund, which takes the disputed transaction as input, verifies that a matching duplicate exists, refunds only the duplicate amount, and logs the action. The capability cannot refund six months of fees, because the capability is not designed to do that. The capability cannot upgrade an account, because that action lives in an entirely different capability that this agent was never granted.

The same principle, applied across the enterprise, produces a clear pattern. The customer service agent is granted account-lookup, statement-retrieval, and standard-refund capabilities. The customer service agent is never granted the contract-modification capability. The IT support agent is granted ticket-creation and password-reset capabilities. The IT support agent is never granted the procurement-approval capability. This pattern is the AI equivalent of role-based access control, which the enterprise already uses for human employees. The pattern is the primary tool the company has for limiting the consequences of any single mistake.

Why capabilities, and not prompts, are the unit of control

There is one further point that matters for executives, because it determines whether the architecture is actually defensible under scrutiny. A natural-language instruction to an AI, which the industry calls a prompt, can sometimes be talked around by a clever user. A capability, in contrast, is an enforceable contract that lives in code. The constraint that says "no refund over $500 without manager approval" is not a sentence in a prompt that the AI might choose to ignore. The constraint is a check that runs every time the capability is invoked, and the AI has no way to bypass it. This property is what makes the capability layer suitable for a regulated or high-stakes environment.

From single point of failure to dual point of failure

The capability layer also changes the trust topology in a way that is worth stating directly. MCP, on its own, is a single point of failure architecture, because the authentication token to the underlying system is the only thing standing between the agent and any action the system supports. A compromised agent, a successful prompt injection, or a misinterpreted instruction translates immediately into a real action, because the token is valid and the call is well-formed. The capability layer turns this into a dual point of failure architecture, because two independent things must now go wrong for an unauthorized action to occur. The agent must select an action, and the capability's policy block must independently permit that action under the runtime conditions. The token alone is not sufficient, because the policy block evaluates the request against business rules, parameter constraints, and approval thresholds before any downstream call is made.

This is the zero-trust principle applied one level deeper than traditional security thinking applies it. Conventional zero trust assumes the network is hostile and authenticates every request. The capability layer assumes the agent itself is potentially hostile, or at minimum potentially mistaken, and authorizes every action against an independent policy that the agent cannot see or modify. The agent is treated as an untrusted caller, even when it is operating with a valid credential, because the credential is no longer a reliable signal of intent. Trust is granted to the specific action, evaluated at the moment of invocation, against rules the enterprise controls.

Design discipline: capabilities map to business actions, not API endpoints

There is also a design discipline worth stating explicitly. Capabilities should be authored to match business operations, not to match underlying API endpoints. A capability is not a thin proxy over a REST call. A capability is the embodiment of a sanctioned business action, and its boundary should match the boundary of a single auditable decision. If a business action requires three downstream calls to complete, those three calls belong inside one capability. If a single API endpoint supports five different business actions through a mode parameter, those five actions belong in five different capabilities, because the company wants to authorize them independently.

Every capability that produces a side effect should also accept an idempotency key in its input schema and should enforce idempotent semantics in its policy block. Agents will retry, networks will partition, and the cost of double-issuing a refund or double-initiating a transaction is high. Idempotency is a correctness property, not an optional polish item.

#How does the Control Plane govern everything?

The role of the Control Plane

The Capability layer is only as valuable as the system that manages it. The Control Plane is the infrastructure that sits above the Capability layer and makes the entire architecture operable, auditable, and reversible. The Control Plane is what turns a collection of capabilities into a governed program the enterprise can defend.

The Control Plane has seven components, and each component answers a specific question an auditor or a board member is likely to ask.

The seven components

The first component is the capability registry. The registry is a single, versioned catalog of every capability in the enterprise, and it records who owns each capability, which agents are permitted to access it, which underlying systems it touches, and the current approved version. The registry answers the question, "What is your AI actually doing inside the company?"

The second component is the policy engine. The policy engine maps each agent, and the human user behind it, to the capabilities and constraint sets the agent is permitted to use. The engine answers the question, "Who decided this AI could do that?"

The third component is the approval workflow. New capabilities, and changes to existing capabilities, require formal review. The reviewers typically include the business owner, the risk function, the compliance function, and the engineering owner. The workflow answers the question, "How does a new AI capability get into production?"

The fourth component is version control and rollback. Every capability, including its description, its inputs, its constraints, and its underlying logic, is versioned. A change to a capability is a new version, not an edit in place. A version that misbehaves in production can be reverted in the same way a software deployment is reverted. Version control and rollback answer the question, "What do you do when something goes wrong?"

The fifth component is description management. The natural-language description that tells the AI when to use a capability is itself a control artifact, because the description shapes how the AI behaves at runtime. The description is reviewed, versioned, tested, and locked, in the same way the underlying code is. Description management answers the question, "How do you know the AI is using each capability for the right purpose?"

The sixth component is audit logging. Every capability invocation is logged as a structured event. The log records which agent invoked the capability, which session it belonged to, which customer or account context it operated in, which inputs were passed, which constraints were checked, and what the outcome was. Audit logging answers the question, "Show me, for the last hundred refunds your AI issued, exactly what it did and why."

The seventh component is continuous monitoring. The Control Plane reports on usage frequency for each capability, success and failure rates, attempts to breach constraints, escalations to human review, and the health of the systems each capability depends on. Continuous monitoring answers the question, "How would you know if the AI started misbehaving, and how quickly?"

The diagnostic property the Control Plane delivers

Taken together, these seven components produce a property that no other architecture can deliver. When something goes wrong, the company can distinguish among three different failure modes. Either the agent selected the wrong capability for the situation, or the agent selected the correct capability but the capability returned bad data from a downstream system, or the capability's constraint worked as designed and correctly blocked the action. A general-purpose chatbot architecture cannot tell these three failures apart, but a Capability-and-Control architecture can, because each capability invocation is a separately logged event with its own success or failure signal. This property is what makes ongoing oversight of AI in production actually tractable.

#What happens during a single agent request?

It is useful to sketch the runtime data flow end to end, because the layering becomes easier to internalize when the path of a single request is visible.

The user issues an instruction to the host application. The host maintains the conversation state and is responsible for assembling the prompt that will be sent to the model. The host queries the policy engine for the set of capabilities the current agent identity is bound to, and the host receives a structured list of capability identifiers, descriptions, and input schemas. The host injects this list into the model's tool definitions for the turn. The host does not inject any capability the agent is not currently bound to, and the host does not inject the underlying MCP tool surface.

The model produces a response. If the response is a tool call, the response names a capability and supplies arguments conforming to the capability's input schema. The host receives the tool call and forwards it to the capability runtime, along with the agent identity, the human principal, and the session context.

The capability runtime resolves the capability identifier to the currently bound version through the registry. The runtime evaluates the policy block, which performs its preconditions and emits a structured policy-decision event into the observability stream. If the policy denies the call, the runtime returns a structured denial to the host, the host surfaces the denial to the model, and the conversation continues. If the policy escalates the call, the runtime enqueues the request for human approval, returns a pending status to the host, and the conversation is suspended until the approval resolves.

If the policy permits the call, the runtime requests scoped credentials from the broker, invokes the relevant MCP tools or direct APIs against the downstream systems, and collects the results. The runtime applies any post-call shaping required by the output schema, emits the completion event into the observability stream, and returns the structured result to the host. The host returns the result to the model, and the model continues its reasoning.

Several properties of this flow are worth noting. The model never sees the credentials. The model never sees the raw MCP tool surface. The model sees only capability-shaped inputs and capability-shaped outputs. The policy decisions are auditable as structured events, not as inferred behavior. The downstream systems see calls that originate from a known capability, on behalf of a known agent identity, with credentials scoped to the call. The company can answer, for any request in the past, who did what, why the system permitted it, and what the result was.

#What does this mean for the governance frameworks the enterprise already runs?

An enterprise does not need to be told that AI is subject to oversight. The enterprise needs to understand how the proposed architecture maps to the specific frameworks auditors, regulators, and risk committees will apply. The four frameworks below are the ones that come up most often.

Model risk management

Model risk management guidance, such as the Federal Reserve's SR 11-7 in financial services or analogous internal model governance programs in other regulated industries, expects that models used in significant decisions are documented, validated, monitored on an ongoing basis, and subject to change management. Each capability in the architecture is a documented model component with a stated business purpose, defined inputs, defined outputs, and known limitations. The audit logs and monitoring metrics provide the ongoing performance evidence these frameworks require. The versioning and approval workflow provide the model change management discipline. The capability registry provides the model inventory.

Third-party risk

Third-party risk guidance, which exists in some form across financial services, healthcare, and federal contracting, emphasizes that the enterprise, not its vendors, is responsible for the safe operation of its systems. MCP, by standardizing the connection layer, clarifies the boundary between the enterprise and the vendor. Capability constraints, defined and enforced by the enterprise, are contractual control points the company holds regardless of which AI vendor is in use. The Control Plane gives the enterprise, rather than the vendor, the authoritative logs. If the vendor changes, the capabilities and the logs remain.

The NIST AI Risk Management Framework

The NIST AI Risk Management Framework organizes AI governance into four functions called Govern, Map, Measure, and Manage. The capability registry implements Map. The policy engine and the approval workflow implement Govern. The audit logging and the monitoring metrics implement Measure. The rollback procedures and the constraint enforcement implement Manage. An enterprise that adopts this architecture is in a defensible position against the NIST framework by construction.

Sector-specific rules

Sector-specific rules, such as NYDFS Part 500 for financial institutions, HIPAA for healthcare, and the growing set of state-level AI rules, require access controls, audit trails, third-party governance, and incident response. The Capability layer provides access control at the granularity AI requires. The Control Plane's audit logs provide the audit trail. The MCP boundary and the capability ownership in the registry provide third-party governance. The monitoring and rollback functions provide the incident response capability.

The pattern across all four frameworks is the same. The architecture is not a workaround for compliance. The architecture happens to be what compliance is asking for, because the regulatory frame and the engineering best practice have converged on the same answer.

#What should executives ask at the next AI committee meeting?

The following questions are designed to be practical. Each question maps to a specific component of the architecture this post has described, and each question has a right kind of answer the team should be able to produce.

The first question is whether the team can show the capability registry. The team should be able to produce a current list of every AI capability the enterprise has approved, who owns each one, and which agents are permitted to access which capabilities. If the enterprise cannot produce a registry, the enterprise does not yet have a Capability layer.

The second question is what the constraints are on the three highest-risk capabilities. The team should be able to walk through the dollar limits, the approval thresholds, the customer segment rules, and any other policy constraints embedded in those capabilities.

The third question is whether the team can show the audit log for the last one hundred invocations of one of those capabilities. The log should show, for each invocation, which agent ran the capability, what inputs were passed, which constraints were checked, and what the outcome was.

The fourth question is who approves a new capability, and what the turnaround time is. The team should describe a workflow that involves the business owner, the risk function, the compliance function, and the engineering owner, with a defined service-level agreement.

The fifth question is how the team would detect a capability failing in production, and how quickly the team would know. The answer should reference specific monitoring signals, not a general assurance that someone would notice.

The sixth question is what the rollback procedure is, and when it was last tested. A rollback procedure that has never been tested is not a rollback procedure.

The seventh question is where MCP, the Capability layer, and the Control Plane sit in the architecture diagram, and who owns each layer. If the team cannot answer this question clearly, the enterprise has architectural work to do before it puts AI agents in front of customer-facing or revenue-critical workflows.

#How should an enterprise actually start?

The architecture this post describes is substantial, and a serious enterprise is in a strong position to build it correctly from the outset. The recommended path has four steps, and the sequencing matters more than the pace.

The first step is to pick a single high-value workflow and instrument it fully. The company should select a workflow where the business impact is meaningful and the operational risk is well understood. The team should define the three to five capabilities that workflow requires and build the Control Plane logging from day one. The agent should run in a shadow mode, where its recommendations are reviewed by a human before any external action is taken, until the capability set and the monitoring have established a confident performance baseline. The purpose of starting with one workflow is not to limit ambition. The purpose is to prove the architecture under real conditions before scaling it across the enterprise.

The second step is to build the capability catalog as a company-wide asset. The catalog is not a side project for a single line of business. The catalog is a shared resource, in the same way the enterprise's API catalog and data dictionary are shared resources. Every new AI use case should begin by checking which capabilities already exist and which need to be added. An enterprise investing seriously in AI will accumulate hundreds of capabilities over time, and the value of the catalog compounds as the inventory grows.

The third step is to bring capability governance under the model risk and third-party risk frameworks the enterprise already operates, rather than treating AI governance as a separate program. The company already knows how to inventory models, approve model changes, monitor model performance, and manage vendor risk. Capabilities are a new kind of model component, and the existing frameworks extend to cover them with limited modification. Standing up a parallel AI governance function, separate from the frameworks the enterprise already runs, creates organizational friction without adding control.

The fourth step is to invest in the Control Plane as a foundational platform, rather than as an afterthought. The Control Plane is the part of the architecture that is hardest to retrofit. An enterprise that builds twenty capabilities without a registry, without policy enforcement, and without comprehensive logging will eventually have to rebuild those capabilities on top of a Control Plane that should have existed from the start. Building the Control Plane first, and then populating it with capabilities, is both the more disciplined sequence and the more economical one over the full program lifecycle.

#What is the strategic conclusion?

The Connection layer is becoming a commodity, because MCP is converging into an industry standard that every AI vendor will support. The Capability layer and the Control Plane are the durable advantage, because those two layers encode the enterprise's specific policies, the enterprise's specific risk appetite, and the enterprise's specific operational expertise. The companies that learn to govern what an agent can do, rather than scripting what an agent must say, will be the companies that deploy AI safely at scale.

The version of the refund story that goes right is not the version where the AI is smarter. The version that goes right is the version where the enterprise has built the architecture that determines what the AI is allowed to do in the first place. That architecture is the work this post is asking enterprise leaders to commit to.