Intent Is the Control Plane: Enterprise Agentic AI Architecture for 2026

Intent Is the Control Plane: Enterprise Agentic AI Architecture for 2026

Different protocols. Different layers. One governing idea: the enterprise should begin with intent.

Agentic AI architecture is becoming much clearer.

We now have protocols for agents talking to tools. Protocols for agents talking to other agents. Protocols for agents interacting with users. Emerging approaches allow agents to generate user interfaces dynamically. Underneath all of it, enterprises still have APIs, events, databases, cloud platforms, identity systems, observability, and decades of existing technology.

That is progress.

But it creates another question:

What coordinates all of it?

The answer should not be another protocol.

It should be intent.

In an Intent-Driven Enterprise, the primary architectural flow becomes:

Intent → Orchestration → Agents → Tools & Services → Enterprise Systems → Validated Outcome

This changes the architecture from a collection of intelligent components into a governed execution system.

The Missing Layer: Intent as the Control Plane

Most agentic architecture diagrams begin with an agent or an orchestrator.

That is already one step too late.

Before an agent reasons, calls a tool, delegates to another agent, queries a database, publishes an event, or modifies a production system, something should define why the work is being performed and what success means.

That is the job of the Intent Control Plane.

An intent should minimally establish four things:

Intent — What outcome are we trying to achieve?

Inputs — What information is available to perform the work?

Outputs — What artifacts, actions, or results should be produced?

Success Criteria — How do we determine that the requested outcome was actually achieved?

Enterprise implementations can extend this with:

• constraints

• policies

• guardrails

• security requirements

• validation rules

• ownership

• cost boundaries

• architectural patterns

• implementation guidance

• compliance requirements

• observability expectations

The important point is that the agent does not invent the mission.

The agent receives the mission.

The Enterprise Intent-Driven Agentic Architecture

The architecture can be viewed as several cooperating layers.

                    USER & APPLICATION LAYER

                Web • Mobile • Teams • Slack

                           │

                           ▼

                  INTENT CONTROL PLANE

          Intent → Constraints → Success Criteria

                           │

                           ▼

                   WEGA / ORCHESTRATOR

             Plan • Route • Validate • Coordinate

                  │         │         │

                  ▼         ▼         ▼

               Agent A   Agent B   Agent C

                  │         │         │

                Skills     A2A      Skills

                  │         │         │

                  └─────────┼─────────┘

                            ▼

                       MCP / TOOLS

                            │

               ┌────────────┼────────────┐

               ▼            ▼            ▼

           REST/gRPC       Kafka      Databases

               │            │            │

               └────── ENTERPRISE ───────┘

                    ↕ DURABLE STATE ↕

           Saga • Checkpoints • Registry • Audit

                 CROSS-CUTTING CONTROL

       Identity • Security • Hooks • Policy • Telemetry

           Observability • Cost • Governance

The value is not any individual box.

The value is the separation of responsibilities.

1. Intent Control Plane — Define the Outcome

Intent sits above execution.

The intent layer describes what the organization wants accomplished without prematurely prescribing every implementation decision.

For example:

## Intent

Provision a new enterprise customer across Salesforce,

billing, ServiceNow, and the customer portal.

## Inputs

Validated TMF customer and product-order information.

## Outputs

Provisioned customer records in all required systems

with a correlated completion result.

## Success Criteria

- Salesforce customer created

- Billing account created

- ServiceNow relationship established

- Portal access provisioned

- All identifiers correlated

- No duplicate provisioning

- Complete audit trail available

Notice what is missing.

There are no detailed instructions telling an AI model exactly which classes to modify, which HTTP requests to execute, or how every system should be implemented.

Those decisions can be discovered from the repository, architecture, skills, policies, tools, and available services.

The intent defines the destination and boundaries.

2. Wega — The Orchestration Layer

Below intent sits the orchestration layer.

In this architecture, we can call that Wega.

Wega is not necessarily an LLM.

It is the execution and coordination capability that turns intent into controlled work.

Its responsibilities can include:

• task decomposition

• planning

• routing

• agent selection

• context management

• workflow coordination

• policy enforcement

• validation

• retries

• compensation

• telemetry

• evaluation

• completion determination

This distinction matters.

An agent may be excellent at reasoning.

That does not mean the agent should automatically own the enterprise transaction.

For a production workflow spanning six systems, the enterprise needs something that knows:

What has completed?

What is still running?

What failed?

What can be retried?

What must be compensated?

What evidence proves success?

That is orchestration.

