Scope

Domain 7 covers the architectural design of enterprise AI systems — the technical layer of AI Transformation. It addresses how AI agents, multi-agent systems, and agentic workflows are designed, deployed, and operated in enterprise environments.

D7 is the most technically oriented domain in the AEBOK™. It is not a software engineering curriculum — it does not teach practitioners how to build AI models. It teaches practitioners how to design the architectural systems that deploy, integrate, and govern AI models in enterprise contexts. The distinction is important: enterprise AI architecture is a systems design discipline, not a machine learning discipline.

What This Domain Covers

• AI agent design patterns — the architectural patterns for building reliable, governable AI agents
• Multi-agent system architecture — how multiple AI agents are orchestrated to execute complex workflows
• Enterprise AI platform selection — the criteria for evaluating and selecting AI platforms
• Agentic workflow design — how business processes are redesigned for agentic execution
• AI integration architecture — how AI systems are connected to enterprise data, applications, and processes
• AI infrastructure design — the compute, storage, and networking requirements for enterprise AI
• AI observability — how AI system behavior is monitored, measured, and governed in production

Core Concepts

C7.1 — AI Agent Design Patterns

An AI agent is an autonomous software system that perceives its environment, makes decisions, and takes actions to achieve defined goals. Enterprise AI agents are distinguished from consumer AI assistants by four characteristics: they operate in production environments with real business consequences, they are integrated with enterprise systems and data, they are governed by enterprise policies and controls, and they are accountable to enterprise stakeholders.

The AEBOK™ identifies four primary AI agent design patterns:

• Pattern 1 — Reactive Agent: An agent that responds to inputs and produces outputs without maintaining state between interactions. Reactive agents are the simplest pattern — they are stateless, predictable, and easy to govern. They are appropriate for well-defined, bounded tasks where the input-output relationship is stable.
• Pattern 2 — Deliberative Agent: An agent that maintains an internal model of its environment and uses that model to plan its actions. Deliberative agents can handle more complex tasks than reactive agents — they can reason about multi-step workflows and adapt their plans when conditions change. They require more sophisticated governance because their behavior is less predictable.
• Pattern 3 — Tool-Using Agent: An agent that can invoke external tools — APIs, databases, search engines, code interpreters — to gather information and take actions. Tool-using agents are the most common pattern in enterprise AI deployments. They can execute complex, multi-step workflows by combining their reasoning capability with access to enterprise systems and data.
• Pattern 4 — Orchestrator Agent: An agent that coordinates the actions of other agents. Orchestrator agents are the architectural foundation of multi-agent systems — they receive high-level goals, decompose them into sub-tasks, assign sub-tasks to specialized agents, and integrate the results. They require the most sophisticated governance because their behavior depends on the behavior of all the agents they coordinate.

C7.2 — Multi-Agent System Architecture

Multi-agent systems are architectures in which multiple AI agents collaborate to execute complex workflows that no single agent could execute alone. They are the architectural foundation of the Autonomous Enterprise — the mechanism by which autonomous AI systems can handle the full complexity of enterprise business processes.

Multi-agent system design addresses four architectural challenges:

• Agent specialization: Each agent in a multi-agent system should be specialized for a specific type of task. Specialization improves reliability — a specialized agent is more likely to perform its specific task correctly than a generalist agent. It also improves governability — the behavior of a specialized agent is more predictable and easier to monitor.
• Orchestration design: The orchestration layer coordinates the actions of specialized agents. Orchestration design determines how tasks are decomposed, how agents are selected, how results are integrated, and how errors are handled. Poor orchestration design is the most common cause of multi-agent system failures.
• State management: Multi-agent systems must maintain state across multiple agent interactions. State management design determines what information is stored, where it is stored, how it is accessed by agents, and how it is governed. State management failures can cause multi-agent systems to lose context, repeat actions, or produce inconsistent results.
• Error handling: Multi-agent systems are more susceptible to cascading failures than single-agent systems — an error in one agent can propagate through the orchestration layer to affect other agents. Error handling design must address how errors are detected, contained, and recovered from at each level of the system.

C7.3 — Enterprise AI Platform Selection

Enterprise AI platform selection is one of the most consequential architectural decisions in an AI Transformation program. The platform determines the capabilities available to AI development teams, the integration options for connecting AI to enterprise systems, the governance tools available for monitoring and controlling AI behavior, and the total cost of ownership for the AI program.

The AEBOK™ identifies six criteria for enterprise AI platform evaluation:

