A Reference Architecture for Separating Autonomous Intelligence from Execution Authority
Abstract
As AI systems move from generating responses to initiating actions, architecture must address a new boundary: the point where dynamically generated intent acquires authority to change the world outside the model. Existing patterns for distributed systems, event-driven coordination, identity, authorization, and Zero Trust remain essential, but agentic execution brings those concerns together in a new way.
The Agentic–Event–Governed (AEG) Architecture Model is a reference architecture for that boundary. It separates autonomous intent generation from execution authority, uses event-mediated coordination to make decisions and outcomes observable, and introduces an independent runtime governance layer that evaluates whether proposed actions may proceed.
The central principle is simple: intelligence may propose an action, but intelligence does not grant itself authority to execute it. AEG makes that separation explicit so autonomous systems can remain governable, attributable, auditable, and interruptible in production.
Authorship and originality. The Agentic–Event–Governed (AEG) Architecture Model is an original reference architecture proposed by Jacob George. It synthesizes agentic system design, event-mediated coordination, runtime policy enforcement, and Zero Trust principles around a specific architectural boundary: the transition from machine-generated intent to authorized execution.
Formal definition: The Agentic–Event–Governed (AEG) Architecture Model is a system design framework in which autonomous components generate structured intent, coordination mechanisms make that intent and its outcomes observable, and an independent runtime governance layer determines whether execution is allowed, blocked, constrained, or escalated before consequential state change occurs.
AEG Quick Reference
If you remember only one thing from this article, remember this:
AEG is an architecture for preventing autonomous intelligence from becoming autonomous authority.
- Agentic = intelligence generates structured intent
- Event = coordination, causality, and evidence make intent observable
- Governed = independent runtime controls determine whether intent may become action
Introduction: The Boundary That Changes With Agentic Software
AI is becoming capable of doing more than producing information. Agents can select tools, call APIs, operate software, modify infrastructure, initiate workflows, and coordinate with other agents. That changes the architecture problem.
Existing architectural patterns remain useful, but agentic execution introduces a new problem at their intersection: dynamically generated intent can acquire operational authority faster than traditional control mechanisms were designed to evaluate it.
A conventional service usually executes logic that engineers explicitly encoded. An agent can determine the next action at runtime from goals, context, model reasoning, retrieved information, and tool feedback. The action may be valid, mistaken, manipulated, unexpectedly expensive, or simply outside the authority that should have been granted to the agent.
AEG starts from the position that reasoning and authority are different architectural concerns. The component capable of proposing an action should not automatically be the component that decides whether the action is permitted to occur.
Agentic AI Changes the Trust Assumptions
Agentic AI systems differ from ordinary application components because they can form intermediate objectives, select actions dynamically, and operate with limited human initiation. That does not make every LLM-enabled service an agent.
What qualifies as an agent in AEG
In AEG, an agent is a workload that can generate intent and select actions based on goals and context. It typically has most of the following properties:
- Goal-driven intent: forms intermediate objectives rather than only returning responses
- Context sensitivity: incorporates signals, history, state, and constraints
- Action capability: can request external effects rather than only produce text
- Attributable identity: operates as an identifiable workload principal
- Governable boundaries: consequential actions cross an enforcement boundary before execution
The final property is especially important. In AEG, autonomy does not imply unrestricted authority.
Structured Intent Is the Architectural Boundary
The architectural center of AEG is the intent object. Model output, reasoning, or a tool-selection decision is not treated as an executable command. It is translated into a structured representation of what the agent proposes to do.
A useful intent object can carry the proposed action, target resource, actor identity, relevant context, requested scope, expected effect, risk attributes, and correlation information needed to trace the decision.
This creates a deliberate boundary:
Agent / Model → Structured Intent → Coordination → Governance Decision → Approved Execution → Outcome Evidence
Once intent is explicit, it can be inspected, evaluated, delayed, transformed, denied, approved, or escalated without giving the reasoning component direct control of the execution surface.
Why Event-Mediated Coordination Matters
AEG uses event-mediated coordination because autonomous systems benefit from explicit causality and durable evidence. Intent, governance decisions, execution results, and downstream outcomes can be represented as events so the system can reconstruct not only what happened, but the sequence of decisions that allowed it to happen.
This does not mean every interaction must be asynchronous or that APIs disappear. Synchronous APIs, queues, workflow engines, durable execution frameworks, streams, and other mechanisms can coexist in an AEG implementation. The architectural requirement is that consequential autonomous intent crosses an observable coordination and governance boundary rather than moving directly from model output to privileged execution.
Events are particularly useful at that boundary because they support decoupling, replay, auditability, correlation, intervention, and independent policy evaluation. They become evidence of system behavior rather than merely an integration mechanism.
Governance Is Broader Than Authorization
Identity and authorization are necessary, but they are not sufficient for autonomous systems. A request may be technically authorized and still be inappropriate because of its amount, timing, destination, cumulative cost, data sensitivity, operational risk, or the context in which the agent generated it.
The AEG runtime governance layer therefore evaluates more than permission. Depending on the system, governance can include:
- Identity: which user, agent, service, or delegated principal is responsible?
- Authorization: is that principal permitted to request this capability?
- Policy: do organizational and regulatory rules permit the proposed action?
- Risk: what is the potential blast radius or reversibility of the action?
- Budgets and quotas: is the action within financial, rate, resource, or usage limits?
- Human approval: does the impact require an explicit human checkpoint?
- Context: do current conditions change what should normally be allowed?
Zero Trust remains a foundational security principle within this layer: trust is not inherited simply because an agent is inside a network, owns a credential, or successfully executed a previous action. But Governed in AEG deliberately extends beyond Zero Trust into the broader operational question of whether this specific intent should be allowed to become action now.
The Unified Model: Three Responsibilities Working Together
AEG organizes the system around three architectural responsibilities rather than requiring a particular vendor stack or deployment topology.
Layer 1: Agentic Intelligence Layer
This layer contains agents, models, planners, reasoning components, and adaptive logic. Its responsibility is to interpret goals and context and generate structured intent. It may recommend or propose actions, but it does not grant itself execution authority.
Layer 2: Event-Mediated Coordination Layer
This layer carries and correlates intent, decisions, state changes, and outcomes. Implementations may use event buses, queues, streams, workflow engines, APIs, or combinations of them. The important property is an observable coordination boundary with traceable causality.
It provides:
- decoupling between reasoning and execution
- correlation between intent, decisions, and outcomes
- durable evidence for audit and incident reconstruction
- points where policy and intervention can operate independently
Layer 3: Runtime Governance Layer
This layer evaluates structured intent before consequential execution. It combines identity, authorization, policy, contextual risk, operational constraints, budgets, and approval requirements to produce an enforceable decision.
A decision may allow the action, block it, constrain it, transform the permitted scope, delay it, or require human approval. Only an approved execution contract should reach the privileged executor.
Policy-as-Code Makes Governance Enforceable
Governance is useful only if it can affect execution. Policy-as-code provides one practical mechanism for expressing controls independently of model reasoning and application business logic.
Policy engines such as Open Policy Agent (OPA), purpose-built authorization services, rules engines, risk services, and approval workflows can all participate in the governance decision. AEG does not require one particular policy technology.
The important architectural property is independence: the agent proposes intent, while a separate enforcement path decides whether that intent can reach the executor.
A Concrete Walkthrough
- Signal or goal arrives: a user request, document upload, anomaly, schedule, or another system event provides context.
- Agent forms structured intent: the agent proposes an action with attributable identity, target, scope, context, and correlation metadata.
- Coordination records the proposal: the intent enters the system through an observable boundary and can be correlated with later decisions and outcomes.
- Governance evaluates intent: policy, authorization, risk, budgets, data sensitivity, and approval requirements are evaluated independently of the agent.
- An enforceable decision is produced: allow, block, constrain, delay, or require human approval.
- Approved execution occurs: only the authorized scope reaches the executor.
- Outcome evidence is captured: execution results and downstream effects feed observability, audit, and future reasoning without silently expanding the agent's authority.
What AEG Is Not
AEG is not intended to replace microservices, event-driven architecture, workflow engines, IAM, Zero Trust, API gateways, agent frameworks, or existing cloud-native patterns. Those remain implementation building blocks.
AEG defines a control architecture: how autonomous intent is represented, observed, evaluated, and allowed to cross into authorized execution. An implementation can use synchronous and asynchronous technologies together as long as that control boundary remains explicit and enforceable.
AEG vs. Common Misreads
- Not “EDA with AI”: events are not the differentiator by themselves; the important boundary is between generated intent and execution authority.
- Not “agents with a message bus”: governance is an independent runtime enforcement responsibility, not simply another consumer.
- Not “Zero Trust at the API gateway”: identity and authorization are part of governance, but decisions can also incorporate risk, budgets, context, and human approval.
- Not a requirement that everything be event-driven: AEG can coexist with APIs and workflow engines while preserving observable intent and governed execution.
Implementation Lens for Architects
- Intent: Is the proposed action represented separately from model output and executable commands?
- Identity: Can every consequential intent be attributed to the responsible user, agent, service, and delegated authority?
- Coordination: Can you correlate the original intent with governance decisions, execution, and outcomes?
- Governance: Can policy, risk, budgets, and approval requirements stop or constrain execution before state changes?
- Least authority: Does the executor receive only the authority required for the approved action?
- Auditability: Can you reconstruct why an action occurred without relying on the model to explain itself after the fact?
- Intervention: Can authority be revoked or high-impact intent escalated quickly when conditions change?
How to Cite the AEG Architecture Model
Jacob George. The Agentic–Event–Governed (AEG) Architecture Model. jacobpallattu.com, 2025. Canonical reference: /architecture/aeg.
When referencing the model in design documents, reviews, or publications, use the full name: Agentic–Event–Governed (AEG) Architecture Model.
Conclusion
The difficult problem in agentic systems is not intelligence alone. It is authority. As software becomes capable of deciding what to do next, architecture must make explicit who or what is allowed to turn that decision into a real-world effect.
AEG separates those responsibilities. Agents generate structured intent. Coordination makes intent, decisions, and outcomes observable. Independent runtime governance determines what may proceed. Execution receives only the authority that has actually been approved.
That separation allows autonomous systems to become more capable without requiring organizations to grant the reasoning layer unrestricted operational trust.
Explore this topic
Part of the Governed Agentic Systems topic collection.