3. Agents Reason — They Should Not Be the Database

One of the easiest mistakes in agentic architecture is confusing context with state.

An agent may maintain temporary context while performing a task.

That is useful.

But durable enterprise workflow state belongs outside the model.

For example, imagine this workflow:

Customer Order

     ↓

Salesforce

     ↓

Billing

     ↓

ServiceNow

     ↓

Provisioning

     ↓

Notification

If step four fails, the organization cannot depend on an LLM conversation remembering what happened.

The workflow needs durable information such as:

workflow_id: 89321

salesforce: COMPLETE

billing: COMPLETE

servicenow: COMPLETE

provisioning: FAILED

notification: NOT_STARTED

retry_count: 2

That belongs in an external workflow or state store.

This gives us another important architectural principle:

Agents reason. Orchestrators coordinate. State stores remember.

That separation makes agentic systems much more predictable.

4. A2A — Agent-to-Agent Collaboration

Not every task should be handled by one giant agent.

An enterprise may have specialized agents for:

• security

• finance

• legal

• HR

• operations

• architecture

• testing

• compliance

Agent-to-Agent communication allows these capabilities to collaborate.

For example:

Wega

  │

  ├──► Architecture Agent

  │

  ├──► Security Agent

  │

  ├──► Implementation Agent

  │

  └──► Testing Agent

The orchestration layer can delegate bounded tasks while retaining responsibility for the overall workflow.

This is a much healthier model than creating an enormous autonomous agent with unlimited responsibilities.

Specialization belongs to agents. Coordination belongs to orchestration.

5. MCP — Agent-to-Tools and Data

The Model Context Protocol has become an important boundary in agentic architecture because it gives agents a standardized way to access external capabilities.

An enterprise agent may need access to:

Jira

Confluence

GitHub

ServiceNow

Databases

Cloud services

Internal APIs

Search systems

Observability platforms

MCP provides a consistent mechanism for exposing those capabilities.

But MCP should not become an architectural religion.

If an existing application already exposes a clean REST API and a deterministic service simply needs to call it, there may be no reason to place MCP between those systems.

A useful distinction is:

MCP is primarily an agent access boundary—not a replacement for every enterprise API.

That keeps the architecture pragmatic.

6. Skills — Reusable Organizational Expertise

Protocols provide connectivity.

Skills provide knowledge of how work should be performed.

An organization may have reusable skills such as:

/create-api

/create-tmf-adapter

/security-review

/create-react-component

/deploy-aws-service

/create-service-now-integration

Those skills can encode:

• architecture conventions

• coding standards

• reusable workflows

• implementation patterns

• security requirements

• testing practices

• deployment expectations

This is how organizational knowledge becomes reusable by agents without stuffing every rule into every prompt.

7. Hooks — Deterministic Control

Some decisions should never depend entirely on probabilistic reasoning.

Examples include:

• secrets detection

• schema validation

• required tests

• security scanning

• protected-file rules

• deployment authorization

• intent validation

• compliance checks

These belong in deterministic controls such as hooks, policies, CI pipelines, and platform enforcement.

This gives us a powerful division:

Agent reasoning       → probabilistic

Skill guidance        → reusable expertise

Intent                → desired outcome

Hook/policy           → deterministic enforcement

AI can reason creatively while the enterprise retains hard boundaries.

8. Native APIs and Events Still Matter

Agentic architecture does not eliminate conventional enterprise integration.

REST is still useful.

gRPC is still useful.

GraphQL is still useful.

Kafka is still useful.

Databases are still useful.

Event-driven architecture is still useful.

The agentic layer sits above and alongside these technologies.

For example:

Intent

   ↓

Wega

   ↓

Agent

   ↓

MCP

   ↓

Enterprise Tool

may be appropriate for an agent-driven operation.

But:

Order Service

   ↓

Kafka

   ↓

Billing Adapter

   ↓

Billing API

may remain entirely deterministic.

Both can coexist.

That is what makes the architecture composable rather than revolutionary for revolution’s sake.

9. The Intent Registry

As organizations accumulate intents, another capability becomes valuable: an Intent Registry.

The registry can provide a searchable catalog of:

• intents

• versions

• owners

• schemas

• templates

• patterns

• relationships

• success criteria

• execution history

• reusable architectural guidance

The registry does not have to become a massive centralized approval system.

A lightweight implementation might simply record intents whenever practical and make them searchable.

More mature implementations can introduce:

Intent

   ↓

Validation

   ↓

Registration

   ↓

Execution

   ↓

Evidence

   ↓

