Agentic Architecture Skills logo

Agentic Architecture Skills

Back

A Governed Path to the Agentic Enterprise: Seven Planes, Fourteen Layers, Two Rules

August 27, 2026 · 12 min read · Agentic Architecture Skills

A practical architecture playbook for transforming one bounded workflow across seven agent-system planes and fourteen enterprise layers—with control and evidence outside execution.

Introduction: agentic AI governance starts outside the prompt

Your team ships an agent with careful instructions: do not overspend, do not touch regulated records, escalate risky cases. Then the agent gets API access, session memory, and a workflow target. At that moment, agentic AI governance stops being a prompt-writing exercise and becomes an architecture problem.

The data now matches that reality. According to McKinsey’s State of AI Trust in 2026, organizations are mature enough to measure agentic governance separately from general genAI controls.

Key takeaways:

  • Prompt text is guidance, not enforcement
  • Seven planes map controls to architecture
  • Control and Evidence must stay outside execution
  • Start with one bounded workflow, then expand

This playbook gives enterprise architects a target-state architecture for the agentic enterprise. Its core claim is simple: autonomous AI agent governance works only when control and evidence remain structurally independent of the agent’s execution loop.

That means the first step is not choosing a model. It is understanding why agent rollout changes enterprise architecture itself.

Agentic transformation is an enterprise architecture change

And once you see agents acting across systems, the scope changes fast. An agent rollout redesigns work, authority, knowledge, controls, evidence, learning, and accountability.

According to Contentstack’s 2026 Agentic Enterprise Report, nearly 9 in 10 leaders (89%) call agentic AI a strategic priority, while about 44% feel overwhelmed by the number of tools and frameworks, and about 53% say hype is getting harder to separate from real opportunity.

At the same time:

  • McKinsey added agentic AI governance and controls as a new maturity dimension across about 500 organizations
  • McKinsey’s 2026 global AI survey found 4 in 10 large enterprises (40%) are scaling agents
  • Smaller firms in that same survey stayed flat at about 22%

If agents change who can decide and act, governance must be designed as enterprise AI architecture, not appended as policy. Based on what we saw when naming the components, boundaries, and decision sequence closely enough for architecture review, prompt instructions are preferences, not enforceable controls.

So the safest move is to narrow the problem before you scale it.

Start with one bounded workflow

That narrowing move is the architectural hinge. Start with one workflow, not one model.

A business process is the repeatable sequence of work that produces an outcome, such as refund approval, supplier onboarding, or service-ticket triage. In agent design, the workflow matters because it exposes authority, data, systems touched, side effects, and failure conditions.

According to Deloitte’s U.S. readiness survey, only 1 in 20 business processes (5%) are highly prepared for AI agents, and only about 15% had scaled orchestrated cross-functional multi-agent adoption.

For a bounded workflow, name:

  • Outcome the workflow must produce
  • Trigger that starts agent participation
  • Authority to recommend, execute, approve, or escalate
  • Systems affected by reads, writes, and commits
  • Stopping conditions that force halt or handoff

This is also where an AI agent readiness assessment becomes practical. It tests whether one workflow has clear ownership, bounded authority, governed knowledge, independent controls, and rollback paths before autonomy is allowed.

Once the workflow is bounded, you need a model that spans the estate without confusing ownership with runtime design.

Fourteen layers are what you own; seven planes are what you build

That is the next distinction to make. The enterprise estate already exists as layers of process, applications, data, identity, networks, risk, records, and operations. The agent system should cross that estate through seven planes.

Think of the estate as ownership and the planes as build design. The cross-layer spine lets an enterprise architect map each owned layer into where it contributes during agent runtime.

Use the seven planes as the organizing visual:

  • Execution for reasoning, orchestration, state, and halting
  • Action for tools, APIs, connectors, and transactions
  • Knowledge for retrieval, context, freshness, and entitlements
  • Control for policies, identity, approvals, and gateways
  • Improvement for evaluation, replay, release, and learning
  • Evidence for logs, traces, outcomes, and audit channels
  • Human for accountable owners and override paths

This is what makes enterprise AI agent governance concrete. It maps policy and risk responsibilities to architectural locations instead of leaving them inside a model prompt.

