Agentic Enterprise Architecture Practice
Design and operate your enterprise “software” as an AI-driven agentic fabric that sits above systems and data, governed by codified business rules, unified data management, and identity-aware security, rather than bespoke application UIs.
This practice describes how enterprises can implement agentic enterprise architecture as the practical counterpart to H005. It explains how to treat AI agents as first-class architectural objects, backed by a shared substrate of business rules and data rules, and how to align those agents with identity-aware AI security and enterprise governance. It outlines roles, responsibilities, and patterns for stabilizing human-facing experiences while shifting differentiation into agents, shared rules, and data management, and it emphasizes the enterprise’s role as a counterweight to vendor-centric architectures as agents become the dominant interface to systems and data.
Purpose and scope
This practice describes how enterprises can shift from application-centric architecture to agentic enterprise architecture, where AI agents become the primary interface to systems and data. It focuses on treating agents as first-class architectural objects, defining their behavioral envelopes in terms of identity, business rules, data rules, and tools, and reducing reliance on bespoke functional UIs without sacrificing safety, governance, or user trust. The scope includes human-facing agents that mediate daily work, background enterprise agents that orchestrate workflows and transactions, and strategic and portfolio-level agents that help leaders design, monitor, and adapt the enterprise’s plays, portfolios, and operating model.
Business rule and data rule foundation
Agentic enterprise architecture presumes a codified layer of business rules and data rules that is not trapped inside individual applications. Business rules capture process flows, approvals, decision logic, constraints, and exception handling that determine how work should proceed across systems. Data rules define shared schemas, classifications, quality constraints, lineage, and valid state transitions for core entities, covering both analytic and transactional use. In many enterprises today, these rules exist as fragile combinations of configuration, code, and implicit behavior inside SaaS applications and custom systems, which makes cross-application orchestration brittle and hard to change. Agentic enterprise architecture elevates a system-agnostic rules substrate—expressed in reusable, versioned, testable artifacts that can be invoked via APIs by both agents and applications—as a foundational investment.
Roles, responsibilities, and ownership
Agent platform owner: Owns the shared runtime, orchestration, protocols, and tooling for AI agents, including integration patterns to systems and the business rule and data rule substrate. Domain product owners: Own the business rules, processes, and data semantics that agents embody in specific domains, and sponsor their codification into shared services. Identity and security architects: Own identity-aware policies, agent identity models, and alignment with the five pillars of identity-aware AI security. Enterprise architecture: Curates the overall agentic fabric, ensuring that agents, business rules, data rules, and systems compose into a coherent enterprise-wide architecture rather than siloed agent islands. Enterprise AI Governance: Sets policy for which agents are acceptable, where they may operate, and how their performance and risk are overseen, coordinating with data, security, and transformation governance boards. Strategy, portfolio, and transformation leaders: Own strategic and portfolio-level agents that interpret enterprise strategy, value hypotheses, capability maps, and performance signals to propose and monitor plays and pivots. Behavior: There is a clear RACI for who defines agents, who owns and evolves shared rules and data models, and who is accountable when agent behavior causes harm or drifts from intended purpose.
Define the agentic fabric as software
Articulate a reference model in which enterprise software is understood as a layered fabric. Data and systems: SaaS platforms, line-of-business applications, data lakehouses, and observability infrastructure. Business rules and processes: Explicit, system-agnostic rules and process definitions that describe valid transactions, decisions, and workflows across the estate. Data rules: Shared data models, classifications, and constraints that define what entities exist, how they relate, and what constitutes valid states and transitions. Experiences: Familiar, relatively stable human-facing displays and interactions, such as material-design-style views for lists, records, dashboards, and trend visualizations. Agents: AI components that interpret intent, plan, and act across the underlying systems using tools, APIs, and workflows, guided by business rules, data rules, and identity-aware policy. Behavior: Architectural discussions explicitly treat agents, business rules, and data rules as the primary orchestration and decision layer across this stack, rather than treating each application as an independent island with its own hidden logic.
Strategic and portfolio-level agents
In an agentic enterprise architecture, some agents are designed explicitly to help leaders interpret, evolve, and execute enterprise strategy and portfolios. Strategic agents operate over codified strategy documents, capability maps, value hypotheses, and performance telemetry, together with cross-cutting data that few individuals can see end-to-end but that agents can reason over under strict abstraction and identity-aware rules. Their outputs include proposals for new plays and experiments, reallocation of resources in the strategic portfolio, signals for strategic pivots or industry relationship changes, and continuous narratives that connect operational signals back to enterprise strategy and culture. As the number of agents grows to many times the number of employees, these strategic and portfolio-level agents act as a force multiplier for strategic thinking, transformation, execution, operations tuning, and culture nurturance, subject to oversight by Enterprise AI Governance and strategic leadership.
Stabilize experiences, externalize business rules
Commit to a design principle: keep human-facing experiences familiar and relatively stable, while moving change and differentiation into agents and shared rule services. Maintain a small set of consistent UI patterns for core tasks such as viewing lists and records, reviewing trends, and asking and answering questions about operations and performance. Codify business rules into reusable, versioned services, such as decision services and workflow definitions, that can be invoked by both agents and UI components, instead of embedding them in UI flows or scattered application code. Treat UI work primarily as sense-making and trust-building, providing clear displays, explanations, and controls, while treating agents and rules as the primary mechanism for evolving functionality and process behavior. Behavior: New feature proposals are first framed as changes to shared business rules, data rules, and agent capabilities, and only secondarily as new bespoke UI flows.
Make identity-aware agent design the default
Design every agent with explicit identity-aware behavior tied to the shared policy authority and rule substrate. Define who the agent acts for—human identity, enterprise function, or both—and map that to entitlements in Pillar A’s shared policy authority, including which business rules and data domains the agent may exercise. Use identity-aware retrieval and abstraction so that agent behavior is constrained to what the acting and recipient identities are allowed to read, transform, and reveal, even when agents cross multiple systems. Ensure that agent tool access, AI platform access, and cross-agent calls are governed by identity providers, identity governance and administration, and policy engines rather than static credentials or local configuration. Behavior: No agent is deployed without a clear mapping to identity-aware policies, permissible rule invocations, and enforcement contexts; agents cannot quietly become more privileged than the identities and functions they represent.
Design agent capabilities as scoped manifests
Treat each agent’s capabilities as a declarative manifest that can be reviewed, tested, and governed. Enumerate allowed tools, APIs, and workflows, along with constraints on parameters, frequency, environment, and context. Reference named business rules and decision services, such as OrderValidation, PricingPolicy, or ApprovalFlow, instead of embedding opaque logic inside the agent. Reference data rules and contracts, such as schemas, quality profiles, and state-transition rules for entities like orders, accounts, and entitlements, that must be satisfied before agents can commit transactions. Behavior: Capability manifests serve as the primary artifact for agent design and governance; changes to agent behavior are primarily changes to manifests, shared rules, and policies, not untracked edits in agent code.
Use agent protocols and orchestration patterns deliberately
Adopt and standardize agent protocols and orchestration patterns that align with the agentic fabric vision. Use agent protocols and tool-connection patterns that make identity, capability, and provenance explicit, rather than bespoke glue that obscures who is acting, with what authority, and via which rules. Distinguish personal agents, acting on behalf of a specific human, from enterprise agents, acting for a function or process, and from multi-agent workflows, and design different identity, rule, and monitoring patterns for each. Prefer orchestration that is explainable and observable, using planners and controllers whose choices can be logged, inspected, and connected back to business rules and data rules. Behavior: The agent platform team maintains an opinionated set of orchestration patterns and discourages ad hoc agent chaining that undermines observability, safety, or alignment with shared rules and policies.
Treat agents as first-class identities
Implement strong lifecycle and entitlement governance for agents as non-human identities. Represent agents explicitly in identity governance and identity systems, with owners, lifecycle states, entitlements, and associated rule scopes. Use workload-identity standards and secrets management to avoid long-lived credentials for agents and their tools, and authenticate agents strongly to both systems and rule services. Review agent entitlements and rule access regularly, with clear owners responsible for certifying that each agent’s scope remains appropriate to its purpose and risk level. Behavior: Security and identity teams can produce an inventory of active agents, their owners, entitlements, accessible rule sets, and last review date on demand.
Embed agentic architecture into the five-pillar AI security stack
Align agentic architecture with the five pillars of identity-aware AI security. Pillar A, identity-aware authorization policy management, uses a shared policy authority to define which agents may access which business rules, data domains, and tools, under what conditions, and manages these policies as versioned, testable artifacts. Pillar B, identity-aware retrieval, ensures agents retrieve only data that their identities, and acting humans where applicable, are entitled to see, using data rules and classifications to scope queries and retrieval. Pillar C, identity-aware abstraction, governs what level of detail agents may reveal about trends, transactions, and decisions to different audiences, based on their clearance and need-to-know. Pillar D, post-AI security operations, monitors agent prompts, tool calls, outputs, and transactions for anomalies, policy violations, and misaligned behavior, and feeds findings back into business rules, data rules, and policies. Pillar E, enterprise AI governance, brings high-impact and high-risk agents under cross-functional oversight, aligning agent behavior and rule changes with enterprise values, regulatory obligations, and risk appetite. Behavior: The agent platform’s reference architecture explicitly maps agent behaviors, rule invocations, and data access to relevant pillars and enforcement contexts, and these mappings are used during design and review.
Operate as an enterprise counterweight to vendor architectures
Recognize that vendors will continue to design products, and increasingly their own agent ecosystems, according to customer needs, market forces, and competitive pressures. Assume that some vendors will support deep, open participation in an agentic fabric with API-first designs, rich events, and rule- and policy hooks, while others will primarily enable agentic patterns inside their own product boundaries. Treat the enterprise’s codified business rules, data rules, and agentic architecture as a counterweight that preserves strategic control over how work is orchestrated and how data is used, regardless of where vendor ecosystems sit on that spectrum. Use architecture standards, integration roadmaps, and procurement language to encourage vendors to expose capabilities, events, and rule hooks that can plug into the enterprise’s agentic fabric, without assuming any one vendor will define it for the enterprise. Behavior: When adopting or expanding SaaS, enterprise architects ask not just what features it has but how well it participates in the agentic fabric, the business rule layer, the data rule layer, and the identity-aware security stack, and they plan compensating patterns where vendor ecosystems remain more closed.
Govern the shift away from UI-centric software
Manage the transition from UI-centric to agent-centric interaction thoughtfully. Inventory key workflows and experiences, then identify where agent mediation can safely reduce reliance on bespoke UI without undermining trust, compliance, or explainability. Prioritize use cases where agents can relieve swivel-chair work, such as reconciling data across systems, recording transactions according to shared business rules, and surfacing and explaining trends based on unified data rules. Define criteria for when a traditional UI remains necessary, for example in complex edge conditions, high-stakes approvals, or regulatory attestations that require explicit human actions. Behavior: The architecture and product roadmap includes a visible shift plan that describes which workflows will move to agent mediation when, under what governance and UX constraints, and with which underlying rules and data foundations.
Instrument agents for explanation, audit, and learning
Build agents with explanation, auditability, and learning as core features. Log agent plans, tool calls, rule invocations, and key decision points in structured, queryable form, tied to identities, rule versions, data contracts, and policy versions. Provide human-facing explanations of why an agent took or recommended an action, referencing the business rules and data rules that were applied and the systems that were touched. Feed incident, data loss prevention, and anomaly data from security operations back into rule revisions, policy changes, and agent manifests, closing the loop between observed behavior and architectural intent. Behavior: When an agent behaves unexpectedly, teams can quickly reconstruct what rules were applied to which data under which identity context, decide whether the rules or policies were wrong, and adjust the shared foundations accordingly.
Minimum viable agentic enterprise architecture
An enterprise is considered to be practicing agentic enterprise architecture when several conditions are met. A shared, system-agnostic business rule layer and data rule layer exists, with versioned, testable artifacts that can be invoked by both agents and conventional applications. Agents are defined and managed as first-class identities with scoped capabilities, owned by specific teams, and governed by the shared policy authority, business rules, and data rules. Core workflows increasingly run through agents that read, act, and answer questions across systems, while human-facing displays stabilize into a small set of familiar patterns for viewing records and trends and asking questions. The agent platform is integrated with the five pillars of identity-aware AI security and with existing security operations, so agent behavior is constrained, monitored, and iteratively improved. Enterprise AI Governance and adjacent boards have visibility into high-impact agents and the shared rules they rely on, can adjust scopes and guardrails, and receive regular reporting on how the agentic fabric affects strategy execution, risk, workforce impact, and culture. Behavior: Software strategy discussions naturally frame new functionality as changes to agents, shared business rules, data rules, and policies within a governed agentic fabric, rather than as isolated application builds or one-off integrations.