Every assessment framework eventually converges on a question of structure: what are the distinct capabilities that an organization must develop, and how do they relate to each other? This report's answer, derived from analysis of dozens of enterprise agentic deployments across industries and from the governance frameworks examined in the preceding chapter, is four pillars. Governance and risk. Orchestration and architecture. Use case identification and portfolio management. Integration and data. An enterprise can be strong in three and critically weak in the fourth, and the weak pillar will determine the program's outcomes regardless of the others' strength. Understanding the four pillars — what each encompasses, why it matters, and how it interacts with the others — is the bridge from the conceptual foundation built in Part I to the operational detail of Part II.
Pillar I — Governance and Risk
Governance is the first pillar, and it is first not because it is the most technically interesting but because it is the one that enables the others. Without a governance framework — a clear assignment of accountability, a policy stack that translates risk appetite into operational rules, a risk management process that can evaluate and approve agentic deployments — the other pillars operate in an organizational vacuum. Agents get deployed without adequate review, incidents occur without clear ownership, and the program accumulates technical debt alongside governance debt in a combination that eventually requires painful remediation.
The governance pillar encompasses several distinct domains. Accountability assignment: who is responsible for each deployed agent, for the policy stack that governs it, and for the incident response when it fails? In most organizations, this assignment does not exist at the start of an agentic program and must be created, typically through a governance charter and the establishment of an AI program office or center of excellence. Policy development: the acceptable-use policy for agents, the model risk policy that governs model selection and evaluation, the data classification policy that determines what data agents can access, and the incident response process specific to agent failures. Regulatory compliance: the mapping of deployed agents to applicable regulatory requirements (EU AI Act risk classification, sectoral rules, state-level requirements) and the maintenance of the documentation and audit trail those requirements demand.
Governance failures are the most common cause of enterprise agentic program setbacks that are not immediately visible in technical metrics. An agent that is technically well-built but deployed without adequate governance review may perform well for months before a compliance gap, a policy violation, or an accountability question surfaces in a context — regulatory inquiry, board audit, media incident — where the absence of governance infrastructure is deeply inconvenient. The organizations that avoid this experience build governance alongside capability, not after it.
Pillar II — Orchestration and Architecture
The orchestration pillar is where the technical substance of agentic AI lives: the frameworks, runtimes, evaluation systems, and guardrail infrastructure that make agents work reliably in production. It is the pillar most familiar to engineering teams — the one that maps most directly to the build-and-ship work that engineering organizations know how to do — and it is consequently often the most developed and the least often the limiting factor in a mature program. The more common pattern is that orchestration is developed while governance and integration lag.
Orchestration encompasses: the choice of agent framework (LangGraph, AutoGen, CrewAI, or proprietary platforms like ServiceNow AI Agent Fabric) and the implications of that choice for architecture, vendor dependency, and governance capability; memory architecture and the state management patterns that allow agents to maintain context across sessions and tasks; evaluation infrastructure — the harness of automated tests, human review processes, and metric dashboards that provide the continuous quality signal needed to detect capability drift and policy violations; and guardrails, the runtime policy enforcement that prevents agents from taking actions outside their defined permission envelope.
The orchestration pillar is also where observability lives. An orchestration stack without adequate observability is a production deployment without instruments — you will discover problems from their effects rather than from their early signals, and the effects of agentic failures are often more expensive than the failures themselves. Trace-level, metric-level, and evaluation-level observability should be designed into the orchestration architecture from the start, not bolted on after the first incident.
Pillar III — Use Case Identification
The use case pillar is about selection: choosing the right work for agents to do. This sounds like a strategy question, and it partly is, but it is also an engineering and governance question. Not all tasks are equally well-matched to agentic approaches; not all tasks that are well-matched carry the same risk profile; and not all tasks that look promising in a pilot environment scale successfully to production. The use case pillar is the structured process for making these distinctions and acting on them.
Use case identification involves a portfolio approach: mapping the landscape of candidate tasks, scoring them on value (what is the economic and strategic return if the agent succeeds?) and feasibility (how mature is the technology, how well-defined is the task, how reversible are the agent's actions?), and selecting a prioritized portfolio that balances quick wins (high feasibility, moderate value) with strategic investments (high value, higher complexity) and lighthouse projects (the use cases that demonstrate transformative capability and earn the next round of funding).
The human-in-the-loop design question — for each use case, at what points should a human review the agent's work, and what triggers escalation? — is also part of the use case pillar. This design question is not purely a safety question; it is also an economics question. Checkpoints that are too frequent recover the labor cost the agent was supposed to eliminate. Checkpoints that are too infrequent allow errors to propagate at scale. The right answer depends on the specific task, the agent's demonstrated quality at that task, and the organization's risk tolerance — and it should be revisited as the agent matures and quality metrics are established.
Pillar IV — Integration and Data
The integration pillar is, in many enterprise programs, the one that most consistently surprises. It is the pillar that determines whether an agent can actually do useful work, because an agent without reliable access to the systems and data it needs is, in practice, a capability demonstration rather than a production system. Integration work is also the pillar that most often hits organizational boundaries — the teams that own the CRM, the ERP, the data warehouse, and the identity provider may not be in the chain of command of the team building the agent, and their cooperation is not guaranteed.
Integration encompasses: system connectivity, the technical work of connecting the agent to enterprise systems through APIs, MCP servers, or direct database access; identity and access management, the design and implementation of the agent's identity model, its credential management, and its scoped access to enterprise systems; data readiness, the quality, currency, and governance of the data that the agent will retrieve and act upon; and interoperability protocols, the adoption of standards like MCP and A2A that allow agents to communicate with tools and with each other in a governed, auditable way.
Data readiness is frequently the binding constraint in integration. Organizations discover, through the process of building agentic systems, that their data is less clean, less well-governed, and less accessible than they believed. Knowledge bases contain stale documents. CRM data has quality problems that were acceptable when humans were reading it but are unacceptable when an agent is acting on it at scale. Data classification is inadequate to support the access control requirements of an agent that operates across many domains and serves users with different permission levels. Addressing these problems takes time and organizational will — and the time to start is before the agent deployment rather than after the pilot has demonstrated that the data is a problem.
The Pillar Interactions
The four pillars are not independent. Each depends on the others, and weakness in one propagates. A strong orchestration stack without adequate governance is a capable but ungoverned agent program — technically impressive, organizationally vulnerable. Strong governance and orchestration without adequate integration produces agents that are well-governed and well-built but cannot access the systems needed to be useful. Excellent use case selection without the integration and orchestration to support the selected use cases produces a roadmap that looks compelling and lands nowhere.
The most effective approach to building agentic readiness is to develop all four pillars in parallel, with a shared timeline and explicit dependencies between them. The governance pillar should set the policy requirements that the orchestration pillar implements as guardrails. The use case pillar should be informed by the integration pillar's realistic assessment of what is achievable with the data and systems available. The orchestration pillar's evaluation infrastructure should be informed by the specific failure modes that the governance pillar's risk analysis has identified as most important to detect and measure.
This parallel development requires cross-functional coordination — between the engineering team building the orchestration stack, the governance team developing policies, the business teams identifying use cases, and the platform and data engineering teams managing integration. That coordination is itself a governance challenge, and it is the one that most commonly falls through the cracks in organizations that are accustomed to sequencing technology and governance as separate workstreams. The agentic enterprise is an integrated system; it requires integrated development.
"A program that stands on three pillars and ignores the fourth will tip over within a year. The tipping usually happens in a way that was entirely predictable from the structure of the program — and entirely surprising to the leadership who approved it."