• Capability fit: Does the platform support the AI agent patterns and multi-agent architectures required by the transformation program? Does it support the model types (LLMs, specialized models, custom models) that the program requires?
• Integration architecture: How does the platform connect to enterprise data sources, applications, and processes? Does it support the integration patterns required by the transformation program? What is the integration complexity and cost?
• Governance tooling: What governance capabilities does the platform provide? Does it support the monitoring, audit trail, and human override requirements of the AI governance framework? Can it be integrated with the enterprise's existing governance and risk management systems?
• Security and compliance: Does the platform meet the organization's security requirements? Does it support the compliance requirements of the applicable regulatory frameworks? Where does data reside, and who has access to it?
• Scalability and reliability: Can the platform scale to support the volume of AI agent interactions required by the transformation program? What are the reliability and availability guarantees? What is the disaster recovery capability?
• Total cost of ownership: What is the full cost of the platform — including licensing, infrastructure, integration, training, and ongoing operations? How does the cost scale as the program grows?

C7.4 — AI Observability

AI observability is the practice of monitoring, measuring, and understanding the behavior of AI systems in production. It is the technical foundation of AI governance — without observability, governance is blind.

Enterprise AI observability has four components:

• Performance monitoring: Tracking the technical performance of AI systems — latency, throughput, error rates, and availability. Performance monitoring is the baseline of observability — it tells you whether the system is working, but not whether it is working correctly.
• Behavioral monitoring: Tracking the decisions and actions of AI agents — what inputs they received, what decisions they made, what actions they took, and what outcomes resulted. Behavioral monitoring is the foundation of AI governance — it provides the audit trail required to investigate AI behavior and detect governance violations.
• Quality monitoring: Tracking the quality of AI outputs — accuracy, bias, consistency, and alignment with intended behavior. Quality monitoring detects model drift, distributional shift, and other quality degradation patterns that can cause AI systems to produce incorrect or harmful outputs over time.
• Business impact monitoring: Tracking the business outcomes produced by AI systems — the value they generate, the costs they reduce, and the risks they create. Business impact monitoring is the foundation of AI value measurement — it provides the data required to demonstrate ROI and sustain executive commitment.

C7.5 — Agentic Workflow Design

Agentic workflow design is the practice of redesigning business processes to be executed by AI agents. It is distinct from traditional process design in three important ways: the process must be decomposable into tasks that AI agents can execute reliably; the process must include explicit human oversight and exception handling mechanisms; and the process must be designed with governance requirements in mind from the start.

The AEBOK™ agentic workflow design methodology follows five steps:

• Step 1 — Process mapping: Document the current process in sufficient detail to identify which steps are candidates for agentic execution. Identify the inputs, outputs, decisions, and dependencies for each step.
• Step 2 — Agentic feasibility assessment: Evaluate each step against the criteria for agentic execution: Is the task well-defined? Is the input-output relationship stable? Can the AI agent's performance be reliably measured? Are the governance requirements manageable?
• Step 3 — Human-AI boundary design: Define the boundary between agent-executed steps and human-executed steps. Design the oversight mechanisms, exception handling protocols, and accountability structures for the boundary.
• Step 4 — Agent architecture design: Select the appropriate agent design pattern for each agentic step. Design the orchestration layer for multi-step workflows. Define the state management, error handling, and observability requirements.
• Step 5 — Governance integration: Integrate the governance requirements — audit trail, human override, compliance controls — into the workflow design. Validate the design against the AI governance framework before development begins.

Framework Alignment

AEF™ — Supporting Framework

D7 addresses the technical implementation of the Autonomy and Integration pillars of the AEF™. The architectural decisions made in D7 directly determine the organization's capacity to advance along these two pillars.

AEOM™ — Supporting Framework

The AI platform and infrastructure decisions made in D7 are components of the AI operating model. D7 architecture design must be integrated with D4 operating model design — the platform selection, integration architecture, and observability design decisions made in D7 directly affect the operating model's capability to deploy and govern AI systems.

AEGF™ — Supporting Framework

AI observability is the technical foundation of AI governance. The observability architecture designed in D7 must support the governance requirements defined in D5 — the audit trail, behavioral monitoring, and human override mechanisms required by the AEGF™.

Practitioner Tools

Tool D7.1 — AI Agent Design Pattern Selector

A decision tool for selecting the appropriate AI agent design pattern for a specific use case. Evaluates the use case against the four pattern criteria and recommends the most appropriate pattern with rationale.

Tool D7.2 — Multi-Agent System Architecture Template

A structured template for designing multi-agent system architectures. Covers agent specialization, orchestration design, state management, and error handling. Includes architecture diagram templates and design review checklists.

Tool D7.3 — AI Platform Evaluation Scorecard

A structured scorecard for evaluating AI platforms against the six AEBOK™ criteria. Produces a weighted score for each platform and a comparative analysis to support platform selection decisions.

Tool D7.4 — Agentic Workflow Design Canvas