Now the review can move from concept to named components.

Build the seven planes across the enterprise estate

The architecture becomes actionable when every plane has named components, owners, enforcement points, and evidence across the enterprise estate. The mapping below identifies each layer’s primary contribution, not exclusive ownership. Some layers deliberately contribute to more than one plane.

1. Execution plane

Primary layers: R01 Infrastructure and Compute; R07 Agent Platform.

This is where agent work runs. Establish isolated runtimes, durable sessions, explicit termination conditions, workload identity, model routing, per-run budgets, and a registry with evaluation-gated promotion. Enterprise architects should verify that execution can be stopped externally and that runtime state survives or fails safely.

2. Action plane

Primary layers: R03 Integration Fabric; R04 Systems of Record; R05 Line of Business and OT.

This is how agents reach enterprise systems. Put tools and governed APIs behind an enforcement gateway. Preserve entitlements inside systems of record, make the agent act as the requesting user, separate reads from writes and commits, and keep agents on the information path rather than the physical control path in operational environments.

3. Knowledge plane

Primary layers: R02 Data Platform; R14 Agent Data Engineering.

This is what agents are allowed to know and remember. Build permission-aware retrieval, governed source data, purpose-specific curation, semantic contracts where deterministic meaning is required, provenance from ingestion, controlled memory writes, retention limits, and cascading deletion. Do not treat a raw corpus pushed into a model as an enterprise knowledge architecture.

4. Control plane

Primary layers: R07 Agent Platform; R10 Security and Identity; R11 Governance, Risk and Sovereignty.

This plane decides what is allowed. Give every agent a registered identity, named owner, scoped authority, expiring credentials, policy decision points, approval thresholds, budgets, sovereignty routing, and a kill path. The agent may request an action, but it cannot grant itself permission.

5. Improvement plane

Primary layers: R06 Intelligence and Learning; R14 Agent Data Engineering.

This is how behaviour changes safely. Maintain representative evaluation sets, replay real traces, test exceptions, define promotion and demotion thresholds, and connect production failures back into curated evaluation data. Improvement should change a versioned agent through a controlled release process—not let a live agent rewrite its own rules.

6. Evidence plane

Primary layers: R11 Governance decision and consultation records; R12 Observability and FinOps.

This plane proves what happened. Collect tool requests, policy decisions, prompts, retrieved sources, actions, costs, outcomes, and human interventions through a channel the agent cannot alter. Correlate records across the full workflow so auditors and operators can reconstruct who acted, on whose behalf, under which rule, and with what result.

7. Human plane

Primary layers: R08 Productivity and Collaboration; R09 Experience and Channels; R13 Operating Model.

This is where intent, accountability, exceptions, and supervision live. Define who owns the workflow, who approves high-impact actions, who receives escalations, who can suspend autonomy, and how customers and employees understand when an agent is acting. Human oversight is an operating model with decision rights—not merely an approval button.

Every production workflow uses all seven planes across the relevant layers. The implementation may be lightweight for a low-risk assistant and extensive for a high-autonomy agent, but no plane should disappear simply because the first use case is small.

Keep control and evidence outside the agent

That rule is binding. An instruction inside an agent prompt is a preference, not an enforceable control.

An Autonomous AI Agent is a software system capable of pursuing complex, multi-step goals with minimal human intervention. By utilizing large language models as a reasoning engine, these agents perceive their environment, formulate strategic plans, execute sequences of tool-based actions, and iteratively refine their performance based on environmental feedback and task outcomes.

Because of that autonomy:

  • Control must live outside execution through deterministic gateways, approvals, and identity checks
  • Evidence must be collected independently through logs, traces, and audit channels the agent cannot alter
  • Execution cannot self-police when incentives favor goal completion over policy fidelity

According to Deloitte’s global survey on agents scaling faster than guardrails, only about 1 in 5 organizations (21%) say they have a mature governance model for agentic AI.

That is why AI governance needs a distinct architectural form here. In enterprise settings, AI governance means the rules, decision rights, controls, evidence, and accountability that shape how AI systems are allowed to act.

The next question is where to make those controls deterministic.

Use deterministic boundaries where consequences are irreversible