Outcome

The registry becomes institutional memory.

10. Cross-Cutting Enterprise Services

Around all of these layers sit capabilities that should not be recreated by individual agents.

These include:

Identity and Access

Agents require identities and constrained permissions just like applications and users.

Security

Agent actions must respect enterprise security boundaries.

Secrets Management

Credentials should come from controlled secret stores rather than prompts or source code.

Observability

Agent decisions, tool calls, workflow transitions, failures, retries, and outcomes should be observable.

Audit and Compliance

Organizations need evidence explaining what happened and why.

FinOps

Agentic workloads introduce variable model and tool costs that should be measured.

Governance

Organizations need policies defining what agents may perform autonomously and what requires approval.

These are platform capabilities.

They should not be reinvented inside every agent.

Protocols Become Plumbing

Once this architecture is viewed through an Intent-Driven lens, something interesting happens.

The protocols become less confusing.

They each have a job.

Protocol / Capability

Primary Responsibility

AG-UI

Agent ↔ User/UI

A2UI

Agent → Dynamic UI

A2A

Agent ↔ Agent

MCP

Agent ↔ Tools/Data

Native APIs

Application ↔ Services

Events/Kafka

Asynchronous system communication

Skills

Reusable expertise/workflows

Hooks

Deterministic enforcement

Intent

Desired outcome and success

Wega

Coordination and execution

External State

Durable workflow memory

Instead of asking:

Which protocol wins?

We ask:

Which protocol belongs at this boundary?

That is a much better architectural question.

A Real Enterprise Example

Consider a customer-order intent.

The user submits an order through a web application.

The application produces an intent.

Wega validates the intent and creates a durable workflow instance.

A product agent determines the appropriate fulfillment plan.

A security agent evaluates required access.

A billing capability is accessed through an API.

ServiceNow may be accessed through MCP.

Kafka carries asynchronous provisioning events.

The state store records each completed stage.

Hooks enforce security and deployment rules.

Observability captures the entire transaction.

The orchestrator finally evaluates the original success criteria.

Only then is the intent considered complete.

The flow becomes:

User

↓

Intent

↓

Wega

↓

Plan

↓

Agents

↓

Skills / MCP / APIs / Events

↓

Enterprise Systems

↓

State + Evidence

↓

Validation

↓

Success Criteria Satisfied

↓

Intent Complete

That final step is extremely important.

Completion is not “the agent stopped talking.”

Completion means the system can demonstrate that the original intent was satisfied.

From Prompt-Driven AI to Intent-Driven Enterprise Systems

The first generation of generative AI applications was largely prompt-driven.

Prompt → Model → Response

Agentic systems expanded that:

Prompt → Agent → Tools → Response

Multi-agent systems expand it again:

Prompt → Agent → Agents → Tools → Systems

But enterprise architecture needs one more evolution:

                    INTENT

                      │

                      ▼

                 ORCHESTRATION

                      │

              ┌───────┼───────┐

              ▼       ▼       ▼

            Agents  Skills   Policies

              │       │       │

              └───────┼───────┘

                      ▼

               Tools / Protocols

                      │

                      ▼

              Enterprise Systems

                      │

                      ▼

                 Evidence

                      │

                      ▼

              Success Criteria

That closes the loop.

The Architectural Principle

The entire architecture can ultimately be summarized in nine statements:

Intent defines what.

Wega coordinates how.

Agents reason.

Skills provide expertise.

A2A enables collaboration.

MCP provides agent access to tools and data.

APIs and events integrate enterprise systems.

External state provides durability.

Hooks and policies provide deterministic control.

Together they create something much larger than an AI assistant.

They create an enterprise execution architecture.

The Future Is Not One Giant Agent

The future enterprise probably will not be controlled by one giant autonomous AI.

It will consist of thousands of capabilities:

agents, APIs, services, event streams, databases, skills, tools, models, workflows, policies, and human approvals.

The architectural challenge is not making all of those things intelligent.

The challenge is making them work together toward a declared outcome while remaining secure, observable, governable, and recoverable.

Protocols such as MCP, A2A, AG-UI, and emerging interoperability standards provide increasingly powerful connective tissue.

But protocols alone do not provide purpose.

That is why the architecture begins one level higher.

It begins with intent.

Because when intent becomes the primary artifact, agents stop being the center of the architecture.

The outcome becomes the center.

And that may be the most important architectural shift of the agentic era.

Mark Kendall

Intent-Driven Engineering

Intent → Orchestration → Execution → Evidence → Outcome