A structured template for designing agentic workflows using the five-step methodology. Produces a workflow design document that includes process map, human-AI boundary definition, agent architecture, and governance integration plan.

Tool D7.5 — AI Observability Framework

A structured framework for designing the observability architecture for an AI system or program. Covers performance monitoring, behavioral monitoring, quality monitoring, and business impact monitoring. Includes dashboard templates and alerting design guidance.

Competency Indicators

Level 1 — Awareness

Can describe the four AI agent design patterns and explain when each is appropriate. Understands the architectural challenges of multi-agent systems. Can explain the six criteria for enterprise AI platform evaluation.

Level 2 — Practitioner

Can design an agentic workflow using the five-step methodology. Can evaluate AI platforms against the six AEBOK™ criteria. Can design the observability architecture for a specific AI system. Can conduct an agentic feasibility assessment for a business process.

Level 3 — Architect

Can design the complete enterprise AI architecture for an AI Transformation program — including agent architecture, multi-agent system design, platform selection, integration architecture, and observability framework. Can lead the technical architecture review for complex AI deployments.

Level 4 — Leader

Can own the enterprise AI architecture at the program level. Can make the platform selection, integration architecture, and observability design decisions required to build a scalable, governable Autonomous Enterprise. Can represent the technical architecture to the board and to regulators.

Certification Mapping

EAA™ — Enterprise AI Architect

D7 constitutes approximately 40% of the EAA™ exam. The EAA™ is the specialist certification for enterprise AI architects. The capstone requires candidates to produce a complete enterprise AI architecture design — including agent architecture, multi-agent system design, platform evaluation, and observability framework — for a real or hypothetical organization.

Case Study: HealthCo (Architecture Failure)

Composite case study. All names and identifying details are anonymized.

Context

HealthCo (introduced in D3) had completed its foundation-building program and was deploying AI agents across its clinical and administrative workflows. One of the highest-priority deployments was a clinical documentation AI — an agent that would automatically generate clinical notes from physician-patient conversations, reducing documentation time by an estimated 60%.

The Problem

The clinical documentation AI was deployed using a reactive agent pattern — it received a conversation transcript as input and produced a clinical note as output. The architecture worked well for straightforward consultations. It failed for complex cases where the physician needed to review and correct the note before it was filed in the electronic health record.

The failure was architectural: the reactive agent pattern did not include a human review step. Notes were being filed in the EHR without physician review because the workflow had not been designed with a human-AI boundary. Physicians assumed the AI was handling the filing; the AI assumed the physician was reviewing the notes. Neither was true.

The Intervention

The architecture was redesigned using the deliberative agent pattern with an explicit human review step. The agent produced a draft note and presented it to the physician for review before filing. The human-AI boundary was designed into the workflow — not assumed. The observability architecture was enhanced to track whether physicians were reviewing notes before filing, and to alert the governance team if the review rate fell below a defined threshold.

The Outcome

The redesigned system achieved the 60% documentation time reduction target while maintaining physician oversight of all clinical notes. The observability architecture detected two instances of the review rate falling below threshold in the first six months — both were addressed before they caused clinical harm.

Key Lesson

Agent design pattern selection is a governance decision, not just a technical decision. The reactive agent pattern is appropriate for tasks where human oversight is not required. For tasks where human oversight is required — especially in high-stakes environments like healthcare — the architecture must include explicit human review mechanisms. The architecture cannot assume that humans will insert themselves into the workflow; it must design the workflow to require their participation.

Monday Morning Actions

For Practitioners — This Week

• Review one AI agent currently deployed in your organization. Which design pattern does it use? Is that the right pattern for the task? What governance mechanisms are built into the architecture?
• Identify one business process in your organization that is a candidate for agentic execution. Conduct an agentic feasibility assessment using the D7 criteria. What would the architecture look like?
• Evaluate your organization's AI observability capability. Which of the four observability components are in place? Which are missing?

For Managers — This Month

• Conduct an AI platform evaluation for your current or planned AI platform using the six AEBOK™ criteria. What are the platform's strengths and weaknesses? What gaps need to be addressed?
• Design the observability architecture for one AI system in your domain. Define the performance, behavioral, quality, and business impact monitoring requirements. Identify the gaps between the current observability capability and the requirements.
• Review the agentic workflow designs for AI systems currently in development in your domain. Are the human-AI boundaries clearly defined? Are the governance requirements integrated into the design?

For Executives — This Quarter

• Commission an enterprise AI architecture review. Evaluate the current architecture against the D7 frameworks. Identify the architectural gaps that are limiting the program's ability to scale.
• Review your AI platform strategy. Is the current platform capable of supporting the target operating model? What platform investments are required to get there?
• Evaluate your AI observability capability. Can you answer the question: "What are our AI agents doing right now?" If not, what would it take to build that capability?