The answer is simple: when consequences cannot be safely undone, the model may advise but a deterministic system must decide.

Use hard boundaries for:

  • Access: entitlements, privilege changes, and role grants
  • Money: payments, credits, pricing changes, procurement commitments
  • Safety actuation: plant controls, field operations, physical interventions
  • Formal records: contracts, regulated filings, customer master data, archives

In these zones, the agent can prepare context, draft recommendations, and propose actions. The commit step should still pass through rule-bound systems, approval thresholds, and system-of-record validation.

This is the practical core of autonomous AI agent governance. It does not block autonomy everywhere; it constrains autonomy exactly where enterprise policy must remain enforceable.

Once those boundaries are clear, the transformation sequence becomes much easier to run.

A governed transformation sequence

And the sequence matters because adoption is moving faster than most control programs. According to Deloitte’s global State of AI in the Enterprise survey, nearly three-quarters of leaders (74%) expect their companies to use AI agents at least moderately by 2027, including about 23% expecting extensive use and about 5% expecting full integration.

Use this order:

  • Step 1: choose one bounded workflow
  • Step 2: define authority, boundaries, and stopping conditions
  • Step 3: connect governed knowledge and governed actions
  • Step 4: capture independent evidence across the full path
  • Step 5: evaluate reliability before increasing autonomy
  • Step 6: expand only after the previous boundary holds

This is how enterprise AI architecture supports controlled growth. It turns experimentation into staged production readiness.

The last thing most teams need is a short test they can run in one meeting.

Readiness checklist for enterprise architects

That test is your Monday-morning gate. An enterprise architect is the role responsible for shaping how business processes, systems, controls, and operating models fit together across the enterprise.

A workflow is not ready for autonomy until the architect can answer these questions in one sitting:

  • Workflow defined? Outcome, trigger, systems affected, stopping conditions named
  • Authority defined? Recommend, execute, approve, escalate separated
  • Action boundaries set? Read, write, commit, irreversible steps gated
  • Knowledge governed? Sources, freshness, entitlements, context patterns specified
  • Control independent? External policy points and deterministic gateways live
  • Evidence independent? Logs, traces, and decisions captured outside agent runtime
  • Evaluation ready? Replay, tests, exception review, rollback path defined
  • Human accountable? One owner and escalation path assigned

This checklist is also an AI agent reliability test. Reliability here means the agent consistently produces acceptable outcomes within defined authority and failure bounds, not merely that it sounds coherent.

With that test in hand, the scale path becomes clearer.

Start narrow, architect enterprise-wide

That is the discipline to keep as programs grow. The goal is not to make one clever agent work; it is to prove a repeatable pattern across all seven planes.

According to McKinsey’s 2026 global AI survey, 4 in 10 large enterprises (40%) are already scaling AI agents, up from about 27% a year earlier. That does not prove transformation is solved, but it does show enterprise-scale patterns are becoming operating practice.

So start narrow while designing enterprise-wide:

The opening mistake was trying to govern action with prompt wording. The payoff is proving a structural pattern instead.

The architecture test that matters

If an agent can act, the real test is not whether the prompt sounds cautious. It is whether Control can stop the action and Evidence can prove what happened without asking the agent for permission.

Key takeaways:

  • Governance is architectural, not prompt-level for autonomous systems
  • Control and Evidence must remain independent of execution
  • One bounded workflow is the right starting point for enterprise rollout

This is the central lesson for agentic AI governance. Most teams still treat governance as policy text wrapped around model behavior, but the stronger pattern is a seven-plane architecture in which execution, action, knowledge, control, improvement, evidence, and human oversight are explicitly separated.

That separation is what lets an enterprise architect map controls to planes, review a workflow against named boundaries, and decide where autonomy is allowed to grow. It is also what makes autonomous AI agent governance enforceable rather than aspirational.

So use this as an immediate architecture review. Pick one bounded workflow this week, map it across the seven planes, verify that Control can block irreversible actions, and verify that Evidence can reconstruct the full path independently. Read it, or install it. The teams that scale safely will not be the ones with the most persuasive prompts; they will be the ones with the clearest boundaries, the strongest cross-layer spine, and verdicts, sources, and gaps visible at every step.

References