---

From Readiness to Acquisition

In Part 9, we covered the workforce dimension: preparing people for the shift to hybrid human-agent teams. With readiness now mapped across strategy, technology, data, governance, and people, the next question is practical: how do you evaluate the vendors and platforms that will power your agentic enterprise?

This is not a standard software procurement exercise. Agentic AI systems affect workflow design, data governance, compliance posture, and downstream cost structures in ways that traditional enterprise software does not. The vendor decisions you make now will shape your operational architecture for years.

The global agentic AI market is projected to surpass $9 billion in 2026, and Gartner projects that 40 percent of enterprise applications will include task-specific AI agents by year-end, up from less than 5 percent in 2025. The vendor landscape is expanding rapidly, and the gap between marketing claims and production reality has never been wider.

The Vendor Landscape: Four Categories

The agentic AI vendor landscape has organized into four broad categories, each with distinct value propositions and trade-offs.

Enterprise platform vendors like Salesforce (Agentforce), Microsoft (Copilot Studio), IBM (watsonx Orchestrate), ServiceNow, and AWS (Bedrock Agents) are embedding agent functionality directly into the enterprise software organizations already use. Their advantage is integration depth: native connections to your data, workflows, and identity infrastructure. The trade-off is that their agent capabilities are optimized for their ecosystem and may not extend well beyond it.

AI model and platform providers like OpenAI, Anthropic, and Google offer the foundational models and development environments for building custom agents. These providers are no longer just selling API access. They are building toward becoming the operating layer of enterprise AI workflows. Their advantage is flexibility and model capability. The trade-off is more engineering investment and tighter integration work.

Agentic AI services providers including Accenture, Deloitte, KPMG, and Capgemini combine consulting expertise with AI agent orchestration to deliver turnkey solutions. They make sense for organizations with complex legacy environments or limited internal AI capabilities. The trade-off is cost and potential dependency on the services partner for ongoing operations.

Pure-play agent platform vendors offer specialized agent development, orchestration, and management platforms, ranging from open-source frameworks like LangGraph, CrewAI, and AutoGen to commercial platforms focused on agent monitoring, workflow orchestration, or domain-specific applications. Their advantage is specialization. The trade-off is adding another vendor to your stack.

Most enterprises will work with vendors from multiple categories. The question is not which category to choose but how to compose a stack that balances integration, flexibility, and control.

Evaluation Criteria That Matter

When evaluating agentic AI vendors, the criteria that matter in practice are different from what dominates marketing materials. Here is what experienced enterprise buyers are prioritizing in 2026.

Integration depth and API readiness. Can the platform connect to your existing systems in real time? An agent that cannot read and write to your ERP, CRM, or ITSM systems cannot close workflows or execute decisions. As we covered in Part 5, orchestration is only as strong as the weakest connection in the chain.

Governance and compliance capabilities. Can the platform enforce decision authority frameworks, maintain audit trails, and support escalation protocols? As Part 8 made clear, governance for autonomous systems requires built-in capabilities, not bolt-on additions.

Orchestration architecture. Does the platform support the orchestration patterns your workflows require: sequential, parallel, hierarchical, and event-driven? Can it manage shared state across multi-agent workflows?

Observability and monitoring. Can you see what your agents are doing and why? Decision tracing, performance attribution, and drift detection are not optional for production deployments. Organizations report that observability infrastructure takes 30 to 40 percent of total implementation effort.

Security and identity management. Does the platform support agent-specific identities with scoped permissions and least-privilege access? Can it maintain audit trails tracking which agent accessed what data and why?

Data handling and context management. How does the platform manage the knowledge bases, context repositories, and data pipelines that agents depend on? As Part 7 established, data readiness is the most common blocker for agentic initiatives.

Scalability and cost transparency. Multi-agent orchestration is token-intensive, and costs multiply as workflows grow. Vendors should provide clear pricing models that let you project costs at scale. Hidden costs in API calls, compute, and data transfer can undermine the business case.

The Questions Vendors Should Be Able to Answer

Beyond feature checklists, there are questions that reveal whether a vendor has real enterprise deployment experience or is selling from a demo.

Ask about their permission scoping model. A mature vendor will describe specific mechanisms for controlling what agents can access, decide, and execute. A vendor that defaults to broad permissions or cannot articulate scoping in detail is a red flag.

Ask about failure modes. What happens when an agent encounters a situation outside its operating parameters? How does the system handle cascading failures in multi-agent workflows? Vendors with production experience will have specific answers. Vendors without it will give generic assurances.

Ask about customer references at your scale and in your industry. Request conversations with customers who have moved past proof of concept into production. The gap between pilot success and production reality is where most vendor promises break down.

Ask about interoperability. Standards like Google's Agent2Agent (A2A) protocol and Anthropic's Model Context Protocol (MCP) are emerging to enable cross-platform agent communication. Vendors that support these standards are positioning for the multi-vendor reality of enterprise AI. Vendors building closed ecosystems are positioning for lock-in.

Ask about intellectual property protections. Some vendors provide contractual protection against IP claims arising from AI-generated outputs. Others do not. For enterprises deploying AI in customer-facing or regulated workflows, this needs to be resolved before signing.

Designing a Meaningful Proof of Concept

Most enterprise AI evaluations include a proof of concept, but most are poorly designed. A well-structured POC typically requires 8 to 12 weeks and $75,000 to $150,000 in investment, and organizations using a structured methodology are 3.2 times more likely to achieve production deployment. Yet 62 percent of organizations struggle to move beyond the POC phase. The difference between a useful proof of concept and a wasted one comes down to design.

Start with a real business process, not a synthetic demo scenario. The POC should test the platform against actual data, actual workflows, and actual exception conditions. If the proof of concept works only on clean, curated data, it has not proved anything about production viability.

Define success criteria before you start, not after. Establish baselines for the current state of the process: how long tasks take, error rates, escalation frequency, and cost per transaction. Then define what improvement the POC needs to demonstrate to justify moving forward.

Design for production from day one. The most common failure mode is a proof of concept that works in isolation but cannot scale. Evaluate the platform's ability to handle production volumes, integrate with your security infrastructure, and operate within your governance framework during the POC, not after it.

Test edge cases and failure modes, not just the happy path. The value of an agentic system is how it behaves when data is incomplete, exceptions arise, and conditions deviate from the expected pattern. A proof of concept that only demonstrates the straightforward scenario has not demonstrated production readiness.

Include your people in the evaluation. If your team cannot operate the platform effectively, the technology's capabilities are irrelevant. Evaluate the learning curve, documentation quality, and whether the vendor provides the training and support your people need.

Reference Architecture: What the Stack Looks Like

An enterprise agentic AI stack is not a single platform. It is a layered architecture with distinct responsibilities at each level.

The engagement layer is where humans and other systems interact with agentic capabilities through user interfaces, chat channels, APIs, and workflow triggers, handling authentication and channel-specific behaviors.

The orchestration layer routes work, decomposes goals, coordinates multiple agents, and manages workflow lifecycle. This is where the planner, policy engine, human-in-the-lead hooks, and retry logic reside.

The agent execution layer is where individual agents perform their assigned tasks: reasoning, tool use, data retrieval, and action execution, each operating within defined parameters.

The data and knowledge layer provides the context agents need: enterprise data stores, knowledge bases, vector databases for retrieval, and real-time data feeds. Part 7's data readiness discussion maps directly to this layer.

The governance and observability layer spans the entire stack, enforcing policies, maintaining audit trails, tracking agent decisions, and providing monitoring infrastructure. Part 8's governance framework operates at this level.

The infrastructure layer provides the compute, networking, storage, and security services the stack depends on, including model hosting, API management, and identity services.

The critical insight is that this is a design problem, not a tool selection problem. Most enterprise deployments that fail do so because teams select a framework before designing the governance, memory, and integration layers.

Red Flags and Common Vendor Traps

Experienced enterprise buyers have identified several patterns that signal risk in vendor evaluation.

The demo-to-production gap. While 79 percent of organizations report some AI agent adoption, only 11 percent are in production and just 2 percent have deployed at full scale. Vendors that showcase impressive demos but cannot provide references for production deployments are selling capability, not delivery. Ask where their customers are on that spectrum.

Opaque pricing models. If you cannot project costs at production scale from the vendor's pricing information, you do not have enough information to decide. Token costs, API call charges, compute fees, and data transfer costs should be transparent and predictable.

Closed ecosystems without interoperability paths. With 81 percent of enterprise leaders expressing concern about AI vendor dependency and only 6 percent able to switch providers without disruption, interoperability is a strategic requirement. Vendors building proprietary ecosystems with no support for emerging standards are optimizing for lock-in, not for your long-term flexibility.

Security by assertion rather than architecture. Research shows that 63 percent of organizations cannot enforce purpose limitations on their agents and 60 percent cannot terminate a misbehaving agent once it starts operating. Vendors that claim to have solved agent security without describing specific mechanisms for permission scoping, audit logging, and agent termination should not make your shortlist.

Overreliance on a single model provider. Platforms tightly coupled to a single AI model provider expose you to compounding dependency risk. The discontinuation of OpenAI's Sora in 2026 is a reminder that provider stability cannot be assumed. Evaluate whether the platform supports model flexibility or locks you into a single provider's roadmap.

The Build-vs-Buy Decision Revisited

We covered the build, buy, assemble, or extend framework in Part 6. With evaluation data in hand, the decision becomes more concrete.

The data in 2026 shows that buying managed platforms delivers measurable ROI in one to six months, while building custom solutions typically takes 12 to 24 months to show returns but offers better long-term economics at scale. Enterprise-grade orchestration platforms with custom memory layers, observability, and security controls start at $100,000 and can exceed $500,000 for large-scale deployments.

The emerging consensus is that this is not a binary choice. Most enterprises are adopting a hybrid approach: buying foundational AI infrastructure while building proprietary orchestration and integration layers on top. Standard processes can run on standard platforms. Processes that define your competitive edge may warrant custom development. The deciding factors are your engineering capacity, the uniqueness of your workflows, and how much differentiation your agentic capabilities need to provide.

Making the Business Case

The business case for agentic AI investments has matured significantly. Companies report an average ROI of 171 percent from agentic AI deployments, with finance showing the fastest payback at around eight months and manufacturing following at 12 to 14 months.

But the business case needs to go beyond cost reduction. In 2026, the primary success metric is shifting from productivity gains to direct financial impact, combining top-line revenue growth with bottom-line profitability. Organizations that frame their agentic investments purely as efficiency plays are underselling the opportunity.

A robust business case should measure across three categories: labor efficiency (baseline hours versus post-deployment hours on target workflows), quality improvement (error rates, customer satisfaction, resolution rates), and speed acceleration (cycle time reduction). Define these baselines before deployment and measure at 30, 60, and 90 days. Include adaptability as a value driver: organizations that can reconfigure agent workflows in days rather than the months required for traditional system changes carry a measurable advantage in a business environment defined by constant change.

What It Takes: Cross-Dimensional Readiness

Effective vendor evaluation requires understanding your readiness across all six dimensions of the Agentic AI Readiness Assessment. You cannot evaluate a platform if you do not know what you need it to do, what data it needs to access, what governance it needs to support, and what your people need to operate it.

Here is what cross-dimensional readiness requires:

Start with strategic alignment. Know what business outcomes you are solving for before you evaluate platforms. The most common procurement mistake is evaluating technology capabilities before defining business requirements. Your use case priorities and strategic alignment should drive your evaluation criteria, not the other way around.

Assess your technical infrastructure honestly. Your API readiness, system interoperability, and identity management capabilities determine what orchestration is possible. A vendor platform cannot compensate for infrastructure gaps. Identify those gaps before evaluations so you can factor remediation costs into your total investment.

Validate data readiness before vendor selection. Test vendors against your actual data, not sanitized samples. If your data is fragmented, inconsistently categorized, or lacks real-time accessibility, address those issues in parallel with your vendor evaluation.

Ensure governance capabilities match your requirements. Part 8's governance framework should translate directly into evaluation criteria. Every vendor on your shortlist should be assessed against your specific governance requirements: decision authority, audit trails, escalation protocols, and compliance needs.

Factor workforce readiness into your evaluation. Part 9 documented that only 12 percent of workers use AI daily despite widespread deployment. If your team cannot operate the platform, its capabilities are wasted. Evaluate documentation quality, training resources, and vendor support alongside technical features.

Build your evaluation criteria before you start taking demos. If you walk into a demo without a structured evaluation framework, you will walk out impressed but uninformed. Define what matters, weight it, and score every vendor against the same criteria.

Up Next

In Part 11, we will pull everything together into a phased roadmap for building your agentic enterprise: what to do first, how to build momentum, and how to sustain the transformation over the 18 to 36 months it takes to move from vision to operational reality.

---

The Dimension Organizations Underestimate Most

In Part 8, we covered governance, trust, and guardrails for agentic systems. But even the most robust governance framework will not deliver results if the people in your organization are not ready to work alongside agents. And for most organizations, they are not.

Talent readiness sits at just 20 percent across enterprises, the lowest score of any AI readiness dimension, well below technical infrastructure at 43 percent and data management at 40 percent. Despite 82 percent of enterprise leaders saying their organization provides some form of AI training, 59 percent still report an AI skills gap. IDC estimates that skills shortages will cost the global economy up to $5.5 trillion by 2026 in product delays, quality issues, missed revenue, and impaired competitiveness.

These numbers tell a clear story. Organizations are investing heavily in platforms, data infrastructure, and governance frameworks while underinvesting in the people who need to operate within them. People readiness is not a soft topic. It is the dimension that determines whether everything else in this series translates from strategy to practice.

Task Redistribution, Not Wholesale Replacement

The most persistent fear around AI agents is that they will replace workers at scale. The evidence so far points in a different direction. AI is reshaping jobs more than it is eliminating them. Over the next two to three years, 50 to 55 percent of jobs in the United States will be reshaped by AI, with most employees retaining the same or similar roles but facing substantially new expectations for how they work. The World Economic Forum projects 170 million new jobs will emerge by 2030 while 92 million will be displaced, a net gain of 78 million positions.

The more useful lens is task redistribution, not job replacement. Current data shows that 47 percent of work tasks across occupations are still performed solely by humans, 22 percent by technology, and 30 percent by a combination of both. By 2030, employers expect these shares to be nearly evenly split. Anthropic's January 2026 Economic Index found that 52 percent of AI usage was classified as augmentation, where AI helps humans work better, compared with 45 percent classified as automation, where AI handles the task independently. The balance tips toward augmentation, not replacement.

What this means in practice is that most roles will not disappear. They will decompose into component tasks, and those tasks will be redistributed. Some move to agents. Some remain with humans. Many involve both working together. The challenge for organizations is not whether to automate jobs but how to redesign work so that humans and agents each handle what they do best.

The Organizational Shape Is Changing

This task redistribution is changing how organizations are structured. Since AI agents can take on many entry-level tasks like data gathering, processing, and initial analysis, some organizations are finding that the traditional pyramid, with a broad base of junior workers, a middle management layer, and a senior leadership team, no longer matches how work gets done.

The emerging pattern is closer to a diamond shape: a smaller base of entry-level workers, a strengthened middle tier that trains, oversees, and manages agents alongside more complex work, and a leadership team focused on strategy and judgment. This does not mean eliminating entry-level positions. It means redefining what entry-level work looks like when agents handle the most routine components.

The implication for workforce planning is significant. If the entry point to your organization has historically been task-heavy, process-oriented work, and agents now handle much of that work, you need a new model for how people enter the organization, build skills, and advance. The apprenticeship path that many industries have relied on for decades needs to be redesigned for a world where the apprentice tasks are increasingly performed by agents.

Emerging Roles in the Agentic Enterprise

New categories of work are emerging as organizations deploy agents at scale. These are not hypothetical. They are appearing in job postings and organizational charts today.

Agent orchestration designers focus on the interface between humans and agents. They design the workflows, escalation paths, and interaction patterns that determine how agents coordinate with each other and with people. This role requires a blend of process design expertise, understanding of agent capabilities, and deep knowledge of the business domain where the agents operate.

Agent supervisors and operators monitor agent performance, handle escalations, and intervene when agents encounter situations outside their operating parameters. As we discussed in Part 5, the human-in-the-lead model depends on people who can set direction, adjust strategy, and exercise judgment that agents cannot provide. Agent supervisors are the operational expression of that model.

AI governance specialists establish and enforce the guardrails for agent behavior, auditing agent decisions and ensuring accountability. As Part 8 made clear, governance for autonomous systems requires ongoing attention, and someone needs to own that work day to day.

AI trainers and knowledge curators maintain the knowledge bases, context repositories, and feedback loops that agents depend on. As we covered in Part 7, the knowledge management dimension of data readiness requires people who understand both the business domain and how agents retrieve and use information.

By 2027, analysts project that half of all AI-enabled enterprise applications will require new oversight positions dedicated to governance, risk, and accountability. By 2026, 40 percent of G2000 job roles will involve direct interaction with AI systems. These are not distant forecasts. They describe the workforce redesign that is already underway.

Skills Evolution

The skills that matter are shifting. The AI talent gap has moved from "prompt engineering" to "agentic orchestration." Writing and maintaining code is becoming less of a differentiator as agents handle more of the implementation work. What is becoming more valuable are higher-order capabilities: systems thinking, judgment under ambiguity, cross-functional collaboration, and the ability to work effectively with AI tools as partners.

Human skills, including creative thinking, resilience, flexibility, and leadership, remain critical and are becoming more valuable precisely because they are the capabilities that agents cannot replicate. The 56 percent wage premium emerging for AI-fluent professionals reflects a market that is already pricing in this skills shift.

Yet most organizations are not preparing their people for this transition. Only 35 percent of leaders report having a mature, organization-wide AI upskilling program. Most training is fragmented, optional, and disconnected from how employees do their jobs. A 2026 Gallup survey of more than 22,000 employees found that only about 12 percent of workers report using AI daily, despite widespread enterprise deployment of AI tools. The gap between providing access and building capability is where most workforce readiness efforts stall.

The practical implication is that AI literacy cannot be treated as a one-time training event. It needs to be embedded in how people learn to do their jobs, integrated into onboarding, woven into performance development, and supported by hands-on practice in real work contexts.

Managing Hybrid Human-Agent Teams

Managing a team that includes both people and agents is a different discipline from managing either one alone. Leaders accustomed to directing people now need to direct work, deciding which tasks flow to humans, which to agents, and which involve both working together. The manager's role shifts from sole decision-maker to system architect: designing how work flows, monitoring outcomes, and adjusting the balance as conditions change.

This shift is revealing a leadership readiness gap. Only 22 percent of business leaders believe they can effectively manage teams that combine humans and AI agents. The organizational factors that determine AI's real impact, including culture, manager support, and talent practices, account for more than twice the influence of individual mindset and behavior. In other words, it is not enough to train individual employees on AI tools. The management layer needs to be rebuilt for a hybrid workforce.

Effective hybrid team management requires clarity about what agents can and cannot do, transparent communication about how work is being redistributed, and mechanisms for people to provide feedback on agent performance. It also requires leaders who can act as a stabilizing force during a transition that triggers real anxiety. Leaders who dismiss that fear rather than addressing it will find adoption stalling regardless of how good their technology is.

Change Management: The Make-or-Break Discipline

The organizations that succeed with agentic AI will not be the ones with the best technology. They will be the ones that manage the human transition most effectively. Change management for the agentic enterprise goes beyond traditional approaches because the change is continuous, not a one-time event. Agent capabilities evolve. Roles shift. The balance between human and agent work keeps adjusting.

Effective change management for this transition requires several elements. First, transparent communication about what is changing and why. People need to understand the business rationale for agent deployment, how their roles will evolve, and what support is available. Sugar-coating the implications or pretending nothing will change erodes trust faster than honest acknowledgment of uncertainty.

Second, practical training that connects to real work. Abstract AI literacy courses that teach concepts without application produce low engagement and lower retention. Training should be embedded in actual workflows, with people learning to work alongside agents in the context of tasks they perform every day.

Third, visible leadership commitment. When leaders use agents in their own work, talk openly about what they are learning, and demonstrate that they are navigating the same transition, it normalizes the change. When leaders delegate agent adoption to their teams while continuing to work the old way, it signals that the transformation is optional.

Fourth, mechanisms for feedback and course correction. People who feel they have no voice in how work is being redesigned will resist the change, and their resistance will be rational. Building channels for employees to surface problems, suggest improvements, and flag concerns converts potential resisters into participants.

Cultural Readiness: From Resistance to Adaptation

Culture is the invisible infrastructure that determines whether change management succeeds or fails. Research shows that 67 percent of organizations are culturally and operationally unprepared for AI transformation. The cultural barriers are often more stubborn than the technical ones.

Organizations with cultures that reward experimentation, tolerate productive failure, and empower individuals to try new approaches adapt to agentic AI faster. Organizations with cultures that punish mistakes, concentrate decision-making authority, and resist process changes struggle even when their technology investments are strong.

Building cultural readiness means creating psychological safety around AI adoption. People need to know that struggling with new tools is normal, that making mistakes while learning is acceptable, and that their value to the organization is not defined by tasks that agents can now handle. It means celebrating the people who find effective ways to work with agents and making early adopters into ambassadors rather than outliers.

The Opportunity Frame

Beneath the anxiety about displacement, there is a genuine opportunity that organizations should not understate. When agents handle the high-volume, repetitive, data-intensive work that consumes much of the average knowledge worker's day, people are freed to spend more time on the work that drew them to their careers in the first place: creative problem-solving, relationship building, strategic thinking, and the kind of judgment that comes from experience and empathy.

This is not aspirational rhetoric. Organizations that have deployed agents effectively report that employees spend less time on administrative tasks and more time on customer engagement, innovation, and cross-functional collaboration. The organizations that frame the transition as an opportunity to do more meaningful work, and follow through on that promise, see higher adoption and lower attrition than those that frame it purely as an efficiency play.

The promise must be genuine. If agents free people from routine work only to have that time consumed by more routine work or by layoffs, the trust deficit will undermine not just current deployments but future ones. The opportunity frame only works if the organization commits to reinvesting the freed capacity in ways that are visible and valuable to the people doing the work.

What It Takes: Workforce Readiness

This article maps to the workforce readiness dimension of the Agentic AI Readiness Assessment. Workforce readiness is the dimension organizations underestimate most, and it is the one that determines whether every other investment delivers its intended value.

Here is what readiness requires in practice:

Assess your AI literacy baseline honestly. Not whether you have training programs, but whether your people can work effectively with AI tools in their daily jobs. The gap between access and capability is where most organizations are stuck. If only 12 percent of your workforce uses AI daily despite having enterprise-wide access, you have a literacy problem, not a technology problem.

Plan for role evolution, not just role elimination. Map how each role in your organization will change as agents take on more tasks. Identify the new skills required, the tasks that will be redistributed, and the new roles that need to be created. Revisit this mapping regularly as agent capabilities and deployment scope change.

Invest in leadership readiness. Your managers will be managing hybrid human-agent teams. Most have no experience doing this. Leadership development programs need to include practical training on directing work across human and agent resources, managing the emotional dynamics of workforce transformation, and making decisions under ambiguity about how quickly to expand agent autonomy.

Build change management as a core capability, not a project. The agentic transition is not a change event with a start and end date. It is an ongoing evolution requiring continuous communication, iterative training, feedback mechanisms, and visible leadership engagement sustained over years, not months.

Design new career pathways. If agents are taking on entry-level tasks, you need new models for how people enter your organization, build skills, and advance. The apprenticeship model that works when juniors learn by doing routine tasks needs to be rethought when agents handle that routine work.

Measure adoption, not just deployment. The metric that matters is not how many agents you have deployed. It is how effectively your people work with them. Track daily active usage, time-to-competency for new agent tools, employee satisfaction with agent-assisted workflows, and the quality of outcomes produced by hybrid human-agent teams.

Up Next

In Part 10, we will turn to navigating the vendor landscape. With the readiness dimensions now mapped, from strategy and technology to data, governance, and people, the question becomes how to evaluate the vendors and platforms that will power your agentic enterprise. We will cover evaluation criteria, proof-of-concept design, reference architecture, and how to avoid the most common vendor traps.

---

Governing Systems That Act

In Part 7, we established that data readiness is the most common barrier to agentic AI deployment. But even with clean, accessible, well-governed data, organizations face a different category of challenge: how do you govern systems that make autonomous decisions and take action on your behalf?

This is not a theoretical concern. Nearly three-quarters of organizations plan to deploy agentic AI within two years, but only 21 percent report having a mature governance model for those agents. Gartner projects that by the end of 2026, more than 1,000 legal claims for harm caused by AI agents will be filed against enterprises due to insufficient guardrails. The governance gap between deployment speed and governance readiness is the single largest source of organizational risk in the agentic transition.

Governance for AI agents is not the same as governance for AI tools. When you deploy a copilot or a predictive model, a human reviews the output before acting on it. The human remains the decision-maker, and existing governance frameworks, designed around human accountability, still apply. When you deploy an agent that can evaluate conditions, choose between approaches, and take action autonomously, the governance model needs to change. The agent is no longer advising a decision. It is making one.

Governance by Design, Not by Afterthought

The most expensive governance mistake organizations make is treating it as a layer added after the system is built. Governance bolted on after deployment is always more fragile, more expensive, and less effective than governance designed into the system from the start.

Governance by design means that accountability, auditability, and control mechanisms are architectural requirements, not compliance add-ons. It means that before an agent is deployed, the organization has answered several questions: What decisions is this agent authorized to make? Under what conditions must it escalate to a human? What data can it access, and what actions can it take? How will its decisions be logged and auditable? Who is accountable when the agent makes a mistake?

These are not questions for the legal team to answer after the engineering team finishes building. They are design constraints that shape how the agent is built, what capabilities it has, and how it operates in production. Organizations that treat governance as a design input consistently report faster time to production deployment, because they avoid the costly cycle of building, discovering governance gaps, and rebuilding.

Decision Authority Frameworks

The core governance question for any agentic deployment is: what can the agent decide on its own, and what requires human involvement? The answer should not be binary. It should be a spectrum calibrated to risk, impact, and reversibility.

The emerging best practice is a three-tier decision authority model. The first tier covers fully autonomous decisions: low-risk, high-volume, reversible actions where the agent has clear authority and the cost of human review exceeds the cost of occasional errors. Routing a customer inquiry to the right team, categorizing an expense report, or updating a CRM record after a call are examples. The agent acts, and the action is logged for post-hoc review.

The second tier covers human-on-the-loop decisions: moderate-risk actions where the agent proceeds but a human reviews the results within a defined window. Approving a standard purchase order under a set threshold, drafting a customer communication for review before sending, or recommending a candidate for an interview are examples. The agent does the work, but a human validates before or shortly after the outcome takes effect.

The third tier covers human-in-the-lead decisions, building on the concept we introduced in Part 5. These are high-impact, difficult-to-reverse, or regulated decisions where the agent prepares the analysis and recommendation but a human makes the final call. Approving a large contract, making a hiring decision, or escalating a compliance issue are examples. The agent adds value by gathering information, synthesizing options, and presenting a recommendation, but the human retains decision authority.

The boundaries between tiers should not be static. As agents demonstrate reliability in a given domain, the boundaries can shift: what starts as a tier-two decision may migrate to tier one as the organization builds confidence. What matters is that the boundaries are explicit, documented, and enforced by the system rather than dependent on informal norms.

Escalation Protocols and Exception Handling

Knowing when to escalate is as important as knowing what to decide. Every agent operating in production will encounter situations outside its designed operating parameters: novel conditions, conflicting data, edge cases that do not match any pattern in its training. How the agent handles these moments determines whether the system is trustworthy or dangerous.

Effective escalation protocols require several elements. First, agents need well-defined trigger conditions: specific thresholds, confidence levels, or scenario types that activate escalation. If an agent's internal confidence score falls below a defined threshold, the action should be blocked and routed for human review. Second, escalation needs to be informative. When an agent escalates, it should provide the human with curated context: what it was trying to do, what information it gathered, why it is uncertain, and what options it considered. Dumping raw data on a human reviewer defeats the purpose.

Third, escalation paths need to be tested. Organizations deploying orchestrated agent systems report that escalation infrastructure takes significant design effort, and the organizations that skip it consistently find themselves building it retroactively after incidents they could not diagnose. As we discussed in Part 5, the observability infrastructure for multi-agent systems is not optional. It is the operational backbone that makes escalation work.

Auditability and Explainability

In regulated industries, the ability to explain why an agent took a particular action is not a nice-to-have. It is a legal requirement. And even in unregulated contexts, auditability is essential for debugging, performance improvement, and stakeholder trust.

Auditability for agentic systems requires an immutable audit trail that captures what the agent did, what data it used, what alternatives it considered, and why it chose the action it took. Every autonomous action should be logged with a unique agent identity, timestamps, the data inputs that informed the decision, and the outcome. This creates the chain of accountability that allows organizations to reconstruct decisions after the fact.

Explainability is the harder problem. Agentic systems built on large language models do not reason through decisions in ways that map cleanly to traditional decision trees or rule-based logic. The agent's reasoning process is probabilistic, and explaining why it chose one action over another often requires interpretive layers that translate model behavior into human-understandable rationale. This is an active area of development, and organizations should not wait for perfect explainability before deploying agents. But they should invest in the best available approaches and be transparent with stakeholders about the current limits.

The practical minimum is decision tracing: the ability to reconstruct the chain of inputs, retrievals, and intermediate steps that led to a given output. This may not explain the model's internal reasoning in full, but it provides the operational visibility needed for governance, debugging, and compliance.

Compliance Across Industries

Different industries face different governance requirements, and the regulatory landscape for agentic AI is evolving rapidly.

Financial services faces the most immediate pressure. AI systems used for credit scoring, creditworthiness assessment, and insurance risk pricing are classified as high-risk under the EU AI Act, which becomes fully enforceable in August 2026. These systems require documented risk management processes, high-quality training data, human oversight mechanisms, transparency, and robustness controls. Penalties reach up to 35 million euros or seven percent of global annual turnover. In the United States, existing regulations around fair lending, anti-discrimination, and fiduciary duty apply to AI-driven decisions even without AI-specific legislation.

Healthcare imposes strict requirements around patient data privacy (HIPAA in the US, GDPR in Europe) and clinical decision-making where errors have direct consequences for patient safety. Other regulated industries, including insurance, legal services, and government, face their own combinations of data privacy, professional liability, and sector-specific requirements. The common thread is that governance frameworks for agentic AI must layer on top of existing industry compliance requirements, not replace them.

Security for Autonomous Systems

Security takes on a different character when the systems being secured can take autonomous action. A compromised AI agent is not like a compromised database. A compromised database leaks data. A compromised agent can take actions: send communications, modify records, initiate transactions, and interact with other systems, all while appearing to operate normally.

The security challenge is significant. Forty-eight percent of cybersecurity professionals identify agentic AI and autonomous systems as the most dangerous emerging attack vector. Prompt injection, where malicious instructions are embedded in data the agent processes, moved from academic research to recurring production incidents in 2025. Identity spoofing, where attackers impersonate agents or hijack their credentials, creates risk that propagates across every system the agent can access.

Only 14.4 percent of enterprises obtain full security and IT approval before deploying AI agents. This gap between deployment speed and security readiness mirrors the governance gap and compounds it. Organizations should treat AI agents as a new class of identity requiring their own security protocols: unique credentials, least-privilege access, behavioral monitoring, and anomaly detection designed for agent-specific activity patterns.

The intersection of security and governance is also where shadow AI becomes a critical risk. When 57 percent of employees use personal AI accounts for work tasks, they are creating unmonitored, ungoverned agent interactions that bypass every security and compliance control the organization has built. Governance frameworks must address not just the agents you deploy but the agents your people are already using.

Building Trust with Stakeholders

Governance frameworks exist on paper. Trust exists in practice. The most technically complete governance framework will fail if employees do not trust the agents they work alongside, if customers do not trust the agents that serve them, or if regulators do not trust the organization's ability to control what its agents do.

Building trust with employees starts with transparency and involvement. People who understand what agents can and cannot do, who participate in defining the boundaries of agent authority, and who see that escalation works when it should are far more likely to embrace agent-augmented workflows. As we discussed in Part 5, organizations with well-designed escalation paths achieve three times higher adoption rates than deployments that attempt full automation.

Building trust with customers requires clear disclosure: knowing when they are interacting with an agent, what it can and cannot do, and how to reach a human. The EU AI Act's transparency provisions formalize what should already be good practice.

Building trust with regulators requires demonstrable governance: documented frameworks, audit trails, incident response procedures, and evidence of ongoing monitoring. Proactive engagement with regulatory expectations positions organizations as responsible actors in a space where regulators are still developing their approaches.

The Guardrails Spectrum

Not every agent needs the same level of governance. A customer FAQ agent operating with read-only data access and a mandate to answer questions requires different guardrails than a procurement agent authorized to commit budget or a compliance agent reviewing regulatory filings. Over-governing low-risk agents wastes resources and slows deployment. Under-governing high-risk agents creates liability and erodes trust.

The guardrails spectrum runs from tight constraints (narrow decision authority, mandatory human approval for most actions, restricted data access) to broad operational parameters (wide decision latitude, human oversight focused on outcomes rather than individual actions, extensive data access). Where an agent falls on this spectrum should be a function of the risk profile of its domain, the reversibility of its actions, the maturity of the organization's governance infrastructure, and the regulatory environment it operates in.

The principle is proportionality: governance effort should scale with risk. Even low-risk agents need logging, identity management, and defined operating boundaries. But the depth and rigor of governance should match the potential impact, not apply a one-size-fits-all framework that makes every deployment equally burdensome.

What It Takes: Governance and Risk Management

This article maps to the governance and risk management dimension of the Agentic AI Readiness Assessment, the dimension that determines whether your organization can deploy agents responsibly and sustain that deployment as scope and autonomy increase.

Here is what readiness requires in practice:

Establish decision authority frameworks before you deploy. Define the three tiers of decision authority for each agent use case. Be explicit about what is fully autonomous, what requires human review, and what requires human decision-making. Document these boundaries and build enforcement mechanisms into the agent architecture.

Build auditability into the architecture from day one. Every agent action should be logged with sufficient detail to reconstruct the decision chain. Do not plan to add audit trails later. Design them in. If you operate in a regulated industry, your audit infrastructure needs to meet the evidentiary standards that regulators expect.

Design escalation protocols and test them. Escalation is not just a fallback. It is a core operational capability. Define trigger conditions, design informative handoff experiences, and test escalation paths under realistic conditions before they are needed in production.

Assess your regulatory exposure. Map your planned agent deployments against the regulatory requirements of every jurisdiction and industry you operate in. The EU AI Act's August 2026 enforcement date is the most visible deadline, but it is not the only one. Existing industry regulations apply to AI-driven decisions even where AI-specific legislation does not exist.

Address shadow AI as a governance priority. The agents you deploy are not the only agents your organization uses. Build policies and technical controls that address the AI tools and agents your employees are already using outside formal IT channels.

Treat governance as ongoing, not one-time. Agent capabilities change. Regulatory requirements evolve. Organizational risk tolerance shifts. Governance frameworks need regular review and adaptation, not a single design exercise at launch. The organizations that build governance as a continuous discipline, rather than a project with an end date, will be the ones that scale agentic deployments with confidence.

For a deeper exploration of governance design principles for AI systems, readers may want to consult the Arion Research Governance-by-Design series and report, which examines these themes in detail across multiple enterprise contexts.

Up Next

In Part 9, we will turn to the human side of the agentic enterprise: workforce, roles, and change. What happens to work and workers when agents take on tasks? We will cover emerging roles, skills evolution, hybrid human-agent teams, and the change management challenge that organizations underestimate most. People readiness is the dimension that determines whether everything else in this series translates from strategy to practice.

---

The Uncomfortable Truth About Data

In Part 6, we examined the platform decision: build, buy, assemble, or extend. But even the best platform strategy will stall if the data underneath it is not ready. And for most organizations, it is not.

A 2026 report from Cloudera and Harvard Business Review Analytic Services found that only seven percent of enterprises consider their data completely ready for AI. More than a quarter say their data is not very or not at all ready. Meanwhile, a separate Cloudera study found that nearly 80 percent of enterprises say AI is held back by data access challenges. These are not fringe concerns. They describe the norm.

This is the most common and most underestimated barrier to agentic AI deployment. Not model quality. Not budget. Not executive sponsorship. Data. When half of enterprise leaders still cite data quality and retrieval as their biggest challenge in agentic AI, the message is clear: the data foundation is where ambition meets reality.

Why Agents Amplify Data Problems

Traditional software tolerates imperfect data because humans compensate. A sales rep glances at a CRM record, recognizes that the phone number is outdated, and calls the number they already have in their contacts. A finance analyst opens a spreadsheet, spots an anomalous figure, and checks the source system before including it in their report. Human judgment papers over data gaps dozens of times a day, so routinely that most organizations do not realize how much of their operation depends on it.

Agents do not compensate this way. An agent retrieving customer data will use what it finds. If the data is incomplete, the agent's output will be incomplete. If the data is inconsistent across systems, the agent may produce contradictory results depending on which source it accesses first. If the data is stale, the agent will act on outdated information with the same confidence it would apply to current information.

This is why data quality rose sharply as a reported barrier to AI deployment, climbing from 37 percent in early 2025 to 65 percent by the end of the year as organizations moved from simple AI experiments to agent-to-agent workflows with broader system integrations. The more you ask agents to do, the more your data problems become visible. Agents do not hide data deficiencies. They expose them.

The Five Dimensions of Data Readiness

Data readiness for agentic AI is not a single problem. It spans five interconnected dimensions, and weakness in any one of them constrains the whole system.

Data quality is the foundation of everything else. Completeness, accuracy, consistency, and timeliness all matter. When 62 percent of organizations say it is challenging to measure and monitor AI data quality, and 62 percent say it is challenging to prepare data to be AI-ready, the scope of the problem becomes apparent. Agents need data they can trust, and trust requires that the data is correct, current, and consistent across the systems where it lives.

The practical challenge is that most enterprises have never needed their data to be this clean. Human-mediated processes tolerated ambiguity and inconsistency because people could interpret and compensate. Agent-mediated processes cannot. The standard for data quality in an agentic enterprise is materially higher than what most organizations have maintained, and closing that gap requires sustained investment, not a one-time cleanup.

Data accessibility is about whether agents can reach the data they need across your enterprise systems. Sixty-five percent of organizations say breaking down AI data silos is a significant challenge, and that number has been climbing year over year. The problem is not that the data does not exist. It is that it lives in disconnected systems with incompatible formats, inconsistent schemas, and limited API access.

Agents operating in orchestrated workflows, as we discussed in Part 5, need to access data across multiple systems in the course of a single task. A procurement agent evaluating a vendor might need data from the ERP, the contract management system, the supplier risk database, and the accounts payable history. If any of those systems lacks the API access, data formats, or response times that agents require, the workflow hits a wall.

Data architecture determines whether your data infrastructure can support agent-scale access patterns. The shift from human-centric to agent-centric data access changes the architecture requirements. Humans access data in interactive sessions, one query at a time, at human speed. Agents access data programmatically, at machine speed, often in parallel, and at volumes that can overwhelm systems designed for human usage patterns.

Organizations are responding with two architectural approaches. Data fabric provides a unified, virtualized access layer across disparate sources, making data accessible without physically consolidating it. Data mesh distributes data ownership to domain teams while maintaining interoperability standards. Research shows that 84 percent of organizations are evaluating or implementing one or both of these approaches. The most sophisticated deployments combine them: data fabric for unified access and governance infrastructure, data mesh for distributed ownership and domain expertise.

Knowledge management extends beyond structured data to encompass the unstructured information and institutional knowledge that agents need to operate effectively. Process documentation, policy manuals, customer communication histories, internal wikis, decision precedents: this is the knowledge that experienced employees carry in their heads and that agents need in explicit, retrievable form.

Retrieval-Augmented Generation, or RAG, has become the primary pattern for giving agents access to enterprise knowledge. RAG allows agents to retrieve relevant information from your knowledge repositories and use it to inform their responses and decisions. By 2026, RAG has moved from experimental to production-critical, with enterprise platforms like Workday and ServiceNow integrating RAG capabilities directly into their agent offerings. The evolution continues with approaches like GraphRAG, which builds entity-relationship graphs over document collections, enabling agents to answer questions that require synthesizing information across multiple sources rather than retrieving individual facts.

But RAG is not a magic solution. Retrieval precision failures, particularly in multi-hop reasoning where agents need to chain information across several documents, remain a real challenge. And the security implications are significant: improperly governed RAG pipelines can expose sensitive information to agents and users who should not have access to it.

Context management is the dimension that ties the others together. Giving agents the right information at the right time, in the right amount, is an engineering challenge that grows with the complexity of your agent deployments.

Within any workflow, an agent maintains session memory: what it has done, what it has retrieved, what decisions it has made. Across workflows, agents may need access to longer-term memory that captures patterns, preferences, and institutional knowledge accumulated over time. In 2026, memory has become a first-class architectural component for agent systems, with its own research literature, benchmark suites, and a growing ecosystem of specialized tools.

The tension is between comprehensiveness and quality. Even as context windows expand past one million tokens, context rot, where the quality of an agent's reasoning degrades as more information is loaded into its working memory, remains an unsolved problem. The most effective approaches use layered context architectures that combine system context, session context, curated memory, and on-demand retrieval, applying compression and relevance scoring to ensure agents work with high-signal information rather than drowning in data.

Data Governance for Agentic Access

Data governance takes on new urgency when agents, not just people, are accessing your data. The question shifts from "who can see this data?" to "which agent can access which data, under what conditions, and what can it do with what it finds?"

This is an area where most organizations are behind. Only 11 percent have implemented governance frameworks specifically for AI agents, despite rapid deployment growth. The gap between deployment speed and governance readiness creates real risk: agents accessing data they should not, making decisions based on information outside their authorized scope, or surfacing sensitive data in contexts where it should not appear.

Effective data governance for agentic AI requires several capabilities. Role-based access control needs to extend to agent identities, with granular permissions that specify which data repositories each agent can query, which fields it can modify, and which actions it can execute autonomously. Data lineage tracking becomes essential so you can trace what data an agent used to reach a conclusion. And real-time monitoring must be able to flag when agents access data outside their expected patterns, whether due to configuration errors, workflow changes, or potential security issues.

As we covered in Part 6, the governance question also intersects with the lock-in question. If your agents accumulate context and operational knowledge within a vendor's proprietary data layer, that knowledge becomes difficult to migrate. Data governance for agentic AI should include explicit policies about where agent-generated knowledge lives, who owns it, and how it can be exported.

Real-Time vs. Batch: Matching Data Freshness to Agent Needs

Not every agent needs real-time data, and not every data source can provide it. One of the practical architecture decisions in agentic deployment is matching data freshness requirements to the actual needs of each agent workflow.

Some workflows demand live data. A supply chain agent monitoring shipment status needs current information to be useful. A customer service agent looking up an account balance needs the number as of right now, not as of last night's batch update. A security monitoring agent needs real-time event streams to detect and respond to threats.

Other workflows work well with periodically refreshed data. A financial reporting agent assembling a monthly close package can work with data that is a few hours old. A market analysis agent does not need sub-second latency on competitor pricing data. An HR agent processing benefits enrollment can work with daily snapshots of employee records.

The cost and complexity difference between real-time and batch data access is substantial. Real-time data pipelines require event streaming infrastructure, change data capture, and systems designed for low-latency queries under agent-scale load. Batch pipelines are simpler, cheaper, and more forgiving of source system limitations.

The practical approach is to categorize your agent workflows by data freshness requirements and design your data infrastructure accordingly. Over-engineering for real-time when batch would suffice wastes resources and adds unnecessary complexity. Under-engineering when agents need current data produces unreliable results and erodes trust.

What It Takes: Data Readiness

This article maps to the data readiness dimension of the Agentic AI Readiness Assessment. Data readiness is where honest self-assessment matters most, because data problems are often invisible until agents expose them.

Here is what readiness requires in practice:

Audit your data quality with agent use cases in mind. The data quality bar for agentic AI is higher than for human-mediated processes. Assess completeness, accuracy, consistency, and timeliness across the systems your agents will need to access. Pay special attention to data that crosses system boundaries, because inconsistencies between systems are exactly where agents will produce unreliable results.

Map your data accessibility landscape. Which systems have APIs that can support agent-scale access? Which have rate limits, latency constraints, or format limitations that will constrain agent workflows? Which critical data sources lack programmatic access entirely? These gaps become your integration investment priorities.

Assess your knowledge management maturity. How much of your institutional knowledge lives in people's heads versus in retrievable, structured repositories? How current is your documentation? How well-organized is your unstructured content? Agents cannot leverage knowledge they cannot find, and most organizations have significant gaps between what their people know and what their systems can provide.

Design your data governance for agent access. Extend your governance frameworks to cover agent identities, agent-specific permissions, and data lineage for agent-driven decisions. If you do not have data governance frameworks in place at all, building them should be a prerequisite to production agent deployment, not a follow-up project.

Be deliberate about data architecture investment. Whether you pursue data fabric, data mesh, or a hybrid approach, your data architecture needs to evolve to support the access patterns, volumes, and governance requirements that agentic systems create. This is a multi-year investment, not a quick fix, and it should start before your agent deployments outrun your data infrastructure's capacity.

The organizations that treat data readiness as a serious, ongoing discipline rather than a box to check will be the ones whose agentic initiatives reach production and deliver sustained value. The 93 percent who acknowledge their data is not fully ready are not facing a technology problem. They are facing an investment and prioritization problem. The data work is unglamorous compared to building agents, but it is the work that determines whether those agents succeed or fail.

Up Next

In Part 8, we will turn to governance, trust, and guardrails. How do you govern systems that make autonomous decisions? We will cover accountability frameworks, auditability requirements, compliance considerations, and the design principles that build trust with employees, customers, and regulators. This is where the governance-by-design principle becomes operational reality.

---

The Platform Question

In Part 5, we established why orchestration is the critical coordination layer for multi-agent systems. The natural follow-up question is: where does that orchestration capability come from? More broadly, how should you acquire and compose the technology capabilities you need to build an agentic enterprise?

This is the platform decision, and it is more complex than the traditional build-versus-buy question because the agentic technology landscape is evolving faster than enterprise procurement cycles. The right platform strategy depends on where you are today, where you need to be, and how much flexibility you need to preserve along the way.

With the AI agents market projected to reach $52.6 billion by 2030 and Gartner forecasting that 40 percent of enterprise applications will embed task-specific agents by the end of 2026, this is not a decision you can defer indefinitely. But it is one you should make deliberately, because the choices you make now will shape your options for years.

Four Platform Strategies

Organizations approaching the agentic platform landscape have four primary strategies. Each has distinct advantages, limitations, and risk profiles.

Extend what you have. This is the lowest-friction starting point, and for many organizations it is the right first move. Every major enterprise platform vendor now ships agentic capabilities. Salesforce Agentforce, with over 8,000 customers, embeds agents across CRM workflows. Microsoft has added Agent 365, a centralized control plane for agent registry, access controls, and cross-ecosystem visibility. ServiceNow's AI Agent Orchestrator coordinates agents across ITSM, HR, and customer service, earning the top position in Gartner's 2025 Critical Capabilities for AI Agents. Workday launched Illuminate agents for HR case management and financial close. SAP offers Joule, and IBM Watsonx Orchestrate ships pre-integrated with more than 80 enterprise applications.

The advantage is speed to value. Your teams already know the platform. Your data is already there. Integration with existing workflows is straightforward. The limitation is scope. Agents built within a single vendor's ecosystem work well for workflows that live within that ecosystem. They struggle when work crosses vendor boundaries, which, as we discussed in Part 5, is where the most valuable orchestration happens.

Buy a purpose-built agent platform. Pure-play agent platforms offer capabilities designed specifically for building, deploying, and managing agents. Some target specific domains: Aisera and Kore.ai focus on employee support and contact center use cases. Others offer broader orchestration capabilities. The market is consolidating rapidly; ServiceNow's acquisition of Moveworks in March 2025 validated the pure-play model while also absorbing a major independent player.

Purpose-built platforms make sense when your agent workflows span multiple enterprise systems and no single vendor covers the full scope, when you need model-agnostic flexibility to swap between AI providers, or when your incumbent vendor's agent capabilities lag in the specific domain where you need them. The limitation is that you are adding another platform to your stack, with the associated integration, governance, and vendor management overhead.

Build your own. Building directly on foundation model APIs from providers like OpenAI, Anthropic, or Google gives you maximum control over architecture, behavior, and integration. Open frameworks like LangGraph and CrewAI provide building blocks that reduce the engineering effort compared to starting from scratch.

But building your own remains the most resource-intensive path. Production-grade agent systems typically require six to twelve months of development, and the ongoing maintenance burden is significant. Custom development is justified when the use case is a genuine competitive differentiator, when deep domain-specific knowledge cannot be captured by commercial platforms, or when no existing offering covers the workflow you need to automate. For most organizations, building should be the exception, not the default.

Assemble from best-of-breed components. This is the approach emerging as the practical default for enterprises with complex requirements. Over half of enterprises now prefer hybrid stacks that layer open protocols on top of vendor-managed orchestration. The pattern: use your ERP or CRM vendor for domain-specific agents, an open framework for custom orchestration logic, and open protocols for the connective tissue.

The assemble model offers the best balance of speed, flexibility, and control. You get the domain expertise and operational maturity of established vendors where it matters, the customization of open frameworks where you need it, and the interoperability of open standards to prevent the whole architecture from calcifying around a single provider. The tradeoff is complexity. An assembled stack requires more architectural skill to design, more governance discipline to manage, and more integration effort to maintain than a single-vendor approach.

The Lock-in Problem Is Different This Time

Vendor lock-in is a familiar concern in enterprise technology. But agentic AI lock-in is more severe than traditional software lock-in because it compounds across multiple layers simultaneously.

With traditional software, lock-in is primarily about data formats and business logic. Migration is expensive but conceptually straightforward: extract data, rebuild logic, retrain users. With agentic systems, lock-in operates across at least four layers: the AI model (which shapes how agents reason), the orchestration logic (which defines how agents coordinate), the memory and context layer (which stores what agents have learned from operating in your environment), and the data connections (which determine what agents can access).

The critical insight is about accumulated operational context. If months of agent memory, workflow conventions, escalation patterns, and institutional knowledge live inside a vendor's proprietary layer, switching costs go far beyond code migration. Research suggests average switching costs exceed $315,000 per project, and only six percent of enterprises can change vendors without significant disruption.

This does not mean you should avoid platforms. It means you should make lock-in risk a first-order evaluation criterion, not an afterthought. Ask: where does the accumulated context live? Can it be exported? Are the orchestration patterns portable? Can you swap model providers without rewriting your agent logic?

Open Standards and the Interoperability Imperative

The most effective lock-in mitigation strategy is adoption of open standards, and the agentic AI ecosystem is converging around two protocols that enterprise buyers should understand.

Model Context Protocol (MCP), introduced by Anthropic in late 2024, standardizes how agents connect to tools and data sources. Think of it as a universal adapter: rather than building custom integrations for every system an agent needs to access, you build one MCP connection and any MCP-compatible agent can use it. MCP now has over 97 million SDK downloads and more than 10,000 enterprise server implementations.

Agent2Agent (A2A) protocol, introduced by Google in April 2025, standardizes how agents communicate with each other across platforms. While MCP handles the agent-to-tool relationship, A2A handles the agent-to-agent relationship, enabling agents built on different platforms to discover each other's capabilities, negotiate collaboration, and coordinate on shared tasks.

Both protocols are now governed by the Linux Foundation's Agentic AI Foundation, co-founded by OpenAI, Anthropic, Google, Microsoft, AWS, and Block. This governance structure matters because it signals that these are not single-vendor initiatives but industry-wide standards.

For enterprise buyers, the practical implication is clear: require MCP and A2A compatibility as baseline criteria in vendor evaluations. Eighty-seven percent of IT leaders now prioritize interoperability in their agentic AI purchasing decisions. Platforms that support these standards give you the flexibility to evolve your architecture as the market matures. Platforms that do not are asking you to bet that their proprietary approach will win, a bet that gets more expensive to reverse over time.

A Decision Framework for Platform Strategy

Rather than prescribing a single approach, here is a framework for matching your platform strategy to your organizational context.

Start with extend if your highest-value agent use cases live primarily within one vendor's ecosystem, your organization has limited AI engineering capacity, and speed to initial deployment matters more than architectural flexibility. This gets you running quickly with manageable risk.

Move to assemble when your agent workflows span multiple systems and vendors, when you need model-agnostic flexibility, or when the extend approach has reached its limits for your cross-functional use cases. The assemble model is where most large enterprises end up as their agentic ambitions mature.

Choose build selectively for use cases where the agent logic itself is a competitive differentiator, where deep domain expertise cannot be replicated by commercial platforms, or where you need capabilities that simply do not exist in the market yet. Ring-fence custom development to genuinely unique requirements and use commercial platforms for everything else.

Consider pure-play buy when you need specialized capabilities in a specific domain that your incumbent vendors do not cover, or when a purpose-built platform offers significantly better orchestration for your primary use cases. But evaluate carefully whether the pure-play vendor will remain independent or get acquired, and ensure you have contractual protections around data portability and API continuity.

Most organizations will use more than one strategy simultaneously. Your CRM agents might run on Salesforce Agentforce (extend), your cross-functional orchestration might use an open framework (assemble), and your most differentiated workflow might be custom-built (build). The key principle is that your platform strategy should be as composable as the architecture it supports. No single choice needs to be permanent, and the best strategies preserve optionality while delivering value today.

What It Takes: Technical Infrastructure and Strategic Alignment

This article maps to two readiness dimensions: technical infrastructure and strategic alignment. Platform decisions sit at the intersection of what your technology can support and what your business needs to achieve.

Here is what readiness requires in practice:

Evaluate your current stack honestly. Before evaluating new platforms, understand what you already have. What agentic capabilities are your existing vendors shipping? How mature are they? What gaps do they leave? Many organizations discover that their current vendors cover 60 to 70 percent of their initial use cases, which changes the calculus significantly compared to starting from scratch.

Define your business outcomes before you evaluate platforms. The most common platform decision mistake is starting with technology capabilities rather than business requirements. Know which workflows you want to make agentic, what success looks like for each one, and what constraints (regulatory, budgetary, organizational) shape your options. Build your evaluation criteria before you start taking demos.

Assess your integration architecture. Platform decisions have downstream implications for every system agents need to touch. If your integration layer is fragile, adding an agent platform on top will amplify the fragility. If your integration layer is robust and standards-based, you have more platform options and more flexibility to evolve.

Factor in total cost of ownership, not just acquisition cost. Agent platforms have cost profiles that differ from traditional software. Token consumption, API call volumes, compute scaling, and ongoing training and customization all contribute to TCO. A platform with a low entry cost but high per-transaction pricing may be more expensive at scale than one with higher upfront investment but more predictable economics.

Plan for evolution, not just initial deployment. The agentic platform landscape will look different in 18 months. Your platform strategy should accommodate that change rather than betting everything on today's market configuration. This is the strongest argument for composability and open standards: they give you the architectural flexibility to adapt as both technology and your organization's needs evolve.

Up Next

In Part 7, we will turn to the data foundation. Agents are only as good as the data they can access and reason over, and data readiness is where most agentic initiatives stall. We will cover what data readiness means in the context of agentic AI, why it is the most common blocker to production deployment, and what organizations need to build to give their agents the information foundation they require.

---

When One Agent Is Not Enough

In Part 4, we mapped where agents create real business value: finance, HR, supply chain, customer operations, sales, and IT. Each of those use cases can start with a single agent performing a defined task. But as organizations move from initial deployment to broader adoption, they hit a ceiling.

The ceiling is not about what individual agents can do. It is about what happens when the work requires coordination across agents, systems, and people. A customer service agent that can resolve inquiries is valuable. But a customer operation that coordinates a triage agent, a knowledge retrieval agent, a response drafting agent, and a compliance checking agent, all working in concert, is transformative. That coordination layer is orchestration, and it is quickly becoming the infrastructure that separates organizations getting isolated value from AI from those building compounding operational advantage.

What Orchestration Means in Business Terms

Orchestration is not a new concept. Businesses have always coordinated work across people, teams, and systems. What is new is the speed, complexity, and adaptive capacity that agentic orchestration enables.

In practical terms, orchestration is the layer that decides which agent does what, in what order, with what information, and what happens when something goes wrong. It handles routing (sending the right task to the right agent), sequencing (ensuring steps happen in the correct order), resource allocation (managing compute and access), exception handling (knowing when to escalate), and state management (keeping track of where things stand across a multi-step workflow).

Think of it as the difference between having a team of specialists and having an effective operating model that makes those specialists productive together. The specialists are your agents. The operating model is orchestration.

How Orchestration Differs from Traditional Automation

If your organization has invested in workflow automation or RPA, you might reasonably ask: how is this different? The distinction matters because it determines what you can expect from orchestrated agent systems and what infrastructure they require.

Traditional workflow automation executes predefined paths. A trigger fires, and the system follows a scripted sequence of steps. If conditions deviate from the script, the automation either fails or routes to a human. RPA operates similarly, automating structured interactions with systems through fixed, rule-based scripts. Both are powerful within their design parameters, and both break when confronted with ambiguity or novel conditions.

Agentic orchestration is adaptive. Orchestrated agents can evaluate conditions, choose between approaches, handle exceptions that would break scripted automation, and adjust their strategy based on intermediate results. The orchestration layer does not just route tasks through a fixed pipeline. It manages dynamic workflows where the path forward may change based on what agents discover along the way.

This does not mean traditional automation disappears. In most enterprises, agentic orchestration will sit alongside existing workflow tools, handling the complex, judgment-intensive work while RPA and workflow automation continue handling high-volume, fully deterministic processes. The practical question is where to draw the boundary, and that boundary will shift over time as agent capabilities improve.

Orchestration Patterns

Not all orchestration looks the same. Different business problems call for different coordination patterns, and understanding these patterns helps you match the right architecture to the right challenge.

Sequential orchestration is the simplest pattern. Agent A completes its work and passes the output to Agent B, which passes to Agent C. Think of document processing: one agent extracts data, another validates it against business rules, a third routes it for approval, and a fourth posts it to the system of record. This pipeline model works well when tasks have clear dependencies and a natural sequence.

Parallel orchestration is used when multiple agents can work simultaneously on independent subtasks. A market research workflow might dispatch one agent to analyze competitor pricing, another to assess customer sentiment, and a third to review regulatory changes, then aggregate the results into a unified brief. The value here is speed: work that would take days when done sequentially completes in hours or minutes.

Hierarchical orchestration introduces a supervisor agent that delegates work to specialist agents and synthesizes their outputs. This is the dominant pattern for complex decision-support workflows. A procurement evaluation, for example, might use a supervisor agent that assigns sub-tasks to agents specializing in vendor risk assessment, financial analysis, compliance verification, and technical evaluation. The supervisor coordinates the specialists, resolves conflicts between their recommendations, and produces a consolidated output for human decision-makers.

Event-driven orchestration activates agents in response to triggers rather than following a predetermined sequence. A supply chain monitoring system might have agents that activate when specific conditions arise: a logistics agent responds to shipment delays, a procurement agent responds to inventory thresholds, and a communication agent notifies affected customers. The orchestration layer manages the event routing and ensures agents do not work at cross-purposes.

In practice, production systems often combine patterns. A hierarchical system might use parallel execution within levels and event-driven triggers to initiate workflows. The point is not to pick one pattern but to understand which patterns suit which problems in your organization.

The Human-in-the-Lead Imperative

There is an important distinction between human-in-the-loop and human-in-the-lead. Human-in-the-loop positions the person as a checkpoint, a gate that approves or rejects agent actions at defined intervals. Human-in-the-lead positions the person as the director: setting objectives, defining constraints, adjusting strategy, and maintaining authority over the overall mission while agents handle execution. The difference matters because it shapes how you design orchestrated systems and what role people play as agent capabilities grow.

In a human-in-the-lead model, the human is not waiting to approve each step. They are setting the direction, defining the guardrails, monitoring outcomes, and intervening when the situation demands judgment that agents cannot provide. Agents operate with appropriate autonomy within those boundaries, escalating when they encounter conditions outside their operating parameters. But the human retains strategic authority over the work, not just veto power over individual decisions.

The most successful orchestrated deployments reflect this philosophy. They use tiered autonomy designs where agents handle routine execution independently while humans focus on goal-setting, exception strategy, and performance oversight. When escalation occurs, agents provide curated context and recommendations rather than dumping raw data and expecting the human to start from scratch.

Research from Deloitte's 2025 enterprise AI survey found that organizations with well-designed escalation paths achieved three times higher adoption rates than deployments that attempted full automation. The reason is trust. When people can see that they remain in control of direction and outcomes, and that the system knows its limits and hands off appropriately, they trust it with more routine execution. When the system operates as a black box, even successful autonomous decisions erode confidence over time.

Designing effective human-in-the-lead orchestration requires answering several questions: What decisions remain with the human, and what execution is delegated to agents? How do you give humans visibility into agent activity without overwhelming them with detail? What happens when a human changes direction mid-workflow? How do you capture human overrides as learning signals for future decisions? These are design choices that directly affect both the system's performance and the organization's willingness to expand its scope.

Observability: Knowing What Your Agents Are Doing and Why

One of the most underappreciated challenges in multi-agent orchestration is observability. When a single agent handles a single task, monitoring is straightforward. When multiple agents coordinate on complex workflows, making decisions, passing context, and adapting their approach, the question of "what is happening and why" becomes significantly harder to answer.

Enterprise orchestration requires several observability capabilities. Decision tracing means being able to reconstruct why an agent took a particular action, not just what it did. In regulated environments, this is not optional. Inter-agent communication tracking means understanding what information agents passed to each other and how that information influenced downstream decisions. Performance attribution means knowing which agent in a multi-agent workflow contributed to success or failure. And drift detection means identifying when an agent's behavior is changing over time in ways that may not be immediately visible.

This is not theoretical. Organizations deploying orchestrated agent systems in production report that observability infrastructure takes 30 to 40 percent of their total implementation effort. It is the operational backbone that makes multi-agent systems manageable at scale, and organizations that skip it in early deployments consistently find themselves building it retroactively when problems arise that they cannot diagnose.

The Emerging Infrastructure Landscape

The orchestration infrastructure landscape is evolving rapidly. Several categories of tools and standards are emerging to support multi-agent coordination in enterprise environments.

Enterprise agent platforms from vendors like Salesforce (Agentforce), Microsoft (Copilot Studio), IBM (Watsonx Orchestrate), and AWS (Bedrock Agents) offer managed orchestration for production workloads. These platforms provide built-in patterns for agent coordination, monitoring, and governance. They make sense for organizations that want to orchestrate agents within their existing vendor ecosystem without building custom infrastructure.

Open frameworks like LangGraph, CrewAI, and AutoGen provide developer-focused tools for building custom orchestration. These offer more flexibility but require more engineering investment. They make sense for organizations with specific orchestration requirements that platform offerings do not address or for those building differentiated capabilities where the orchestration logic itself is a competitive advantage.

Interoperability standards are the critical emerging layer. Google's Agent2Agent (A2A) protocol, announced in early 2025, targets cross-platform agent communication, enabling agents built on different platforms to coordinate. Anthropic's Model Context Protocol (MCP) provides a standardized connectivity layer for agents to access enterprise systems and data sources. These standards matter because enterprise orchestration inevitably spans multiple platforms and vendors. Without interoperability, orchestration hits a wall at organizational and vendor boundaries.

For most enterprises, the practical path forward involves a combination: leveraging platform orchestration for workflows within a vendor ecosystem while adopting interoperability standards for cross-platform coordination. The specific tooling choices matter less at this stage than the architectural decisions about how agents will communicate, share state, and coordinate across your environment.

Business Outcomes from Orchestrated Systems

The business case for orchestration builds on the single-agent value documented in Part 4, but with multiplier effects. Organizations deploying multi-agent architectures report 40 to 60 percent faster task completion on complex knowledge work compared to single-agent deployments. Cycle time reductions of 25 to 45 percent are common in multi-step processes. And output quality improves through built-in agent peer review, where one agent checks another's work before results move forward.

But the most significant advantage is not operational efficiency. It is adaptability. Orchestrated agent systems can be reconfigured for new business conditions without rebuilding from scratch. Adding a new agent to a workflow, adjusting escalation thresholds, or rebalancing workloads across agents can happen in days rather than the months required to modify traditional enterprise systems. In a business environment characterized by constant change, this operational agility is the real competitive edge.

Gartner projects that by 2028, 33 percent of enterprise software will incorporate agentic AI, up from less than one percent in 2024. The organizations that invest in orchestration infrastructure now will be positioned to capitalize on this shift as it accelerates. Those that treat agents as isolated point solutions will find themselves rebuilding their architecture under competitive pressure.

What It Takes: Technical Infrastructure

The readiness dimension at the heart of this article is technical infrastructure. Orchestration cannot function without a foundation of connectivity, interoperability, and computing resources.

Here is what technical infrastructure readiness requires in practice:

Assess your API readiness. Orchestrated agents need to access data and take action across your enterprise systems. If your critical systems lack APIs, have poorly documented APIs, or impose rate limits that cannot support agent-scale activity, orchestration will be constrained by those bottlenecks. Map which systems agents need to reach and evaluate whether those systems can support the interaction volume and response times that agents require.

Evaluate system interoperability. Can your systems exchange data in formats that agents can consume and produce? Are there integration gaps that currently require manual data transfer or custom point-to-point connections? Orchestration amplifies both the benefits and the costs of your integration architecture. Well-connected systems become more valuable. Poorly connected systems become bigger bottlenecks.

Plan for identity and access management at agent scale. Each agent needs appropriate access credentials, and those credentials need to follow least-privilege principles. When multiple agents coordinate, the access management complexity multiplies. Your IAM infrastructure needs to support agent-specific identities, scoped permissions, and audit trails that track which agent accessed what data and why.

Consider compute and cost implications. Multi-agent orchestration is token-intensive. Each agent consumes compute resources, and orchestrated workflows multiply the total resource consumption. Understanding the cost profile of orchestrated systems, including both the compute costs and the API costs for the systems agents interact with, is essential for sustainable deployment at scale.

Invest in shared state management. Agents coordinating on a workflow need access to shared context: what has happened so far, what decisions have been made, what information has been gathered. The infrastructure for managing this shared state, making it accessible to the agents that need it while keeping it secure and consistent, is a prerequisite for reliable multi-agent coordination.

If your organization has well-documented APIs across critical systems, proven integration patterns, mature identity and access management, and scalable computing infrastructure, you have the technical foundation for orchestrated agent deployment. If not, the gaps you identify become your infrastructure investment priorities, because orchestration will only be as strong as the weakest connection in the chain.

Up Next

In Part 6, we will tackle the platform decision: build, buy, assemble, or extend. With the orchestration requirements now clear, the next question is how to acquire and compose the technology capabilities you need. We will examine the vendor landscape, compare platform strategies, and provide a framework for making platform decisions that balance speed, flexibility, and long-term positioning.

---

From Frameworks to Outcomes

In Parts 1 through 3, we established the strategic case for the agentic enterprise, built a shared vocabulary, and introduced the Dual Maturity Framework for understanding where your organization stands. All necessary groundwork. But at some point, the practical question takes over: where do we start? Where are agents creating real, measurable business value today, not in demos or proofs of concept, but in production workflows that move important metrics?

This article answers that question. Organized by business function, it maps the landscape of high-value agent use cases and identifies the characteristics that make certain workflows better candidates for agentic AI than others. The goal is not to provide an exhaustive catalog. It is to help you see the opportunities in your own organization and prioritize where to focus first.

Finance and Accounting

Finance was one of the first functions to see meaningful agent deployments, and for good reason. Financial processes are data-intensive, rule-governed, high-volume, and error-sensitive. They involve significant coordination across systems. And the cost of getting them wrong, whether through processing delays, compliance gaps, or reconciliation errors, is quantifiable.

Invoice processing and accounts payable is where many organizations start. Agents can handle the full cycle: extracting data from invoices regardless of format, matching against purchase orders and receiving documents, coding to the general ledger, validating against procurement policies, routing for the appropriate approval, and posting to the ledger. Current deployments report accuracy rates above 99% for data extraction and dramatic reductions in cycle time. What previously required a team managing exceptions across multiple systems now runs continuously with agents handling routine cases and escalating genuine exceptions to human reviewers.

Financial close and reconciliation is a higher-stakes application where agents are reducing close cycles by 20 to 30 percent, with some organizations reporting 90% reductions in specific reconciliation tasks. The value here is not just speed. It is the elimination of the manual data-gathering and cross-checking that consumes finance teams during close periods, freeing them for analysis and judgment rather than data wrangling.

Compliance monitoring moves from periodic audits to continuous oversight when agents are involved. Rather than reviewing a sample of transactions after the fact, agents monitor every transaction against regulatory requirements in real time, flagging anomalies and generating audit-ready documentation. For regulated industries, this shifts compliance from a costly retrospective exercise to an embedded operational capability.

HR and People Operations

HR processes are deceptively complex. They span multiple systems, require coordination across functions, and involve a mix of structured data and human judgment. The handoff-intensive nature of processes like onboarding makes them natural candidates for agentic AI.

Employee onboarding orchestration is one of the clearest examples of agent value in HR. A new hire triggers a cascade of tasks across HRIS, IT provisioning, directory services, benefits enrollment, mandatory training, and manager coordination. Traditionally, these tasks are managed through checklists and manual handoffs, with predictable gaps and delays. An agent can orchestrate the entire sequence: capturing credentials from offer documents, triggering cross-system provisioning, routing benefits enrollment, scheduling training, and confirming completion with full audit trails. Organizations report that agents now handle the majority of onboarding coordination, including tasks that fall outside standard business hours.

Employee inquiries and tier-1 support is an area where agents handle routine questions about benefits, policies, PTO balances, and process guidance. This is not the same as a chatbot with a knowledge base. Agentic systems can take action: updating records, initiating workflows, and resolving issues end-to-end rather than simply providing information and sending the employee elsewhere to complete the task.

Workforce planning and skills analysis is an emerging application where agents analyze workforce data to surface insights about skills gaps, attrition risks, and capacity constraints. The value is shifting HR from reactive reporting to proactive recommendation, though most organizations maintain human decision-making for actions that affect individual employees.

Supply Chain and Operations

Supply chains are coordination machines. They involve dozens of systems, hundreds of trading partners, and thousands of decisions per day. They are also highly sensitive to disruption and delay. The combination of complexity, volume, and time-sensitivity makes them fertile ground for agentic AI.

Demand sensing and planning is moving from historical-pattern forecasting to dynamic signal processing. Agents analyze real-time inputs, including point-of-sale data, weather patterns, social sentiment, and supply disruption signals, and adjust demand forecasts accordingly. The shift is from dashboards that recommend adjustments to agents that make adjustments within defined parameters, escalating only when conditions deviate significantly from expectations.

Procurement automation extends beyond simple purchase order generation. Agents can identify emerging supply risks, evaluate alternative vendors against established criteria, manage routine replenishment within approved parameters, and handle supplier communication for standard transactions. The human role shifts from executing transactions to setting policies and managing exceptions.

Logistics coordination is where multi-agent orchestration becomes particularly relevant. Route optimization, carrier selection, exception handling, and customer communication during delivery all involve real-time decisions that benefit from speed and consistency. Agents that can coordinate across these tasks, adapting when conditions change, operate more effectively than sequential manual processes.

Customer Operations

Customer operations has seen some of the most visible and well-documented agent deployments, driven by the combination of high volume, measurable outcomes, and direct revenue impact.

Service incident resolution is the flagship use case. Organizations are reporting that agents now resolve 46 to 70 percent of customer inquiries end-to-end without human involvement. Resolution times have dropped from minutes to seconds. Cost per resolution has fallen from the $7 to $8 range for human-handled interactions to under $1 for agent-resolved cases. These are not simple FAQ lookups. Agents are checking order status, processing returns, updating account information, applying credits, and coordinating across backend systems to resolve multi-step issues.

Customer onboarding involves guiding new customers through setup, configuration, and initial value realization. Agents can personalize the onboarding flow based on customer characteristics, proactively identify barriers to adoption, and intervene before the customer needs to ask for help. Organizations report improved satisfaction scores and reduced time-to-value as a result.

Proactive outreach is where agents shift from reactive service to anticipatory engagement. Monitoring customer behavior and account health, they identify opportunities for outreach before issues escalate: contract renewals approaching, usage patterns suggesting churn risk, or expansion opportunities based on product usage. The agent initiates the outreach or prepares a briefing for a human representative, depending on the situation's complexity and sensitivity.

Sales and Marketing

Sales is one of the fastest-payback areas for agentic AI, with some organizations reporting return on investment within the first few months of deployment.

Lead qualification and routing is where agents process inbound leads, enrich them with company and contact data, score them against qualification criteria, and route qualified leads to the appropriate representative. The speed advantage is significant: leads routed within minutes rather than hours or days. Organizations report two to three times more qualified meetings within the first month and a reduction in time-to-first-meeting from over a week to a few days.

Pipeline management and development involves agents that research target accounts, build prospect profiles, generate personalized outreach, monitor responses, update CRM records, and identify dormant opportunities worth re-engaging. One large enterprise reported $1.7 million in new pipeline generated from leads that had been sitting untouched in the CRM.

Content operations is the area where agents generate, personalize, and distribute marketing content at a scale that would be impossible for human teams alone. The shift is from one-to-many content creation to one-to-one personalization across email sequences, social content, and sales collateral. The value is both efficiency (dramatically reduced production time and cost) and effectiveness (higher engagement from personalized content).

IT Operations

IT operations has a long history with automation, from scripted responses to runbook automation. Agentic AI extends this by handling situations that require judgment, cross-system coordination, and adaptive response.

Incident response and remediation is where agents monitor system health, detect anomalies, diagnose root causes, and execute remediation, often resolving issues before users notice them. The shift from alert-and-escalate to detect-diagnose-resolve changes the operational model entirely. Human operators focus on complex, novel incidents while agents handle the high-volume repetitive cases.

Provisioning and access management involves agents orchestrating the cross-system workflows required when employees join, change roles, or leave. Identity management, access controls, infrastructure provisioning, and tool configuration all follow patterns that agents can execute faster and more consistently than manual processes. One government organization reported reducing case-opening times from 10 days to 30 minutes through agent-driven provisioning.

Security operations is an emerging but rapidly growing application. Agents monitor for threats, triage alerts, and execute initial response protocols. Given that security teams face alert volumes that far exceed human capacity to review, agents that can handle first-level triage and execute routine containment actions free human analysts for the complex investigations that require judgment and creativity. This area carries particular governance requirements, which we will address in Part 8.

What Makes a Good Agent Use Case?

Looking across these functions, a pattern emerges. The workflows where agents deliver the most value share several characteristics.

High volume. Processes that handle hundreds or thousands of transactions per day benefit most from the speed and consistency that agents provide. Low-volume processes may not justify the investment in configuration and governance.

Rule-based with defined exceptions. The best candidates follow established rules for the majority of cases but encounter exceptions that require judgment. Agents handle the rule-based majority and escalate the exceptions, rather than requiring a human to process every case just to catch the occasional outlier.

Data-intensive and cross-system. Workflows that require gathering information from multiple systems, reconciling data across sources, and making decisions based on that consolidated view are natural fits. This is exactly the coordination-heavy work where humans lose time and make errors due to context-switching and fatigue.

Handoff-heavy. Processes that pass through multiple teams or roles, with the associated delays, miscommunications, and dropped balls, benefit enormously from agents that maintain context and continuity across the entire workflow.

Measurable outcomes. The strongest candidates have clear metrics: processing time, error rate, cost per transaction, customer satisfaction, resolution time. Measurability matters not just for proving value but for monitoring agent performance and identifying when intervention is needed.

Well-understood current state. This is the characteristic that separates realistic candidates from aspirational ones. If your team cannot clearly describe how a process works today, including the unwritten rules, informal workarounds, and tribal knowledge that make it function, you are not ready to hand it to an agent. Agents need clear instructions and defined boundaries. They cannot operate effectively on processes that are poorly documented or inconsistently followed.

What It Takes: Process Maturity

The readiness dimension at the heart of this article is process maturity. Technology capabilities and organizational readiness matter, but agents cannot automate what you have not defined.

Here is what process maturity requires in practice:

Document your processes honestly. Not as they appear in your process documentation (which may be years out of date), but as they operate in reality. Agents will follow the instructions you give them. If your documented process does not match actual practice, the agent will do the wrong thing consistently and at scale.

Map the exception paths, not just the happy path. Every process has exceptions: unusual inputs, edge cases, situations that require human judgment. Identifying these before deployment determines where your agent needs guardrails and escalation protocols. If you only define the happy path, the agent will either fail silently on exceptions or handle them inappropriately.

Identify the informal knowledge that makes processes work. In many organizations, critical processes depend on institutional knowledge that lives in people's heads rather than in documentation. The experienced accounts payable specialist who knows which vendors have different invoicing quirks. The IT administrator who knows which systems need to be updated in a specific sequence. This knowledge needs to be captured and codified before an agent can take over the workflow.

Assess process consistency across the organization. If different teams or locations execute the same process differently, you have a decision to make before deploying an agent: which version becomes the standard? Agents can enforce consistency, but only if you have defined what consistency means.

Start with workflows that are already well-managed. This sounds counterintuitive. Many organizations want to point agents at their messiest processes first. But agents perform best on workflows that are already well-understood and reasonably consistent, because those are the workflows where you can define clear instructions, meaningful guardrails, and reliable escalation criteria. Fix the process first, then automate it.

If your organization has well-documented processes that match actual practice, defined exception paths, and captured institutional knowledge for your target workflows, you have the process foundation for agent deployment. If not, the most valuable investment right now is process documentation and standardization, because it is a prerequisite for everything that follows.

Up Next

In Part 5, we will examine what happens when agents need to work together: the orchestration layer. As organizations move beyond single-agent deployments to coordinated multi-agent workflows, orchestration becomes the critical infrastructure that determines whether your agents collaborate coherently or operate as disconnected islands. We will explore how orchestration differs from traditional workflow automation, the patterns that emerging deployments use, and why this coordination layer is becoming the new competitive edge.

---

The Problem with One-Dimensional Thinking

Most organizations approach agentic AI by asking a single question: what can the technology do? They evaluate platforms, assess model capabilities, and explore use cases. These are reasonable starting points. But they are only half the picture.

The question that gets far less attention, and the one that determines whether an agentic AI initiative succeeds or stalls, is: what can our organization support?

Technology capability without organizational readiness leads to failed deployments, compliance risks, and eroded trust. Organizational readiness without matching technology ambition leads to missed opportunities, wasted investment, and a widening gap against competitors who are moving faster.

This is why a one-dimensional AI strategy fails. Whether you focus only on what the technology can do or only on what the organization needs, you end up with an incomplete picture and decisions that misfire. The Dual Maturity Framework, introduced in our research earlier this year, addresses this by mapping two dimensions simultaneously: how capable the AI is and how prepared the organization is to handle that capability. The alignment between these two dimensions is where strategy lives.

The First Dimension: Organizational AI Maturity

The first axis of the framework assesses your organization's readiness to support AI that acts with increasing independence. This is not a technology assessment. It evaluates your data infrastructure, governance structures, leadership engagement, workforce preparedness, and cultural adaptability.

We define five levels, starting from zero.

Level 0: No Capabilities. There is no formal AI strategy, no governance framework, and no coordinated approach to data management. Data sits in operational silos. There is no executive sponsorship and minimal AI literacy across the organization. This is the starting point for organizations that have not yet begun the journey, and it is where any autonomous deployment would be premature.

Level 1: Opportunistic. Individual teams are experimenting with AI tools on their own initiative, but there is no coordination, no formal policies, and no centralized oversight. This is the "shadow AI" stage that many organizations pass through. It produces localized wins but also ungoverned risk: tools making decisions with unvetted data, potential compliance exposures, and duplicated effort across teams that do not know what the others are doing.

Level 2: Operational. The organization has moved from ad hoc experimentation to deliberate deployment for defined purposes: summarization, routing, report generation, and similar productivity applications. Some governance is in place, but it may be fragmented across business units. Data quality has improved in the areas where AI is deployed, but an enterprise-wide data strategy is still incomplete. The organization can support AI that proposes and assists, but its infrastructure and policies are not yet mature enough for agents that operate across organizational boundaries.

Level 3: Systemic. This is a significant inflection point. AI is integrated across organizational boundaries, with agents operating in workflows that span multiple functions. This requires a federated data strategy, one that is governed consistently but accessible enterprise-wide. Governance is comprehensive, with clear policies on AI decision-making authority, escalation protocols, and monitoring. Cross-functional teams manage deployments, and the organization has invested in AI literacy at every level.

Level 4: Strategic. AI is a core component of how the organization designs work. Governance is embedded into the AI development lifecycle rather than applied as an afterthought. Executive sponsorship is active and informed. Data infrastructure provides real-time, enterprise-wide access with robust quality controls. The workforce is skilled in AI collaboration, and the culture embraces continuous adaptation. This organization is prepared for highly autonomous agents because the organizational scaffolding is already in place.

The Second Dimension: Agentic AI Capability

The second axis assesses how much autonomy the AI system exercises. In Part 2, we introduced the autonomy spectrum. Here, we connect each level to the organizational requirements it creates.

Level 1: Assistive. The AI responds to direct human prompts and provides single-turn outputs. A user asks a question and gets an answer. There is no autonomous action, no independent planning, and no persistent context between interactions. This is where most generative AI tools operate today, and the organizational requirements are relatively modest.

Level 2: Partial Agency. The AI can analyze a situation and propose a plan of action, but a human must approve every step before it proceeds. For example, an AI system might review a queue of support tickets, categorize them by urgency and complexity, and propose routing decisions, but a human confirms each one. The AI adds value through analysis and recommendation while the human retains decision authority at every stage.

Level 3: Conditional Autonomy. The AI operates independently within defined guardrails, executing tasks and making decisions on its own as long as conditions remain within established parameters. When something falls outside those boundaries, it escalates to a human. The organizational requirements increase significantly here: you need well-defined guardrails, robust escalation protocols, and monitoring systems that can verify the agent is staying within its boundaries.

Level 4: High Autonomy. The AI executes complex, multi-step workflows with minimal human intervention. It coordinates across systems, adapts its approach based on changing conditions, and handles exceptions within broad operational parameters. Human oversight shifts from real-time supervision to periodic audits and performance reviews. This level demands sophisticated monitoring infrastructure because humans are no longer watching in real time.

Level 5: Full Agency. The AI is capable of extended autonomous operation and self-directed goal-setting. This level is largely aspirational today. The governance, trust, and verification infrastructure needed to support full agency in enterprise environments is still developing. We include it to provide a complete picture of the spectrum and to help organizations plan for what is coming.

The Matching Matrix: Where Strategy Meets Reality

The core value of the framework lies in the alignment between the two axes. The principle is straightforward: the autonomy level of your AI should not exceed the maturity level of your organization.

An organization at Level 0 or Level 1 maturity should limit itself to Level 1 (Assistive) AI. Without governance, data infrastructure, or a coordinated strategy, the organization cannot safely support any autonomous action. AI should be limited to prompted, single-turn interactions.

An organization at Level 2 maturity can support Level 2 (Partial Agency) AI. There is enough governance and data quality for AI that proposes actions, but human approval is still required at each step. The governance infrastructure can handle review-and-approve workflows but not unsupervised execution.

An organization at Level 3 maturity can support Level 3 (Conditional Autonomy) AI. Cross-functional integration, federated data access, and comprehensive governance enable the definition and enforcement of guardrails. Escalation protocols are mature enough to handle boundary cases reliably.

An organization at Level 4 maturity can support Level 4 (High Autonomy) AI. Embedded governance, real-time monitoring, executive sponsorship, and enterprise-wide data infrastructure can support agents operating complex workflows with minimal oversight. Periodic audits replace real-time supervision.

Notice there is no recommended organizational pairing for Level 5 autonomy. Full agency requires trust, verification infrastructure, and governance sophistication that does not yet exist at scale in enterprise environments. That will change over time, but today, Level 5 sits in the planning horizon, not the deployment roadmap.

This matrix is not theoretical. When organizations align their AI ambitions to their organizational readiness, deployments succeed more consistently, scale more smoothly, and build the confidence needed to advance further. When they do not, they run into one of two failure modes.

The Two Failure Modes

Overshooting: The High-Risk Zone. Overshooting happens when an organization deploys AI agents with autonomy levels that exceed its organizational maturity. The classic case is a Level 1 organization attempting to deploy Level 4 agents.

The consequences are predictable and painful. Agents operate without clear boundaries because no governance framework defines their decision authority. They work with incomplete or inconsistent information because there is no integrated data infrastructure. Problems compound before anyone detects them because there is no monitoring infrastructure to provide visibility.

The failures tend to be dramatic: compliance violations, customer-facing decisions made on bad data, cascading automated actions that no one can explain or reverse. And the damage extends beyond the immediate incident. Overshooting erodes trust, both internally and externally, and often triggers an overcorrection that shuts down AI initiatives entirely. We have seen organizations set their agentic AI efforts back by years because a premature deployment went wrong and leadership concluded the technology was not ready, when in truth it was the organization that was not ready.

Undershooting: The Lost-Value Zone. Undershooting is the opposite problem: a mature organization deploying AI well below what its infrastructure, governance, and culture can support. A Level 4 organization using only Level 1 assistive tools is leaving enormous value on the table.

This failure mode is particularly insidious because it does not produce visible crises. No one gets fired for undershooting. There are no compliance incidents, no public embarrassments, no dramatic failures. Instead, the damage shows up as a slow erosion of competitive position. The organization has invested in infrastructure, governance, and culture but is not capturing a return on that investment. Knowledge workers remain burdened with tasks that agents could handle. Competitors with similar maturity but more autonomous agents gain advantages in efficiency, speed, and scale.

By the time the gap becomes apparent, the window for catching up may have narrowed. Undershooting is the quiet failure, and it is just as costly as overshooting over time.

A Multi-Year Journey, Not a Single Decision

The Dual Maturity Framework is not a one-time assessment. It is a strategic planning tool for what will inevitably be a multi-year journey. Moving from Level 1 to Level 3 organizational maturity typically requires 18 to 36 months of sustained investment in data infrastructure, governance, workforce development, and cultural change.

The practical implication is that you should advance both dimensions in concert. As your data infrastructure improves, deploy agents that can use that data within your current governance boundaries. As your governance matures, expand the autonomy of your agents to match. Each step forward on one axis creates the conditions and the confidence to take the next step on the other.

This is where the framework becomes most valuable as a planning tool. Rather than asking "What agents should we deploy?" in isolation, you can ask: "Given where we stand on organizational maturity, what level of agent autonomy can we responsibly support today? And what do we need to build on the organizational side to support the next level?"

That second question turns the framework from a diagnostic into a roadmap. It makes visible the specific investments, in data, governance, workforce readiness, and process design, that are prerequisites for advancing your agentic capabilities. And it prevents the all-or-nothing thinking that stalls so many initiatives: you do not have to leap from where you are today to full autonomy. You can progress deliberately, building capability and confidence at each stage.

What It Takes: Honest Self-Assessment

The readiness question at the heart of this article spans all six dimensions of our Agentic AI Readiness Assessment: Strategic Alignment, Technical Infrastructure, Data Readiness, Process Maturity, Governance and Risk Management, and Workforce Readiness. Each of these dimensions maps to the organizational conditions that determine what level of AI autonomy your organization can support.

Here is what honest self-assessment requires in practice:

Know where you stand on each dimension. You need a clear-eyed view of your current state across all six areas. Where is your data infrastructure? How mature is your governance? How ready is your workforce? The answers will not be uniform. Most organizations are further along on some dimensions than others, and those gaps are important to identify because they define where to invest next.

Resist the temptation to overrate your readiness. This is harder than it sounds, especially in organizations where there is pressure to appear innovative or where leadership has publicly committed to AI transformation. The Dual Maturity Framework only helps if the self-assessment is honest. An inflated view of your organizational maturity leads directly to overshooting.

Look for the gaps between dimensions. An organization might have strong data infrastructure but weak governance, or excellent executive sponsorship but limited workforce readiness. These asymmetries matter. The dimension where you are weakest sets the ceiling for what level of agent autonomy you can safely support. Identifying the bottleneck dimension tells you where the highest-return investment lies.

Use the framework to build a sequenced plan. Once you know where you stand and where the gaps are, you can build a phased plan that advances both dimensions in coordination. Phase 1 might focus on closing your most critical readiness gap while deploying agents at the autonomy level your current maturity supports. Phase 2 expands autonomy as the organization catches up. This sequenced approach is more effective than trying to move everything forward at once.

Make assessment ongoing, not one-time. Both the technology landscape and your organizational capabilities are evolving. The alignment that is right today may not be right in six months. Build periodic reassessment into your operating rhythm so you can adjust as conditions change.

To help readers put this framework into practice, we are building a companion Dual Maturity Quick Diagnostic tool that will be available at arionresearch.com. The diagnostic is a brief self-assessment, roughly 10 questions, that plots your organization on the Matching Matrix and provides an initial reading of whether you are aligned, overshooting, or undershooting. It is a starting point, not a comprehensive evaluation. For organizations that want a deeper assessment, our full Agentic AI Readiness Assessment provides detailed evaluation across all six dimensions, and our AI Blueprint offering translates that assessment into a concrete implementation roadmap.

Up Next

In Part 4, we will shift from frameworks to use cases: where agents create real business value today. Organized by business function, from finance and operations to customer service and IT, Part 4 helps you identify the high-value opportunities in your own organization and understand what makes certain workflows better candidates for agentic AI than others. If you have been waiting for the practical "where do we start?" guidance, that is the next article.

---

The Vocabulary Problem

In Part 1 of this series, we made the case that the agentic enterprise is not a distant aspiration but an emerging reality, and that the shift from AI-as-tool to AI-as-worker requires a different kind of organizational thinking. But before we can think clearly, we need to talk clearly. And right now, the vocabulary around agentic AI is a mess.

Walk into any enterprise strategy meeting about AI and you will hear terms like "agent," "copilot," "bot," "RPA," "orchestration," and "autonomy" used interchangeably, imprecisely, or in ways that mean something different to every person in the room. Your CIO uses "agent" to describe a specific technical architecture. Your operations lead uses it to describe anything that automates a task. Your vendor's sales team uses it to describe whatever they're selling this quarter.

This is not just a semantic nuisance. Vocabulary misalignment leads to strategic misalignment. When the leadership team thinks they have agreed on an agentic AI strategy but each member has a different mental model of what "agent" means, the resulting initiatives pull in different directions. Budget gets allocated to the wrong capabilities. Vendor evaluations compare unlike things. And the organization ends up confused about what it is building and why.

This article is a translation guide. It takes the terms that dominate the agentic AI conversation and defines them in practical, business-language terms. The goal is not technical precision for engineers. It is shared understanding for the cross-functional teams that need to make decisions together.

Automation: Where It All Started

Before we get to agents and copilots, it helps to ground the conversation in what came before, because the history shapes how people think about what comes next.

Traditional automation in the enterprise has meant rule-based systems that follow predefined instructions. If an invoice matches a purchase order within tolerance, approve it. If a server's CPU exceeds a threshold, send an alert. These systems are fast, reliable, and predictable, but they have a hard boundary: they cannot handle anything they were not explicitly designed for.

Robotic Process Automation (RPA) extended this approach by mimicking human interactions with software. RPA bots log into applications, copy data between systems, and complete repetitive tasks that previously required a person clicking through screens. But RPA shares the same hard boundary: it follows scripts. When the process changes, the script breaks. When the situation requires judgment, the bot stops.

Understanding this history matters because many executives carry mental models shaped by these earlier approaches. When they hear "AI agent," they picture a faster, smarter version of an RPA bot. That mental model leads to underestimating both the opportunity and the organizational requirements of agentic AI.

Copilots: AI That Assists

The generative AI wave introduced a new model for human-AI interaction: the copilot. A copilot is an AI system that works alongside a human, responding to requests and augmenting the person's capabilities. You ask a question, it provides an answer. You start drafting a document, it suggests completions. You need to analyze data, it generates charts and summaries.

Copilots have delivered real value. Products like Microsoft 365 Copilot, Salesforce Einstein Copilot, and dozens of domain-specific tools have made copilot-style AI a familiar part of the workday for millions of people, helping them write faster, research more efficiently, and analyze data more quickly.

But copilots have a defining characteristic that also defines their limitation: they are reactive. A copilot waits for a human to initiate an interaction. It does not monitor a situation, identify a problem, formulate a plan, and take action on its own.

Think of a copilot as a brilliant assistant sitting next to you. Anytime you turn and ask a question, the assistant provides a thoughtful, well-researched answer. But the assistant never taps you on the shoulder and says, "I noticed something you should know about," or "I took care of that issue before it became a problem." The initiative always rests with the human.

For many tasks, this is exactly the right model. The mistake is assuming it is the only model, or that it is sufficient for operational challenges that require continuous monitoring, multi-step execution, and cross-system coordination.

Agents: AI That Acts

An AI agent is a system that can pursue goals with some degree of independence. Unlike a copilot that responds to individual requests, an agent can be given an objective, break it into steps, make decisions about how to proceed, interact with tools and systems, and carry out tasks over extended periods with limited human involvement.

The key distinction is initiative. An agent does not wait to be asked. Within the boundaries it has been given, it identifies what needs to happen and makes it happen.

Consider a practical example. In a customer service context, a copilot helps a support representative by suggesting responses, pulling up relevant knowledge base articles, and summarizing the customer's history. The representative makes every decision: what to say, what action to take, when to escalate.

An agent in the same context operates differently. It monitors incoming customer inquiries, assesses the complexity and urgency of each one, handles straightforward issues end-to-end (checking order status, processing a return, updating account information), and routes complex or sensitive issues to human representatives with a summary and recommended course of action. The agent does not just suggest; it executes. And it does this continuously, across hundreds or thousands of interactions, without waiting for a human to initiate each one.

This is not a difference of degree. It is a difference of kind. And it has significant implications for how organizations need to think about governance, oversight, data access, and process design, topics we will cover in depth later in this series.

The Autonomy Spectrum

One of the most common sources of confusion in the agentic AI conversation is the word "autonomous." It conjures images of AI systems operating with complete independence, making decisions with no human oversight, which triggers understandable concern among business leaders.

The reality is more nuanced. Autonomy is a spectrum, not a binary switch. In the Dual Maturity Framework (which we will explore in detail in Part 3), we define five levels of agentic AI capability, each describing a distinct degree of independent action.

Level 1: Assistive. The AI responds to direct human prompts and provides single-turn outputs. A user asks a question and gets an answer. There is no independent planning, no multi-step execution, and no persistent context between interactions. This is where most copilot tools operate today.

Level 2: Partial Agency. The AI can analyze a situation and propose a plan of action, but a human must approve every step before it proceeds. For example, an agent might review a set of vendor proposals, rank them against your evaluation criteria, and recommend a shortlist, but a human makes the final selection and initiates each next step.

Level 3: Conditional Autonomy. The AI operates independently within defined guardrails, executing tasks and making decisions on its own as long as conditions stay within established parameters. When something falls outside those boundaries, it escalates to a human. Think of an agent that automatically approves purchase orders under $5,000 from approved vendors for standard supplies, but flags anything above that threshold or from a new vendor for human review.

Level 4: High Autonomy. The AI executes complex, multi-step workflows with minimal human intervention. It can coordinate across systems, adapt its approach based on changing conditions, and handle exceptions within broad operational parameters. Human oversight shifts from real-time supervision to periodic reviews and performance monitoring. An agent at this level might manage an entire accounts payable workflow: receiving invoices, matching them to purchase orders, resolving discrepancies, scheduling payments, and handling routine exceptions, with humans reviewing dashboards and intervening only for strategic decisions.

Level 5: Full Agency. The AI is capable of extended autonomous operation and self-directed goal-setting. This level is largely aspirational today. The governance, trust, and verification infrastructure needed to support full agency in enterprise environments is still developing.

Understanding this spectrum is essential for two reasons. First, it helps leaders match the right level of autonomy to each use case. Not every process needs a Level 4 agent. Many workflows are well-served by Level 2 or Level 3 capabilities. Second, it prevents the all-or-nothing thinking that stalls agentic AI initiatives. You do not have to leap from copilots to fully autonomous agents. You can progress deliberately, building confidence, governance, and organizational capability at each stage.

Orchestration: When Agents Work Together

As organizations move beyond single-agent deployments, a new challenge emerges: coordination. When multiple agents need to work together across a complex process, something has to manage the flow, routing tasks between agents, sequencing activities, handling handoffs, and managing exceptions. This coordination layer is called orchestration.

Orchestration is the connective tissue of the agentic enterprise. Without it, you have a collection of individual agents that each do their own thing but don't work together coherently. With it, you have coordinated workflows where agents collaborate with each other and with human workers to accomplish complex, multi-step objectives.

Think of it in business terms. In a traditional organization, a manager coordinates the work of a team: assigning tasks, sequencing activities, resolving bottlenecks, and making sure the pieces come together into a coherent output. Orchestration plays a similar role for AI agents. It is the management layer that turns individual capabilities into coordinated operations.

We will explore orchestration in depth in Part 5, but it is important to introduce the concept here because it shapes how you evaluate vendor claims and platform capabilities. When a vendor tells you their platform supports "multi-agent workflows," the right follow-up question is: how does orchestration work? Who or what decides which agent handles which task? How are handoffs managed? What happens when an agent encounters something it cannot handle? The answers to these questions reveal more about a platform's real-world readiness than any feature list.

Cutting Through Vendor Marketing

Now that we have a shared vocabulary, let's address a practical challenge: navigating vendor marketing claims. The agentic AI space is in a period of intense hype, and the terminology we have just defined is being used loosely, sometimes to the point of meaninglessness.

Here are some common patterns to watch for.

Agentic" as a label for copilot features. Some vendors have rebranded their existing copilot or chatbot capabilities as "agentic" without adding meaningful autonomous capabilities. If the AI still requires a human to initiate every interaction and approve every action, it is a copilot with a new name, regardless of what the marketing says. The test is simple: can this system take goal-directed action on its own, or does it wait to be asked?

Autonomy claims without governance specifics. When a vendor emphasizes what their agents can do but is vague about guardrails, escalation protocols, audit trails, and monitoring capabilities, that is a red flag. Mature agentic AI requires robust governance. Vendors who have built for real enterprise deployment will have detailed answers about how their agents are supervised, how decisions are logged, and how exceptions are handled.

Orchestration" used loosely. Some platforms describe simple sequential workflows as "orchestration." Genuine orchestration involves dynamic routing, conditional logic, exception handling, and coordination across multiple agents and systems. If the "orchestration" is just a predefined workflow that runs the same way every time, it is automation with a new label.

Confusing model capabilities with agent capabilities. A large language model that can reason well and use tools is not automatically an agent. An agent requires additional infrastructure: persistent memory, goal management, tool integration, monitoring, and governance frameworks. Model intelligence is necessary but not sufficient.

The shared vocabulary we have established here gives your team a framework for asking better questions and evaluating vendor claims more critically. When someone presents an "agentic AI platform," your team can ask: what level of the autonomy spectrum does this operate at? How does orchestration work? What governance capabilities are built in? What does the escalation path look like?

What It Takes: Building Shared Understanding

The readiness dimension that matters most at this stage of the journey is deceptively simple: does your organization have a shared understanding of what it is talking about?

This might sound like a soft requirement compared to technical infrastructure or data readiness. It is not. Misaligned vocabulary leads to misaligned strategy, which leads to misaligned investment. We have seen organizations spend months evaluating platforms that do not match their needs because different stakeholders had fundamentally different mental models of what "agentic AI" meant for their business.

Here is what building shared understanding requires in practice:

Assess AI literacy across the organization. This does not mean testing whether people can define technical terms. It means understanding whether the leaders who will make decisions about agentic AI, including line-of-business executives, IT leadership, operations, compliance, and HR, have a common framework for discussing capabilities, risks, and opportunities. If your CFO thinks "agent" means "chatbot" and your CTO thinks it means "autonomous system," you have a communication gap that will show up in every strategic conversation.

Create a common language document. Take the definitions we have outlined here, adapt them to your organization's context, and make them a reference point for all AI-related discussions. This is not about being pedantic. It is about ensuring that when your leadership team discusses agentic AI strategy, everyone is working from the same conceptual foundation.

Educate across functions, not just within IT. Agentic AI is not a technology initiative that can be contained within IT. It affects how work gets done across every function. Business leaders need to understand enough about agent capabilities and limitations to make informed decisions about where and how agents fit into their operations. This does not require deep technical training. It requires the kind of practical, business-language understanding that this article and this series aim to provide.

Address misconceptions early. The two most common misconceptions we encounter are "agents will replace our workforce" and "agents are just fancy chatbots." Both are wrong, and both lead to poor decisions, either excessive fear that blocks adoption or insufficient respect for the organizational changes that agentic AI requires. Addressing these misconceptions early, with clear explanations and practical examples, saves enormous time and friction later.

Include change management in AI literacy efforts. Workforce readiness is not just about understanding the technology. It is about preparing people for how their work will change. We will cover this in depth in Part 9, but the groundwork starts here, with honest, transparent communication about what agentic AI means for roles, skills, and ways of working.

If your organization can align on vocabulary, build baseline literacy across functions, and address the most common misconceptions, you have the communication foundation to move forward. If different parts of the organization are still using the same words to mean different things, invest the time to fix that before you invest in platforms and pilots.

Up Next

In Part 3, we will introduce the Dual Maturity Framework, a structured approach to understanding where your organization stands today and what level of AI autonomy it can support. The framework maps two dimensions, organizational readiness and agentic capability, and reveals the two failure modes that derail most enterprise AI initiatives: overshooting (deploying too much autonomy too soon) and undershooting (mature organizations that deploy too little). If you have ever wondered how to honestly assess your organization's readiness for agentic AI, Part 3 provides the diagnostic.

The Shift No One Can Afford to Ignore

For the past three years, the enterprise AI conversation has centered on generative AI. And for good reason. Tools that could summarize documents, draft emails, generate code, and answer complex questions delivered real productivity gains across nearly every function. Copilots became the default deployment model: AI that sits beside a human worker, ready to help when asked.

But something has changed. The conversation in boardrooms and strategy sessions has moved past "How do we use AI to help our people work faster?" to a more consequential question: "How do we use AI to work differently?"

That shift in framing matters more than it might seem. Helping people work faster is an optimization play. Working differently is a transformation play. And the technology driving that transformation is agentic AI: systems that don't wait to be asked, but instead plan, decide, execute, and coordinate across complex workflows with varying degrees of independence.

The agentic enterprise is not a distant concept. It is emerging right now, in organizations that are moving beyond pilots and proofs of concept to deploy AI agents in production workflows. And the gap between organizations that figure this out and those that don't is widening faster than most leaders realize.

From Tools to Workers: What Changed

To understand why the agentic enterprise matters now, it helps to trace how we got here.

The first wave of enterprise AI was predictive. Machine learning models analyzed historical data to forecast demand, flag anomalies, score leads, and optimize supply chains. These systems were powerful but narrow, and they required specialized teams to build and maintain.

The second wave was generative. Large language models democratized AI by making it accessible through natural language. Suddenly, any knowledge worker could interact with AI without writing code or understanding model architectures. This wave brought AI out of the data science lab and into everyday work.

The third wave, the one we're entering now, is agentic. Agentic AI systems don't just generate outputs in response to prompts. They take action. They can break complex goals into steps, make decisions within defined boundaries, interact with enterprise systems, coordinate with other agents, and carry out multi-step tasks with limited human oversight.

Think about the difference this way. A generative AI tool can draft a purchase order when you ask it to. An agentic AI system can monitor inventory levels, identify when supplies are running low, evaluate vendor options against your procurement policies, generate the purchase order, route it for the appropriate approval, and follow up if the approval stalls. It doesn't wait for someone to notice the problem and type a prompt. It acts.

This is not a marginal improvement over copilots. It is a different category of capability, and it requires a different kind of organization to support it.

Why Now? The Convergence

Agentic AI didn't appear overnight. The technology has been advancing steadily, but several forces have converged in 2025 and 2026 to make this the inflection point.

Model capabilities have crossed a threshold. Today's large language models can reason through multi-step problems, maintain context across extended interactions, use tools and APIs, and self-correct when they encounter errors. These capabilities, combined with advances in planning and orchestration frameworks, make it practical to build agents that can handle real enterprise workflows, not just toy demos.

Enterprise platforms are building agent infrastructure. The major enterprise software vendors, from Salesforce and Oracle to Zoho and ServiceNow, have introduced or announced agentic capabilities within their platforms. This signals that agents are not a niche technology play but a core part of the enterprise software roadmap. When your existing vendors start shipping agent frameworks, the adoption conversation shifts from "should we explore this?" to "how do we integrate this into what we already run?"

The economics of knowledge work are under pressure. Every organization faces the same math: rising labor costs, growing complexity, and an expanding volume of work that requires judgment, coordination, and execution across systems. Copilots helped at the margins by making individual workers more productive. Agents address the structural challenge by taking on entire workflows that previously required multiple people, multiple handoffs, and multiple systems.

Early adopters are showing results. We are past the point where agentic AI is purely theoretical. Organizations across financial services, healthcare, manufacturing, retail, and professional services have moved agents into production, handling tasks from claims processing and compliance monitoring to customer onboarding and supply chain coordination. The results, both in efficiency gains and in the quality of outcomes, are compelling enough to shift the conversation from "if" to "how fast."

The talent equation is shifting. Organizations everywhere are struggling to find and retain enough skilled workers to keep pace with growing operational complexity. Agentic AI offers a way to address capacity constraints without simply adding headcount. This is not about cost-cutting through layoffs. It is about extending what your existing workforce can accomplish by offloading the repetitive, coordination-heavy work that consumes so much of their time today.

The Strategic Imperative

For business leaders, the agentic enterprise is not primarily a technology initiative. It is a strategic one.

The organizations that move effectively toward agentic operations will gain compounding advantages. Their processes will run faster and more consistently. Their people will focus on higher-value work while agents handle the routine and the complex-but-repetitive. Their ability to scale operations without proportionally scaling headcount will create structural cost advantages. And their capacity to respond to market changes will accelerate as agents handle the execution while humans focus on strategy and judgment.

The organizations that delay will find themselves in an increasingly difficult position. Not because agents will replace their workforce overnight, but because competitors using agents effectively will operate at a speed and consistency that is hard to match with human-only teams managing traditional workflows.

This is not about replacing people. That framing misses the point entirely. The agentic enterprise is about redesigning how work gets done so that human intelligence and artificial intelligence each handle what they do best. People bring judgment, creativity, empathy, relationship skills, and the ability to navigate ambiguity. Agents bring speed, consistency, tirelessness, and the ability to coordinate across systems and data sources without losing context or making fatigue-driven errors.

The winning combination is not humans or agents. It is humans and agents, working together within workflows that are designed for that collaboration from the ground up.

What This Series Will Cover

Building the agentic enterprise is not a single decision or a single project. It is a multi-dimensional journey that touches technology, data, governance, process design, workforce strategy, and organizational culture. Getting any one of these dimensions wrong can stall the entire effort.

Over the next ten articles, we will walk through each of these dimensions in practical, business-focused terms. Here is the arc:

We will start by cutting through the jargon, providing a clear, business-language guide to agents, copilots, orchestration, and autonomy levels so that leaders across the organization can have productive conversations about what they're building toward.

We will introduce a framework for understanding where your organization stands today and what level of AI autonomy it can support, using the Dual Maturity Framework that maps organizational readiness against agentic capability.

We will explore where agents create real business value, organized by function and use case, with a focus on outcomes rather than technology features.

We will examine the orchestration layer, the emerging middleware that coordinates multiple agents, systems, and human decision-makers into coherent workflows, and explain why it is becoming the critical infrastructure layer of the agentic era.

We will tackle the platform question (build, buy, assemble, or extend), the data foundation that agents depend on, the governance and trust frameworks that keep autonomous systems accountable, and the human side of the equation, including how roles, skills, and organizational design need to evolve.

We will close with practical guidance on navigating the vendor landscape and building an execution roadmap that moves from vision to measurable results.

Each article will include a "What It Takes" section: a practical assessment of the organizational readiness required for that dimension. These sections are designed to help you identify where your organization stands and what needs to change, because understanding the technology is only half the equation. The other half is knowing whether your organization can absorb it.

What It Takes: Strategic Alignment as the Starting Point

Before diving into agents, orchestration, platforms, or any of the technical dimensions, the first readiness question every organization should answer is deceptively simple: Why are we doing this, and what does success look like?

Strategic alignment is where most agentic AI initiatives either find their footing or lose their way. Organizations that jump to technology selection or pilot projects without first connecting their AI investments to specific business outcomes tend to end up with impressive demos that don't move important metrics.

Here is what strategic alignment requires in practice:

Executive sponsorship that goes beyond approval. Agentic AI is not something you can delegate to IT or a digital transformation team and check in on quarterly. It changes how work gets done across functions, which means leadership needs to be actively involved in defining priorities, resolving cross-functional conflicts, and making resource allocation decisions. Sponsorship means engagement, not just a budget line.

A clear connection between AI investments and business objectives. Which business outcomes are you trying to improve? Revenue growth? Operational efficiency? Customer experience? Time to market? The answer shapes every downstream decision, from which use cases to prioritize to which platforms to evaluate to how you measure success. Starting with the technology and looking for problems it can solve is a reliable path to underwhelming results.

Use case prioritization based on both impact and feasibility. Not every process is a good candidate for agentic AI. The best starting points are workflows that are high-volume, rule-based (with well-defined exceptions), data-intensive, and currently constrained by human bandwidth or handoff complexity. Mapping your candidate use cases against both their business impact and your organizational readiness to support them prevents the common trap of starting with the most ambitious project and stalling.

Success metrics defined before deployment, not after. If you cannot articulate what success looks like in measurable terms before you deploy an agent, you will not be able to distinguish a successful deployment from an expensive experiment. Define the baseline, set targets, and build the measurement infrastructure early.

A realistic view of your starting point. Honest self-assessment is harder than it sounds, especially in organizations where there is pressure to appear innovative. Acknowledging where you have gaps, whether in data quality, governance maturity, technical infrastructure, or workforce readiness, is not a sign of weakness. It is a prerequisite for building a plan that works. We will introduce a structured framework for this assessment in Part 3 of this series.

A long-term vision, not just a pilot plan. Pilots are necessary, but they are not a strategy. Organizations that treat agentic AI as a series of disconnected experiments rarely build the organizational muscle needed for scaled deployment. The most effective leaders think in terms of a multi-year journey: where do we start, how do we learn, how do we scale, and how do we adapt as both the technology and our organization evolve? Part 11 of this series will provide a detailed roadmap framework, but the mindset starts here.

If your organization can answer these questions clearly, you have the strategic foundation to move forward with confidence. If you cannot, the most valuable thing you can do right now is pause the technology conversation long enough to get alignment on the business case, because every other decision in this journey depends on it.

Up Next

In Part 2, we will tackle the jargon problem head-on: agents, copilots, automation, orchestration, autonomy levels, and the rest of the vocabulary that has made the agentic AI conversation unnecessarily confusing. The goal is a clear, business-language guide that gives every leader in your organization the shared vocabulary they need to participate in this conversation productively.

This matters because the distinction between what agentic IoT is and what people are calling agentic IoT is not a semantic quibble. It is a multibillion-dollar valuation gap that can mislead investors, confuse enterprise buyers, and ultimately damage the credibility of a technology category that has real potential.

What Agentic Means

The term "agentic" has a specific technical meaning rooted in the AI research community, and every major platform vendor has converged on a consistent definition. IBM describes agentic AI as systems that "plan, execute, and adapt actions to achieve complex goals without human intervention." Google Cloud defines it as AI that "sets sub-goals, chooses tools, and takes multi-step actions to achieve a user's objective with limited supervision." AWS emphasizes the cycle of sense, plan, act, and reflect. These definitions are not marketing language from competing vendors trying to differentiate; they are descriptions of the same underlying architecture.

The core characteristics are consistent across all of these definitions: autonomous goal-directed reasoning, where the system pursues objectives independently and adjusts strategy as conditions change; multi-step planning, where it decomposes complex tasks into sub-steps and sequences them; environmental perception and adaptation, where it interprets complex input and modifies behavior accordingly; tool use and orchestration, where it selects and invokes external resources dynamically; and learning from feedback, where it improves performance over time based on outcomes.

This is the bar. Not one or two of these characteristics. All of them, working together in a continuous loop. A system that lacks any one of them is, at best, adjacent to agentic AI. And a system that lacks all of them is simply not agentic, regardless of what its marketing materials say.

What Agentic IoT Would Look Like

When you apply the agentic definition to IoT, something compelling emerges. Agentic IoT is the convergence of connected devices with AI systems that can reason, plan, and act on the data those devices produce. OpenText describes it as "prescriptive and autonomous," connecting real-world data streams with AI agents that are goal-driven (optimizing uptime, throughput, safety, or sustainability targets), adaptive (re-planning in real time when disruptions occur), and action-oriented (executing changes across systems and workflows, not just raising alerts).

IoT Analytics frames this as an evolution along a maturity curve: from connected devices that simply report data, through analytics that identify patterns, to autonomous operations where systems make and execute decisions independently. The industry is currently somewhere in the middle of that curve, with most enterprises still in the connected-and-analyzing stages.

A true agentic IoT system in a supply chain context, for example, would not just track a shipment's location. It would monitor the full logistics network, recognize when a delay at one port is going to cascade into missed delivery windows downstream, autonomously reroute shipments through alternative pathways, negotiate with carriers in real time, update customer commitments, and learn from the outcome to improve its routing decisions the next time a similar disruption occurs. That is a system that reasons about goals, plans multi-step responses, adapts to novel situations, orchestrates external tools, and learns from feedback.

That is also a system that, as of April 2026, largely does not exist in production at enterprise scale.

The Relabeling Problem

Here is where it gets problematic. Gartner has identified a phenomenon they call "agent washing," which is the rebranding of existing products, including AI assistants, robotic process automation, chatbots, and, increasingly, IoT platforms, without adding substantial agentic capabilities. Gartner estimates that only about 130 of the thousands of vendors claiming agentic AI capabilities are real. The rest are applying a hot label to existing technology.

In the IoT space, this relabeling follows a predictable pattern. A company has a portfolio of technology that does something useful: tracking assets, monitoring conditions, detecting threshold violations, authenticating products. These are valuable capabilities. But "IoT asset tracking" does not command the same valuation multiple as "agentic IoT platform." So the pitch deck gets rewritten.

I recently reviewed a few product and patent portfolios that illustrate this pattern with unusual clarity. The portfolios were built around a core IoT device designed for location determination, supply chain tracking, and anti-counterfeiting. Solid technology with real market applications. But the companies are trying to position the themselves as "agentic AI" to enhance their perceived value.

The products and patents describe devices that calculate their position using trilateration from timing signals, log location data on a tamper-evident ledger, form peer-to-peer groups that detect missing or added items in a shipment, compare product attributes against stored records to flag counterfeits, and trigger events when assets cross predefined geofence boundaries. Every one of these functions is useful. None of them is agentic.

The Automatic vs. Autonomous Confusion

The core confusion in most agentic IoT claims comes down to a single distinction: the difference between automatic and autonomous behavior.

An automatic system executes a predetermined response to a predetermined trigger. When the temperature exceeds 40 degrees, send an alert. When a device crosses a geofence boundary, log an event. When a hash comparison fails, flag the product as suspect. These are if/then operations. They may be sophisticated in their engineering, and they may run without human intervention, but they are not autonomous in the way that the AI community uses the word.

An autonomous system sets its own sub-goals, selects its own methods, and adapts its approach based on what it learns. It does not just respond to triggers; it reasons about what the triggers mean in context and decides what to do about them. A thermostat that turns on the heat when the temperature drops below 68 degrees is automatic. An AI agent that manages a building's energy consumption by balancing occupancy patterns, weather forecasts, energy prices, equipment health, and tenant comfort preferences, learning from each day's outcomes to improve the next day's decisions, is autonomous.

The products and patent portfolios I reviewed contain devices that adjust their scanning frequency based on context: scan every four hours on a ship, every 30 minutes in a shipyard, every 12 hours on a truck. The specification used the word "recognize" to describe this behavior. But when you read the actual implementation, these were preprogrammed values stored in what the patent called "Local Profile Data Values." If asset type equals ship, then interval equals four hours. That is a lookup table, not recognition. It is the thermostat, not the building management AI.

This conflation matters because it misleads people who do not have the time or technical background to read the underlying specifications. When a board member or investor hears that a portfolio's devices "recognize context changes and autonomously adapt their behavior," it sounds like agentic AI. When you read the underlying claims and find a hardcoded conditional, it is not.

The "Reads On" Fallacy

In the patent world, there is a concept called "reads on," which refers to whether an existing patent's claims could be interpreted to cover a particular technology or product. Some of the most creative agentic IoT claims I have encountered take this approach in reverse: they argue that because agentic AI systems would need to perform functions similar to what the patents describe (location tracking, data authentication, event triggering), the patents somehow "read on" agentic AI.

This logic does not hold up. A filing cabinet reads on the need for document storage in a content management system, but no one would claim a filing cabinet patent covers Dropbox. The fact that an agentic supply chain system would consume location data does not mean a patent covering a location tracking device is an agentic AI patent. The data source is not the intelligence. The sensor is not the agent.

This distinction matters enormously for IP valuation. A patent portfolio that covers the data infrastructure layer of an agentic system has value, but it is a different kind of value, with a different magnitude, than a portfolio that covers the agentic reasoning layer itself. Confusing the two leads to inflated expectations and, eventually, to disappointment when the claims do not survive due diligence.

How to Evaluate Agentic IoT Claims

For enterprise leaders, investors, and board members who encounter agentic IoT positioning, here is a practical framework for evaluating whether the claims are substantive.

First, look for goal-directed reasoning in the actual technical implementation, not in the marketing copy. Ask: does the system pursue objectives it formulates itself, or does it execute responses to predefined triggers? If every behavior can be described as "when X happens, do Y," it is automatic, not agentic.

Second, look for multi-step planning. Can the system decompose a complex problem into sub-tasks and sequence them? Or does it perform single operations in isolation? An IoT device that reads a sensor, compares a value, and sends an alert is doing three things in sequence, but it is not planning. The sequence is hardcoded.

Third, look for learning. Does the system improve over time based on outcomes? Not "does the vendor plan to add machine learning in a future release," but does the current technology, as described in its patents, specifications, or product documentation, include any mechanism for updating its behavior based on feedback? If the answer is no, the system is not agentic.

Fourth, check the claims or product documentation, not the abstracts or marketing material. In patent analysis specifically, the legal scope of protection is defined by the claims, not by the abstract or specification. Abstracts often contain aspirational language ("AI-powered," "machine learning enhanced") that is entirely absent from the claims or documentation. If the claims describe a comparison against a threshold and the abstract mentions machine learning, the patent covers the comparison, not the machine learning.

Fifth, apply the thermostat test. Can you describe the system's behavior using a simple thermostat analogy (when the reading crosses this threshold, take this action)? If yes, it is probably not agentic, no matter what adjectives are attached to it.

The Real Opportunity

None of this is to say that IoT technology lacks value. The problem is not with the underlying technology; it is with the label being applied to it. The global IoT asset tracking market is projected to reach $223 billion by 2030, growing at 24.3% annually. The anti-counterfeiting technology market is expected to hit $178 billion. Cold chain monitoring, supply chain security, and product authentication are all large, growing markets with real demand.

An IoT portfolio that provides authenticated location data, tamper-evident chain of custody records, and automated shipment integrity monitoring has clear value in these markets. That value does not increase by calling it agentic; if anything, the overstatement creates risk. Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. When the correction comes, companies that overstated their agentic credentials will be the first to lose credibility.

The smarter play is to position IoT technology for what it is: the trusted data infrastructure that agentic systems will eventually need. As AI-driven operations scale, the quality and trustworthiness of input data becomes the bottleneck. Authenticated, tamper-proof, cryptographically verified data from IoT devices is not the agent, but it is the agent's most valuable input. That is an honest value proposition, and it is a durable one.

The Bottom Line

The agentic IoT label, when used accurately, describes something transformative: the convergence of connected devices with AI systems that can reason, plan, act, and learn. We are not there yet for most enterprise use cases, but the trajectory is clear and the investment is real.

The problem is that the label is being applied far more broadly than the technology warrants. Companies are rebranding threshold comparisons as "autonomous decision-making," lookup tables as "context recognition," and peer-to-peer device discovery as "multi-agent coordination." This is not unique to IoT; Gartner's "agent washing" observation spans the entire enterprise technology landscape. But in IoT, the gap between the claim and the reality is especially wide because the underlying technology, sensors, conditional logic, and data logging, while growing rapidly in capability, has been around for decades.

For anyone evaluating an agentic IoT claim, whether as an investor, a board member, or an enterprise buyer, the framework is simple: look for goal-directed reasoning, multi-step planning, environmental adaptation, tool orchestration, and learning from feedback. If those capabilities are present, you are looking at something that is agentic. If they are not, you are looking at IoT with a new label. Both can be valuable. But they are not the same thing, and pretending otherwise serves no one.

In the first article of this series, I posed a question: as the traditional enterprise application bundle collapses under the pressure of AI agents, where does the center of gravity of enterprise technology land? Does control accrue to whoever owns the data, whoever owns the intelligence, or whoever owns the business logic?

Seven articles later, we have built the framework to answer that question. We have mapped the three-layer architecture (Enterprise Platform, Agentic Platform, Collaboration), the cross-cutting vertical services (Identity, Governance, Context and Memory, Metering), the connective tissue (Agent Service Bus), and the cross-organizational dimension that stress-tests all of it. Now it is time to map some of  the major vendors against this framework and evaluate who is best positioned to win, over what time horizon, and under what conditions.

The answer, as with most things in enterprise technology, is not simple. The center of gravity shifts over time, and the vendors positioned to win in the near term are not necessarily the ones positioned to win in the long term. Understanding this dynamic is the key to making sound enterprise technology decisions over the next several years.

The Competitive Landscape Mapped to the Framework

The major players in the Future Enterprise landscape fall into four categories, each with distinctive strengths and structural weaknesses when mapped against the architecture we have built in this series.

The Vertical Integrators: Oracle, Salesforce, ServiceNow, zoho, SAP

Large technology providers including Oracle, Salesforce, ServiceNow, Zoho and SAP, control the Enterprise Platform layer today. They own the systems of record, the business logic, and the transactional data that enterprises depend on. Their AI agent strategies share a common pattern: embed agents deeply into the application, operating at the transaction layer with direct access to the data model and business rules.

Oracle has been the most aggressive, embedding over 600 agents across Fusion Cloud applications in finance, HCM, supply chain, and customer experience, and including them at no additional cost within existing subscriptions. This is a deliberate strategy to accelerate adoption and make Oracle's agent layer the default for Fusion customers. Oracle's additional advantage is its infrastructure stack: Database 26ai and OCI provide the compute and data layer beneath the agents, creating a full-stack integration from infrastructure through application through agent that no other vendor can match in depth.

Salesforce has taken a different approach with Agentforce, positioning it as a platform for building and deploying agents across the customer lifecycle. Salesforce's strength is its CRM data: no vendor has a richer, more broadly adopted model of customer relationships, sales processes, and service interactions. Agentforce agents operate within this data model with native understanding that external agents cannot replicate. Salesforce has also been the most aggressive on pricing experimentation, testing per-conversation, consumption, and seat-based models as it navigates the pricing paradox I discussed in Article 6.

SAP controls the operational backbone of many of the world's largest enterprises. Its ERP data, covering finance, supply chain, manufacturing, and procurement, is often the most business-critical data an enterprise holds. SAP's agent strategy embeds AI across these operational workflows, with a particular focus on the complex, regulation-heavy processes where deep data model access provides the most value.

The structural advantage of the vertical integrators is depth. As I argued in Article 3, native agents operating at the transaction layer understand the data model, the business rules, the validation logic, and the exception handling in ways that external agents accessing the same systems through APIs cannot match. This depth advantage is real and durable.

The structural weakness is scope. Each vertical integrator's agents work brilliantly within their own ecosystem and are blind to everything outside it. Oracle's procurement agent cannot orchestrate with Salesforce's CRM agent. SAP's finance agent cannot coordinate with a third-party logistics system. The vertical integrators control deep, narrow slices of the enterprise, and the connective tissue between those slices (the Agent Service Bus, the cross-platform orchestration layer) is not their strength. All of them are adopting open protocols (MCP and A2A), which narrows this gap by enabling their native agents to participate in cross-vendor workflows. But protocol connectivity solves message routing, not semantic translation between different data models, not cross-vendor governance arbitration, and not the commercial tension between openness and platform lock-in. The trajectory is positive. The gap is closing, but it has not closed.

The Horizontal Platforms: OpenAI and Anthropic

OpenAI and Anthropic are building from the opposite direction. They do not control the Enterprise Platform layer. They do not own the systems of record or the business logic. What they control is the intelligence layer: the frontier-class reasoning capability that powers the most sophisticated agent behaviors.

OpenAI's Frontier platform, launched in February 2026, is the most ambitious play to build a horizontal agentic layer across the enterprise. Frontier positions itself as the orchestration platform where agents can work across systems, across vendors, and (eventually) across organizations. The value proposition is breadth: a single platform that can coordinate agents spanning CRM, ERP, HCM, and custom systems rather than being confined to one vendor's applications.

Anthropic has taken a more infrastructure-oriented approach. The Model Context Protocol (MCP), now hosted by the Linux Foundation, has become the de facto standard for agent-to-tool connections with over 10,000 active servers. The Claude Partner Network, backed by a $100 million investment, builds the implementation ecosystem through partnerships with Accenture, Deloitte, Cognizant, and other major system integrators. Anthropic's strategy is less about building a competing application platform and more about becoming the intelligence and connectivity layer that other platforms build on.

The structural advantage of the horizontal platforms is intelligence breadth. They offer the most capable reasoning models available, and their agents can orchestrate across vendor boundaries. For the cross-functional processes I described throughout this series (order-to-cash, procure-to-pay, hire-to-retire), horizontal platforms are the natural orchestration layer.

The structural weakness is the depth gap I explored in Article 3. Horizontal agents interacting with enterprise systems through APIs see only what the APIs expose. They lack the transaction-layer access, the business rule awareness, and the validation logic that native agents operate within. This gap is narrowing as protocols like MCP and A2A improve, but it has not closed.

The Infrastructure and Ecosystem Players: Microsoft and Google

Microsoft and Google occupy a distinctive position. They are not primarily application vendors (though both have significant application portfolios). They are infrastructure and ecosystem players whose AI strategies span compute, models, platforms, and tools.

Microsoft's strategy is the most layered. Azure provides the cloud infrastructure. OpenAI models (and increasingly Microsoft's own MAI models) provide the intelligence. Microsoft 365 Copilot and the new E7 Frontier Suite embed agents into the productivity tools that hundreds of millions of workers use daily. Entra Agent ID provides the identity layer. Agent 365 provides governance and management. Microsoft is the only vendor attempting to play at every layer of the Future Enterprise architecture simultaneously, from infrastructure through identity through applications.

Google brings its own strengths: Gemini's multimodal capabilities (text, images, video, audio) provide advantages in scenarios requiring unstructured data processing. The A2A protocol, which Google originated and contributed to the Linux Foundation, is becoming a standard for agent-to-agent communication. Google Cloud Platform provides the infrastructure, and Vertex AI Agent Builder provides the development platform.

The structural advantage of the infrastructure players is reach. Microsoft touches more enterprise workers through Microsoft 365 than any other vendor. Google touches more consumers and has deep strengths in data processing and search. Both can embed agent capabilities at a scale that specialized vendors cannot match.

The structural weakness is that neither Microsoft nor Google controls the deep business logic of the enterprise. Their agents interact with Oracle, Salesforce, ServiceNow, Zoho and SAP systems as external parties, subject to the same depth-versus-breadth trade-offs that affect all horizontal agents.

The Time-Horizon Analysis: Three Overlapping Phases

The center of gravity question is not static. It shifts over time as the technology matures, standards solidify, and enterprises build new capabilities. I see three overlapping phases, each favoring different vendors and different strategies. These phases are not sequential in the clean sense. Early adopters compress the timeline, and the boundaries between phases blur as the pace of agentic AI development accelerates. But the directional logic holds.

Phase 1: Data Wins (Now through 18 Months)

In the near term, the center of gravity sits with whoever controls the enterprise data. Agents are only as good as the data they can access, and the vendors who own the systems of record hold the most valuable data. This is the vertical integrators' moment.

Oracle's full-stack advantage (database through applications through agents) is strongest in this phase. An Oracle Fusion customer deploying Oracle's embedded agents gets immediate value because the agents operate directly on the data model they already run their business on. No integration required. No API translation. No data pipeline to build. The same logic applies to Salesforce within CRM and SAP within ERP/supply chain.

Horizontal platforms face their biggest challenge in Phase 1. Their agents need data to be useful, and getting access to enterprise data at the depth required for high-value workflows is slow, expensive, and often politically difficult. MCP and API connections provide access, but not the same depth of access that native agents enjoy.

For enterprises, the Phase 1 implication is clear: start with your existing vendors' native agents for the highest-value workflows within their domains. The quick wins are there, and the integration cost is lowest.

Phase 2: Intelligence Wins (12 Months through 3 Years)

As data connectivity matures (through MCP, A2A, and improving API ecosystems), the advantage shifts from who has the data to who has the best reasoning about the data. In this phase, the horizontal platforms and infrastructure players gain ground.

The reasoning gap between frontier models and vendor-embedded models is significant today and shows no sign of closing. OpenAI and Anthropic are investing billions in model capability. Vertical integrators are licensing or partnering for model access, not building frontier models themselves. As agents take on more complex, multi-step, cross-system workflows, the quality of reasoning becomes the differentiator.

This is also the phase where the Agent Service Bus (Article 2) and the third path of native agents with open interoperability (Article 3) become critical. The enterprises and vendors that have built the orchestration layer, the capability discovery, the intent resolution, and the protocol connectivity will be able to combine native depth with horizontal intelligence. Those who have not will face expensive retrofits.

Microsoft is particularly well positioned for Phase 2. Its combination of Azure infrastructure, OpenAI models, Copilot distribution, and Entra Agent ID gives it a play at every layer. The risk for Microsoft is complexity: maintaining coherence across this many products and strategies is an execution challenge that has tripped Microsoft up before.

For enterprises, the Phase 2 implication is: invest now in the interoperability layer. Demand A2A and MCP support from your vendors. Build the Agent Service Bus infrastructure. The enterprises that have this connective tissue in place when intelligence becomes the differentiator will be able to adopt the best reasoning models regardless of which vendor provides them.

Phase 3: Business Logic Wins (2-4 Years and Beyond)

In the long term, the center of gravity shifts to whoever controls the business logic: the rules, processes, constraints, and domain knowledge that define how an enterprise actually operates. This is the most consequential phase, and it is the one where the competitive landscape is most uncertain.

Here is the logic: data access will commoditize as protocols and integration platforms mature. Every agent will eventually be able to access every system's data through standardized connections. Model intelligence will also commoditize (or at least converge) as frontier capabilities diffuse through open-source models, smaller specialized models, and multi-model architectures. What will not commoditize is the business logic specific to each enterprise: the approval chains, the compliance rules, the pricing algorithms, the exception handling, the institutional knowledge about how the business actually works.

The vendors who control the deepest, most business-critical logic have a durable advantage. Today, that business logic lives inside Oracle, Salesforce, ServiceNow, Zoho and SAP applications. But here is the disruption: as agents become more capable, enterprises may choose to extract their business logic from vendor applications and run it on open platforms with better reasoning models, lower costs, or more flexible governance. The application, as I argued in Article 1, is a bundle of data model, business logic, UI, and workflow. Agents only need the data and the logic. If the logic can be separated from the application and expressed as agent-callable APIs, the traditional application vendor's lock-in weakens.

This is the existential question for the vertical integrators. Their long-term competitive position depends on whether business logic remains inseparable from their application platforms (which favors them) or becomes portable and platform-independent (which threatens them). Oracle's full-stack strategy, binding database, application, and agent into a unified architecture, is in part a bet that keeping business logic tightly coupled to the platform creates durable competitive advantage. The horizontal platforms are betting the opposite: that business logic will eventually be expressible in forms that any capable agent can execute.

For enterprises, the Phase 3 implication is the most important: document, structure, and own your business logic. Regardless of which vendor scenario plays out, the enterprises that have their business rules, processes, and domain knowledge well-documented and accessible (as high-quality, agent-callable APIs and machine-readable policy) will have optionality. They can run that logic on whatever platform provides the best combination of intelligence, cost, governance, and interoperability. The enterprises that leave their business logic buried inside vendor applications will be dependent on those vendors' agent strategies, for better or worse.

The Strategic Playbook

Across all three phases, certain strategic principles apply regardless of which vendors you use or which phase you are currently navigating. This is the playbook that synthesizes the entire Future Enterprise series into actionable guidance.

1. Treat identity and governance as foundational investments, not compliance exercises. Articles 4 and 5 made the case that agentic identity and governance are architectural layers, not security features. Every agent you deploy without proper identity, governance, and accountability is a liability you have not sized. Build these layers first, not after the agents are already in production.

2. Build the orchestration layer now. The Agent Service Bus (Article 2), with its five functions of capability discovery, intent resolution, contract negotiation, conflict arbitration, and message routing, is the infrastructure that makes a multi-vendor agent portfolio work. Without it, your native agents and external agents operate in parallel but never collaborate. The enterprises that have this infrastructure when Phase 2 arrives will have a structural advantage.

3. Demand interoperability from every vendor. Every agent you deploy should support open protocols: A2A for agent-to-agent communication, MCP for agent-to-tool connections, and emerging standards for agent identity and governance. If a vendor says their agents only work within their platform, you are building the next generation of integration silos. The third path (native agents with open interoperability) is the right architectural target.

4. Adopt a portfolio approach to agents. As I argued in Article 3, the native-versus-external question is not either/or. Use native agents for deep, high-volume, compliance-heavy workflows within a single vendor's domain. Use horizontal agents for cross-functional orchestration across vendor boundaries. Match the agent model to the process requirements, not the vendor pitch.

5. Plan pricing for the consumption era. Per-seat pricing is structurally breaking down (Article 6). Build metering infrastructure, develop internal cost allocation capabilities, and negotiate hybrid contracts that balance predictability with consumption alignment. Resist value-based pricing pitches until the attribution and measurement problems are solved.

6. Prepare for cross-organizational collaboration. The enterprise boundary is where the entire architecture gets stress-tested (Article 7). Build identity frameworks that can verify external agents. Develop governance policies for cross-boundary interactions. Establish Know Your Agent processes for evaluating the agents you interact with. Start with your most strategic external relationship and pilot cross-org collaboration there.

7. Own your business logic. This is the single most important long-term strategic action. Document your business rules, processes, and domain knowledge in forms that are machine-readable and platform-independent. Express them as agent-callable APIs. Build the institutional capability to maintain and evolve this logic independently of any vendor. In Phase 3, the enterprises that own their business logic will have options. The enterprises that have ceded it to vendor platforms will not.

Closing the Series

Over eight articles, we have mapped a structural transformation in enterprise technology. The traditional application model, built for human users interacting with bundled software through graphical interfaces, is giving way to an agent-native model where AI agents interact directly with data and business logic, orchestrate across systems, and collaborate with each other and with humans in increasingly sophisticated ways.

This transformation is not hypothetical. It is happening now, unevenly, with significant gaps in identity, governance, interoperability, and pricing that the industry has not yet resolved. The vendors are moving fast. The standards are emerging. The regulatory frameworks are taking shape. But the architectural foundations that enterprises build today will determine whether they can participate in this transformation or will be constrained by decisions made before the full picture was clear.

The center of gravity will shift. Data wins now. Intelligence wins next. Business logic wins in the long run. The enterprises that understand this progression and invest accordingly, building depth where depth matters, breadth where breadth matters, and the connective tissue that links them, will have the most capable, most governable, and most adaptable technology infrastructure in the market.

The future enterprise will not be defined by any single vendor's platform. It will be defined by the architecture that connects them all.

This concludes the Future Enterprise series. A comprehensive research report synthesizing the findings across all eight articles will be published by Arion Research later in 2026.

Everything we have discussed in this series so far has been, in one critical respect, the easy version of the problem. Enterprise Platforms, Agentic Platforms, Agent Service Buses, identity frameworks, governance architectures, and pricing models are all challenging to build. But they share one simplifying assumption: they operate within a single organization's boundary, under one set of policies, one identity provider, one governance framework, and one chain of accountability.

That assumption is about to break.

The next phase of enterprise AI is not agents working inside your organization. It is agents working across organizations: your procurement agent negotiating with your supplier's fulfillment agent, your compliance agent coordinating with your auditor's review agent, your customer's service agent interacting with your support agent, your logistics agent synchronizing with your carrier's routing agent. Every one of these scenarios crosses an organizational boundary, and every architectural layer we have discussed in this series gets harder at that boundary.

Cross-organizational agent collaboration is where the full Future Enterprise architecture gets stress-tested. Identity, governance, the Agent Service Bus, the native-versus-external debate, and even pricing models all need to work not just within your enterprise but between enterprises that do not share infrastructure, do not share policies, and may not share interests. This article examines what happens when agents leave the building, using three concrete scenarios to illustrate how each layer of the architecture adapts (or fails to adapt) at the organizational boundary.

Scenario 1: Supply Chain Negotiation

Consider a scenario that is already emerging in pilot deployments: a manufacturer's procurement agent needs to negotiate delivery terms with a supplier's fulfillment agent. The manufacturer wants to accelerate delivery of a critical component. The supplier has limited capacity. Both sides have agents authorized to negotiate within defined parameters.

In an intra-enterprise scenario, this is a workflow problem. The procurement agent and the fulfillment agent share the same identity provider, the same governance framework, and the same data model. The Agent Service Bus can route messages, resolve intent, and arbitrate conflicts because all participants are known entities operating under common rules.

Across the organizational boundary, every one of those assumptions fails.

Identity at the Boundary

The manufacturer's procurement agent needs to verify that it is actually communicating with the supplier's authorized fulfillment agent, and not a spoofed endpoint, a test instance, or an agent that lacks the authority to commit to delivery terms. As I discussed in Article 4, this requires federated agentic identity: the ability for Organization A's agent to present verifiable credentials that Organization B can validate without sharing a common identity provider.

Neither organization controls the other's identity infrastructure. The supplier has issued an identity to its fulfillment agent. The manufacturer needs to trust that identity. This requires a trust framework that spans the boundary: mutual recognition of identity providers, verifiable credential exchange, and a mechanism for revoking trust if either party's agent behaves outside agreed parameters. The emerging OIDC-A (OpenID Connect for Agents) proposal and SPIFFE-based workload identity offer pieces of this puzzle, but the federated layer that connects them across organizations is still nascent.

Governance Across Boundaries

The manufacturer's governance framework says the procurement agent can commit to a maximum 15% delivery premium without human approval. The supplier's governance framework says the fulfillment agent can accept rush orders up to a certain capacity threshold. These governance rules are internal to each organization. Neither side has visibility into the other's constraints.

Cross-organizational governance requires a negotiated layer of shared rules that sits above each organization's internal governance. This is not about one organization imposing its governance on the other. It is about establishing a bilateral (or multilateral) governance contract: agreed decision boundaries, escalation protocols, and dispute resolution mechanisms. Think of it as a machine-readable version of the terms and conditions that govern human business relationships, except that agents need to evaluate and enforce these terms in real time, at machine speed.

The Agent Service Bus Across Boundaries

Inside the enterprise, the Agent Service Bus (as I described in Article 2) handles capability discovery, intent resolution, contract negotiation, conflict arbitration, and message routing. Across organizations, each of these functions needs to work across separate infrastructure.

Capability discovery is the most tractable: the A2A protocol's Agent Cards already provide a mechanism for agents to advertise their capabilities to external parties. Intent resolution is harder because each organization may express the same business intent differently. Contract negotiation becomes genuinely complex when the agents have different authority levels, different governance constraints, and different optimization objectives. And conflict arbitration requires a neutral mechanism that neither party controls, or at minimum, a pre-agreed escalation path when the agents reach an impasse.

The supply chain scenario illustrates a critical point: cross-organizational agent collaboration does not require building a single, unified Agent Service Bus that spans all participants. It requires an interoperability layer that lets each organization's Agent Service Bus communicate with others. This is the federated model: each enterprise operates its own orchestration infrastructure, and a protocol layer bridges them.

Scenario 2: Partner Ecosystem Orchestration

The supply chain scenario involves two organizations with a direct commercial relationship. Partner ecosystem orchestration is more complex: multiple organizations, each with their own agents, coordinating on shared workflows where the relationships are multilateral rather than bilateral.

Consider a commercial real estate transaction. The buyer's agent, the seller's agent, the lender's agent, the title company's agent, the insurance company's agent, and the regulatory filing agent all need to coordinate a complex, multi-step process with dependencies, approvals, and compliance requirements that span every participant. No single organization controls the workflow. No single platform runs all the agents. Each participant has different identity infrastructure, different governance rules, and different risk tolerances.

Or consider a healthcare scenario: a provider's clinical agent recommending a treatment plan that requires prior authorization from a payer's authorization agent, verification of drug interactions from a pharmacy benefits agent, and coordination with a specialist referral agent at another provider. Patient data is involved, with HIPAA constraints, consent requirements, and data minimization rules that differ by participant.

These multi-party scenarios expose limitations that bilateral cross-org collaboration does not:

Multilateral trust. In a bilateral relationship, two organizations establish a trust agreement. In a partner ecosystem, every participant needs to trust every other participant's agents, or at minimum, trust the agents they interact with directly. The number of trust relationships grows combinatorially with the number of participants. Without a shared trust framework (such as a consortium-operated identity federation), the trust management overhead becomes unmanageable.

Workflow coordination without a central orchestrator. Intra-enterprise workflows have a clear orchestrator: the enterprise's Agent Service Bus or process engine. In a multi-party ecosystem, no single participant can be the orchestrator without creating a power asymmetry that other participants resist. The workflow needs to be coordinated through consensus or through a neutral intermediary that all parties trust.

Data sovereignty. Every participant in a multi-party workflow has data that it needs to share selectively and protect absolutely. The healthcare scenario makes this vivid: patient data flows through the workflow, but each participant has different access rights, different retention rules, and different compliance obligations. The agents need to collaborate on the workflow while respecting data boundaries that are not just technical but legal.

Accountability in multi-hop chains. When a workflow spans five organizations and one agent's action produces a bad outcome, the accountability chain (which I discussed in Article 5) becomes a multi-party problem. The delegation chain crosses organizational boundaries. Provenance records are distributed across participants. Determining responsibility requires a shared accountability framework that no participant has built.

Scenario 3: Customer-Vendor Agent Interactions

The third cross-org scenario is perhaps the most immediate: agents acting on behalf of customers interacting with agents acting on behalf of vendors. This is already happening in customer service, where AI agents handle the majority of support volume for some vendors. But the next phase extends far beyond support tickets.

Consider a customer's purchasing agent evaluating products from multiple vendors. The customer's agent queries each vendor's sales agent for pricing, availability, and configuration options. It compares responses, negotiates terms, and ultimately commits to a purchase. The vendor's agent responds to inquiries, adjusts pricing within authorized parameters, and fulfills the order.

This interaction is routine for human buyers and sellers. For agents, it raises distinctive challenges.

Asymmetric information and adversarial optimization. The customer's agent is optimizing for the buyer (lowest cost, best terms, fastest delivery). The vendor's agent is optimizing for the seller (highest margin, longest commitment, maximum volume). Both are acting rationally within their mandates. But unlike human negotiations, where social dynamics, relationship considerations, and imprecise communication introduce useful friction, agent-to-agent negotiation can devolve into rapid algorithmic optimization that produces outcomes neither party intended. Financial markets have seen this pattern with algorithmic trading: individually rational agents producing collectively irrational results.

The trust asymmetry. In most customer-vendor relationships, there is a power imbalance. The vendor controls the product, the pricing, and the service infrastructure. The customer's agent has limited ability to verify the vendor agent's claims independently. If the vendor's agent asserts that a product is in stock when it is not, or quotes a delivery timeline it cannot meet, the customer's agent may lack the context to challenge the assertion. Trust verification in customer-vendor agent interactions needs to account for this asymmetry.

Consent and transparency. When a customer's agent and a vendor's agent negotiate a contract, does the customer understand what their agent committed to? Does the vendor understand what their agent offered? The accountability governance layer needs to ensure that both principals (the customer and the vendor) have visibility into what their agents did on their behalf, and that neither agent exceeded its authority. This is not just good practice. Under emerging regulations like the EU AI Act, it is likely to become a legal requirement.

Customer-vendor agent interactions will likely become the most common form of cross-organizational agent collaboration simply because every enterprise is both a customer and a vendor. The governance, identity, and trust frameworks you build for one side of the relationship will need to work for the other side as well.

Platforms, Protocols, or Both?

Every cross-organizational scenario raises the same strategic question: will cross-org agent collaboration be mediated by dominant platforms or by open protocols? The answer, I believe, is both, but in different ways for different contexts.

The Platform Case

Dominant platforms have real advantages in cross-organizational scenarios. They can enforce common identity standards, common governance rules, and common data formats across all participants. A supply chain platform that hosts both buyer and supplier agents can mediate negotiations, enforce compliance, and maintain audit trails within a single environment. The trust problem is simplified because both parties trust the platform, even if they do not trust each other.

This is why industry-specific platforms are well-positioned to anchor cross-org agent collaboration in their verticals. A healthcare interoperability platform, a trade finance platform, a logistics orchestration platform: each of these can provide the shared infrastructure that makes cross-org collaboration tractable within a specific industry context. The platform becomes the trust anchor, the governance enforcer, and the interoperability layer for its vertical.

The Protocol Case

Open protocols have different advantages. They prevent any single platform from becoming a gatekeeper for cross-organizational collaboration. They allow organizations to maintain their own infrastructure while participating in shared workflows. They enable cross-industry scenarios that no single vertical platform covers.

The Agentic AI Foundation (AAIF), launched under the Linux Foundation in late 2025 with founding members from multiple major AI companies, is working to establish exactly this kind of open protocol infrastructure. A2A handles agent-to-agent communication. MCP handles agent-to-tool connections. Emerging protocols like AP2 handle agent payment transactions. Together, these protocols could provide the connective tissue for cross-org collaboration without requiring a central platform.

NIST's AI Agent Standards Initiative, announced in February 2026, reinforces this direction by fostering industry-led standards for interoperable and secure agent ecosystems. The initiative explicitly calls out open-source protocol development to prevent vendor lock-in.

The Hybrid Reality

The likely outcome is neither pure platform nor pure protocol. Dominant platforms will anchor specific industry verticals, providing the shared infrastructure, trust frameworks, and governance mechanisms that make cross-org collaboration practical for their ecosystems. Open protocols will connect across those verticals, enabling cross-industry scenarios and preventing any single platform from controlling the entire agent economy.

Think of it as analogous to how electronic commerce evolved. Industry-specific marketplaces (platforms) emerged for procurement, logistics, and financial services. But the internet protocols (HTTP, TCP/IP, SSL) connected across those marketplaces, and open standards for data exchange (EDI, XML, APIs) enabled interoperability that no single marketplace controlled. Agent ecosystems will likely follow a similar pattern: vertical platforms for depth, horizontal protocols for breadth.

The strategic implication for enterprises is to participate in both. Engage with the industry-specific platforms relevant to your business (they will provide the fastest path to cross-org agent collaboration in your vertical). But also demand open protocol support from every platform and agent you deploy (it will protect your ability to collaborate across industry boundaries and prevent platform lock-in).

The Role of Industry Consortia

Cross-organizational agent collaboration will not emerge spontaneously. It requires coordinated action on standards, trust frameworks, and governance models that no single vendor or enterprise can establish alone. This is where industry consortia play a critical role.

Several initiatives are already underway. The NIST AI Agent Standards Initiative is working on interoperability and security standards. The Agentic AI Foundation under the Linux Foundation is developing open protocol infrastructure. The OpenID Foundation's AI Identity Management Community Group is tackling federated agent identity. Singapore's IMDA has published the first government governance framework for agentic AI.

But what is missing is industry-specific consortium activity focused on the operational details of cross-org agent collaboration. The broad standards initiatives establish the protocol foundations. Industry consortia need to build on those foundations with sector-specific governance models, trust frameworks, data sharing agreements, and liability allocation mechanisms.

Financial services needs agent collaboration standards for trade settlement, KYC verification, and regulatory reporting. Healthcare needs standards for cross-provider agent coordination that respect HIPAA and patient consent. Manufacturing needs standards for supply chain agent negotiation that account for industrial safety and quality requirements. These are not problems that horizontal protocol bodies can solve because they require deep domain expertise and industry-specific regulatory knowledge.

The enterprises that participate in shaping these industry standards will have a structural advantage: they will understand the cross-org collaboration framework before it becomes mandatory, and they will influence the rules that their competitors will also have to follow.

Preparing for the Cross-Org Future

Cross-organizational agent collaboration is not a distant scenario. Supply chain agent pilots are running now. Customer-vendor agent interactions are already in production for support and service workflows. The pace is accelerating as agent capabilities improve and organizational confidence grows. Here is how to prepare:

Build your architecture with the boundary in mind. Every architectural decision you make today about agent identity, governance, and orchestration will either support or obstruct cross-org collaboration tomorrow. Ask yourself: can my identity framework verify external agents? Can my governance layer enforce rules for cross-boundary interactions? Can my Agent Service Bus communicate with an external orchestrator? If the answer is no, you are building for a world that is already passing.

Start with your most strategic external relationship. Do not try to enable cross-org agent collaboration with every partner simultaneously. Identify your most strategic bilateral relationship (your largest supplier, your most important customer, your critical logistics partner) and pilot cross-org agent collaboration there. The lessons from one well-structured pilot will inform your broader architecture more effectively than any theoretical planning exercise.

Engage with standards bodies now. The NIST AI Agent Standards Initiative, the Agentic AI Foundation, and the OpenID Foundation's AI Identity group are all in their formative stages. Enterprise participation in these processes matters. The standards they produce will shape how cross-org agent collaboration works for the next decade. If you wait until the standards are published to engage, you will be implementing rules you had no role in defining.

Develop your KYA process. Begin defining what you would need to know about an external agent before allowing it to interact with your systems. What identity credentials do you require? What governance framework must the agent operate under? What accountability chain must be demonstrable? What liability allocation is acceptable? Answering these questions now will accelerate your readiness when cross-org collaboration becomes a commercial requirement.

Assume the hybrid model. Plan for a world where industry-specific platforms anchor your primary vertical collaborations and open protocols connect you across verticals. Avoid committing exclusively to a single platform for all cross-org collaboration. Invest in open protocol support for your agent infrastructure to preserve optionality as the ecosystem evolves.

Throughout this series, I have argued that the Future Enterprise is not just a new technology stack. It is a new operating model where AI agents handle increasingly autonomous, consequential work. Cross-organizational collaboration is where that operating model meets its hardest test. Every layer of the architecture, from identity to governance to orchestration to pricing, must work not just within the controlled environment of a single enterprise but across the messy, adversarial, trust-deficient space between enterprises.

The organizations that solve this will not just have better technology. They will have access to a new category of business capability: agent-mediated collaboration that operates at machine speed across every significant business relationship. The organizations that do not solve it will find their agents powerful within their walls and useless beyond them.

The enterprise boundary has always been where coordination gets hard. In the age of agents, it is where coordination gets transformative.

Next in the series: "Where Does the Center of Gravity Land?" the concluding article that synthesizes the entire Future Enterprise framework and examines whether data, intelligence, or business logic will ultimately determine who controls the enterprise stack.

Enterprise software has been priced per seat for roughly three decades. The model is simple, predictable, and deeply embedded in how both vendors and buyers plan their budgets. A company with 10,000 employees buys 10,000 licenses. Headcount goes up, spend goes up. Headcount goes down, spend goes down. Procurement teams understand it. CFOs can forecast it. Vendors can build revenue models around it.

AI agents break this model in a way that no previous technology shift has.

The reason is structural: per-seat pricing assumes that value delivery is tied to the number of humans using the software. Agents sever that link. A single agent can do the work that previously required dozens of human users. An enterprise that deploys procurement agents, customer service agents, and financial close agents may need fewer seats, not more, while extracting significantly more value from the software. The vendor's revenue goes down precisely when the customer's value goes up. That is not a pricing challenge. It is an economic contradiction at the core of the business model.

The industry's response has been to experiment: consumption-based pricing, credit systems, per-conversation charges, per-resolution fees, and (the most ambitious claim) value-based pricing. Each approach solves some problems while creating others. But one of these approaches, value-based pricing, is receiving attention disproportionate to its viability. It sounds like the right answer. In practice, it almost never works.

The Per-Seat Collapse

To understand where pricing is heading, it helps to understand exactly why per-seat is failing. The breakdown is not gradual. It is structural.

In a traditional enterprise software deployment, one human user equals one unit of consumption. The user logs in, performs work, and the license covers the capacity they consume. The cost structure is roughly aligned: more users mean more compute, more storage, and more support burden for the vendor. The price scales with the cost to serve.

Agents destroy this alignment in three ways.

First, agents decouple value from headcount. When an enterprise deploys an agent that automates accounts payable processing, the number of human AP clerks using the software goes down. Under per-seat pricing, the vendor's revenue drops even though the software is delivering more value than before. The enterprise is getting better outcomes with fewer seats. The vendor is getting punished for making the customer more productive.

Second, agents have entirely different cost structures. A human user might log in for eight hours, run a few reports, and enter some transactions. An agent might execute thousands of transactions per hour, make hundreds of API calls, and consume significant compute resources for inference. The cost to serve one agent can exceed the cost to serve dozens of human users, but the per-seat model charges the same flat rate regardless. Vendors absorb the cost difference, which is not sustainable at scale.

Third, agents blur the definition of a "user." Is an agent a user? Is a sub-agent spawned by another agent a separate user? If an orchestrating agent delegates work to three specialized agents, is that one seat or four? If an agent from a horizontal platform invokes a native agent inside an application (the third-path scenario I described in Article 3), who is the licensee? Per-seat pricing cannot answer these questions because it was never designed to.

The market is already responding. Recent industry surveys show that 38% of SaaS companies now use some form of usage-based pricing, up from 27% in 2023. Gartner forecasts that by 2030, at least 40% of enterprise SaaS spend will shift toward usage, agent, or outcome-based pricing models. The per-seat era is not ending overnight, but the structural forces pulling against it are accelerating.

The Seductive Logic of Value-Based Pricing

If per-seat pricing is breaking down, the intuitive replacement seems obvious: charge based on the value the software delivers. If an agent saves the enterprise $2 million per year in labor costs, charge a percentage of that savings. If an agent generates $500,000 in new revenue, take a share. Align the vendor's revenue with the customer's outcomes, and both sides win.

This is value-based pricing, and it has been a staple of enterprise software thought leadership for years. Consulting firms advocate for it. Pricing strategists model it. Vendor CEOs announce it at conferences. And in practice, it almost always collapses under its own weight.

The failure is not about intent. It is about mechanics. Value-based pricing requires solving four problems simultaneously, and the difficulty of each one is routinely underestimated.

Problem 1: The Attribution Problem

Value-based pricing requires attributing a specific business outcome to a specific piece of software. In an enterprise environment, this is extraordinarily difficult. Did revenue increase because of the AI agent's lead qualification, or because of the new marketing campaign, or because a competitor stumbled, or because the sales team changed their pitch? Was the cost reduction driven by the procurement agent, or by the supplier renegotiation the human team conducted, or by the commodity price drop that had nothing to do with either?

Business outcomes are the product of many inputs. Isolating the contribution of any single tool or agent requires controlled experiments that are impractical in production environments. Recent surveys confirm this: nearly half of enterprise buyers report struggling to define clear, measurable outcomes for AI pricing, and a quarter acknowledge that outcomes depend on factors entirely outside the vendor's control.

The attribution problem is not solvable with better analytics. It is a structural feature of complex business environments. Multiple causal factors interact, and there is no clean way to decompose the outcome into vendor-attributable and non-vendor-attributable components.

Problem 2: The Measurement Problem

Even if you could solve attribution, you need to agree on how to measure value. And measurement, it turns out, is deeply subjective.

What counts as a "resolution" when a customer service agent handles a ticket? If the agent answers the customer's question but the customer calls back two days later with a follow-up, was the first interaction a resolution? What about an agent that deflects a call by providing a self-service link that the customer never clicks? The vendor and buyer have structurally different incentives when defining measurement. The vendor wants to count as many successful outcomes as possible. The buyer wants to count as few as possible. Every measurement definition becomes a negotiation, and every edge case becomes a dispute.

This problem compounds over time. As agents take on more complex, multi-step workflows, the definition of "value" becomes increasingly ambiguous. A procurement agent that negotiates a better price on a contract delivered value. But what if the supplier's delivery performance degrades as a result of the price pressure? The short-term cost savings are measurable. The long-term quality impact is not, at least not in the same time frame. Which version of "value" does the pricing model use?

Problem 3: The Adversarial Dynamics Problem

Value-based pricing creates an adversarial relationship between vendor and buyer at exactly the moment when the relationship should be collaborative. The vendor is incentivized to maximize the measured value (by inflating metrics, expanding the definition of outcomes, or claiming credit for improvements that have multiple causes). The buyer is incentivized to minimize it (by underreporting results, attributing improvements to other factors, or gaming the measurement criteria).

In traditional per-seat or consumption-based pricing, the vendor and buyer can focus on making the software work better. In value-based pricing, they spend time arguing about how much value was delivered. The pricing model consumes management attention and legal review cycles that could be directed toward actually improving the deployment.

This adversarial dynamic also makes renewals contentious. In a per-seat model, the renewal conversation is about user count and feature needs. In a value-based model, every renewal is a negotiation about whether the software delivered enough value to justify the price. If the business had a bad quarter for reasons unrelated to the software, the vendor's revenue drops. If the business had a great quarter, the vendor claims credit for outcomes they may not have driven. Neither party is wrong. Both are acting rationally within the incentive structure. The structure itself is the problem.

Problem 4: The Predictability Problem

CFOs need to forecast software spend. Budget cycles require predictable cost structures. Value-based pricing, by definition, makes costs unpredictable because they are tied to business outcomes that fluctuate with market conditions, competitive dynamics, and dozens of other variables the enterprise cannot control.

This matters more than pricing theorists typically acknowledge. Enterprise procurement decisions are not purely rational optimizations. They are organizational processes embedded in annual budget cycles, approval hierarchies, and multi-year planning horizons. A pricing model that delivers better theoretical economics but cannot be forecasted within a reasonable margin is often rejected in favor of a less efficient but more predictable alternative. Recent vendor experience confirms this: major platform vendors that initially explored outcome-based pricing have reported that customers pushed back in favor of predictable per-seat or credit-based models, particularly as AI pilots moved from experimentation into production.

What Actually Works: The Consumption Spectrum

If per-seat is structurally broken and value-based is practically unworkable, where does that leave enterprise software pricing? The answer emerging across the industry is a spectrum of consumption-based models, each suited to different types of agent work.

Credit-Based Systems

The most common approach today is the credit or token system. Customers purchase a pool of credits, and agent actions consume credits at rates that reflect the underlying compute cost. Simple actions (data lookups, routine classifications) consume fewer credits. Complex actions (multi-step reasoning, document generation, cross-system orchestration) consume more.

Credit systems solve the vendor's cost problem: revenue scales with the actual resources consumed. They also provide reasonable buyer predictability: credits can be purchased in blocks, usage can be monitored against budgets, and overages can be capped or throttled. The weakness is transparency. Customers often struggle to understand why one action costs 3 credits and another costs 30, which can erode trust if the credit pricing feels arbitrary.

Transaction-Based Pricing

A more granular approach charges per completed transaction: per invoice processed, per customer interaction resolved, per document analyzed, per workflow executed. This model is gaining traction in well-defined domains where the unit of work is clear and countable.

Transaction-based pricing has an attractive alignment property: the customer pays when the agent does work, and the price is tied to a business-relevant unit rather than an abstract credit. The challenge is defining the transaction boundary. A customer service agent that handles an inquiry, escalates to a specialist agent, and then follows up with the customer has completed one customer interaction or three agent transactions, depending on how you count. And the counting methodology directly affects the bill.

Hybrid Models

The approach that appears most likely to dominate enterprise AI pricing is the hybrid model: a platform fee (per-seat or flat rate) that covers base access, combined with a consumption component that scales with agent activity. Industry data suggests that 43% of software companies already use hybrid models, with adoption projected to reach 61% by end of 2026.

Hybrid models balance multiple interests. The platform fee gives the vendor predictable base revenue and gives the buyer predictable base cost. The consumption component aligns incremental spending with incremental value. The buyer knows their minimum spend, the vendor captures upside when agents are heavily used, and neither side is forced to agree on how much "value" was delivered.

The most effective hybrid models pair the platform fee with an embedded usage allowance (a generous baseline of included agent actions) and a transparent, per-unit charge for usage beyond the baseline. This structure eliminates the budget anxiety that pure consumption models create while avoiding the economic contradiction of pure per-seat pricing.

The Metering Infrastructure Gap

Whichever pricing model an enterprise adopts, it requires something that most organizations do not have: granular, reliable metering of agent activity. This is the infrastructure layer in the Future Enterprise architecture that I identified as "Metering" in the first article of this series, and it is more important than most vendors acknowledge.

In a per-seat world, metering is trivial. Count the users. In a consumption world, metering requires tracking every agent action at a level of detail that supports billing, cost allocation, capacity planning, and governance. How many API calls did this agent make? How much inference compute did it consume? How many transactions did it process? Which department or project should be charged? Were the actions routine or did they involve complex reasoning that consumed disproportionate resources?

This is not just a billing problem. It is an organizational management problem. When agents consume shared resources (model inference capacity, API rate limits, data pipeline bandwidth), the enterprise needs to allocate costs and manage contention. Without metering, the enterprise has no way to do charge-back to business units, no way to identify agents that are consuming disproportionate resources, and no way to optimize the cost of its agent portfolio.

The metering infrastructure also feeds directly into governance. As I discussed in the previous article, behavioral governance requires visibility into what agents are doing. The metering layer provides that visibility. If the governance layer detects that an agent's activity has spiked by 10x in the past hour, the metering data tells you whether that is a legitimate workload increase or an anomaly that warrants investigation.

Building metering infrastructure is not glamorous, but it is a prerequisite for any pricing model beyond per-seat. Enterprises that deploy agents without metering will find themselves unable to forecast costs, allocate expenses, or negotiate effectively with vendors at renewal time.

Strategic Implications for Enterprise Buyers

The pricing transition creates both risks and opportunities for enterprise buyers. Here is how to navigate it:

Resist the value-based sales pitch. When a vendor proposes value-based pricing, recognize that the alignment sounds perfect in a slide deck and falls apart in practice. Ask the vendor: how will we attribute outcomes? What happens when the measured value drops for reasons unrelated to the software? Who defines the measurement methodology, and what happens when we disagree? If the vendor cannot provide clear, contractual answers to these questions, the model will become a source of friction rather than alignment.

Demand metering transparency. In any consumption-based model, insist on granular, real-time visibility into what you are being charged for and why. The metering data should be available through APIs and dashboards, not just in monthly invoices. If you cannot see what you are consuming, you cannot manage what you are spending.

Negotiate the hybrid structure carefully. In hybrid models, the balance between the platform fee and the consumption component determines your economics. A high platform fee with a low consumption rate favors heavy users. A low platform fee with a high consumption rate favors light users. Model your expected agent usage patterns before negotiating, and build in periodic rebalancing provisions as your agent portfolio evolves.

Build internal cost allocation capabilities. As agent costs shift from predictable per-seat to variable consumption, the enterprise needs mechanisms to allocate those costs to the business units and projects that benefit from the agents. This requires the metering infrastructure discussed above, combined with cost allocation rules that reflect how agents are shared across the organization.

Plan for pricing model migration. The industry is in the early stages of a multi-year pricing transition. Contracts signed today under per-seat models will likely be renegotiated under different terms within two to three years. Build flexibility into your agreements: shorter terms, renegotiation triggers tied to agent deployment thresholds, and provisions for migrating to consumption-based models when the vendor introduces them.

Watch for the lock-in effect. Consumption-based pricing creates a subtler form of lock-in than per-seat licensing. When your organization has built workflows, trained agents, and accumulated usage patterns on a particular platform, switching costs are embedded in the operational dependency, not just the contract. Factor this into your vendor selection and diversification strategy.

The enterprise software pricing model is in the early stages of a structural reset. Per-seat is breaking down under the weight of agents that decouple value from headcount. Value-based pricing sounds like the logical replacement but fails under the weight of attribution, measurement, adversarial dynamics, and unpredictability. Consumption-based and hybrid models are emerging as the practical middle ground, offering reasonable alignment without requiring vendor and buyer to agree on exactly how much value was delivered.

The transition will not be clean or fast. Vendors are experimenting, buyers are cautious, and the industry has not yet converged on standard practices. But the direction is clear: the future of enterprise software pricing will be driven by what agents do, not by how many humans use the software. The enterprises that prepare for this shift, by building metering infrastructure, developing internal cost allocation capabilities, and negotiating flexible agreements, will be better positioned to capture the value of their agent investments without being surprised by the bill.

Next in the series: "Where Does the Center of Gravity Land?" examining whether data, intelligence, or business logic will ultimately determine who controls the future enterprise stack, and what that means for every vendor and buyer in the market.

Ask any enterprise software vendor whether they have governance for their AI agents, and the answer is almost always yes. They will point to role-based access controls, audit logs, compliance dashboards, and security monitoring. They will describe guardrails that prevent agents from accessing unauthorized data or executing prohibited actions. They will reference their SOC 2 certification and their alignment with NIST frameworks.

All of that is necessary. None of it is sufficient.

The problem is not that enterprises lack security and compliance controls for their agents. The problem is that they are treating security and compliance as if they were governance. They are not the same thing. Security answers the question: is this agent protected from threats? Compliance answers the question: does this agent meet regulatory requirements? Governance answers a broader set of questions: should this agent be taking this action, under these circumstances, with this level of autonomy, given the current business context, risk posture, and organizational policy? Security and compliance are components of governance. They are not substitutes for it.

Throughout this series, I have identified governance as one of the critical vertical services in the Future Enterprise architecture, a service that spans the Enterprise Platform, the Agentic Platform, and the Collaboration layer. In the previous article, I examined why agentic identity is the prerequisite that most vendors are neglecting. Identity tells you who the agent is and what it is authorized to do. Governance tells you whether it should, right now, in this context, given everything the organization knows about risk, policy, and business priorities.

This article lays out what a purpose-built agentic governance architecture looks like: the layers, the capabilities, and the design principles that distinguish real governance from the security-plus-compliance approach that most vendors are offering today.

Why Security and Compliance Are Not Enough

To understand the governance gap, consider a concrete scenario. An enterprise procurement agent has proper security controls: it authenticates via the organization's identity provider, it has role-based access limited to procurement functions, and its actions are logged in an audit trail. It also meets compliance requirements: it operates within the organization's data residency rules, it follows the approval thresholds defined in corporate policy, and it generates the documentation required by auditors.

Now the agent encounters this situation: a supplier offers an accelerated delivery option at a 15% premium. The agent has the authority to approve the premium (it falls within its spending threshold). It has the access to modify the purchase order (it has the right role). The action is compliant (the premium is within policy limits and properly documented). But should it take the action?

The answer depends on context that security and compliance cannot evaluate. Is the organization under a cost-reduction mandate this quarter? Is this supplier on the risk watchlist for delivery reliability? Has the requesting department already exceeded its discretionary spending budget? Is there a competing purchase order from another department for the same supplier capacity? Did a similar accelerated delivery decision last month result in quality issues?

A human procurement manager would factor in all of this context. They would check with finance, consult the supplier relationship history, consider the broader organizational priorities, and make a judgment call. An agent operating within a security-and-compliance-only framework has no mechanism for any of this. It sees a valid action within its authorized scope and executes it. The action is secure, compliant, and wrong.

This is the governance gap. Security controls access. Compliance enforces rules. Governance exercises judgment. And as agents take on more autonomous, consequential actions, the absence of judgment becomes increasingly expensive.

The Five Layers of Agentic Governance

A purpose-built agentic governance architecture requires five distinct layers, each addressing a different aspect of how agents are managed, monitored, and directed. Most enterprises today have pieces of the first two layers. Almost none have built the remaining three.

Layer 1: Access Governance

This is the layer most enterprises have in some form. Access governance controls what agents can reach: which systems, which data, which APIs, which tools. It includes authentication (verifying the agent's identity), authorization (defining what the agent is permitted to do), and access management (enforcing those permissions at runtime).

Access governance is necessary but insufficient on its own for the same reason that giving an employee a building keycard does not constitute managing their work. Knowing what an agent can access tells you nothing about whether it should access those resources for a particular task, at a particular time, under particular circumstances. Access governance defines the boundaries. It does not govern the decisions made within those boundaries.

Layer 2: Compliance Governance

Compliance governance ensures that agent actions meet regulatory and policy requirements. It includes data residency enforcement, retention and deletion policies, regulatory reporting, industry-specific rules (financial services, healthcare, government), and documentation requirements for auditors.

This layer is well understood because it mirrors what enterprises already do for human workers and traditional software systems. The challenge with agents is scale and speed: an agent may execute thousands of compliance-relevant actions per day, and the compliance governance layer needs to evaluate each one without creating a performance bottleneck.

Singapore's IMDA Model AI Governance Framework for Agentic AI, released at Davos in January 2026, provides useful guidance here. It recommends that organizations assess and bound risks upfront by selecting appropriate use cases and placing limits on agents' autonomy, access to tools, and access to data. This is sound compliance governance. But it is still only one layer of what enterprises need.

Layer 3: Behavioral Governance

This is where most enterprise governance architectures have a significant gap. Behavioral governance monitors and constrains how agents act, not just what they can access or whether their actions are compliant. It addresses questions like: is the agent's decision-making pattern consistent with organizational intent? Is the agent exhibiting drift from its expected behavioral baseline? Is the agent's confidence level appropriate for the action it is about to take?

Behavioral governance requires several capabilities that most enterprises have not built:

Confidence thresholds. Agents should not treat all decisions equally. A procurement agent approving a routine reorder from an established vendor is a low-uncertainty decision. The same agent evaluating a new supplier in a market it has not operated in before is a high-uncertainty decision. Behavioral governance sets confidence thresholds that determine when an agent can act autonomously, when it should seek additional information, and when it must escalate to a human. The thresholds should be dynamic, adjusting based on the stakes, the novelty of the situation, and the agent's track record.

Behavioral baselines. Over time, each agent develops observable patterns: typical transaction sizes, common decision paths, characteristic interaction patterns. Behavioral governance establishes these baselines and flags deviations. This is different from security anomaly detection, which looks for malicious behavior. Behavioral governance looks for well-intentioned behavior that has drifted outside the organization's expectations, which is often a more subtle and more costly problem.

Goal alignment verification. Agents optimize for objectives. If those objectives are poorly specified, or if the agent's optimization produces unintended side effects, the results can be technically correct but organizationally harmful. A customer service agent optimizing for case resolution speed might close tickets prematurely. A scheduling agent optimizing for utilization might create unsustainable workloads. Behavioral governance continuously verifies that the agent's actions align with the organization's actual goals, not just the metrics the agent was given.

Guardrail agents. An emerging pattern is the deployment of specialized agents whose sole purpose is to monitor other agents. These guardrail agents evaluate inputs, outputs, and reasoning chains in real time, applying governance policies that would be too complex or too dynamic to encode as static rules. The guardrail agent pattern is promising but introduces its own governance question: who governs the guardrail agent?

Layer 4: Contextual Governance

Contextual governance brings organizational context into agent decision-making. This is the layer that addresses the procurement scenario I described earlier, where the action is authorized and compliant but does not account for broader business conditions.

Contextual governance requires that agents have access to (or can query) real-time organizational context: current budget status, strategic priorities, risk posture, related decisions being made elsewhere in the organization, and historical outcomes from similar decisions. It also requires a policy engine that can evaluate this context against organizational rules and preferences, not as a simple lookup but as a dynamic assessment that weighs multiple factors.

This is where governance connects to the architecture I described in the first article of this series. The Context and Memory vertical service in the Future Enterprise framework exists precisely to make this kind of contextual governance possible. Without a shared context layer that agents can query, each agent makes decisions in isolation, unaware of the broader organizational state. Contextual governance is the mechanism that turns a collection of independent agents into a coordinated organizational capability.

The California Management Review recently published research on the "Agentic Operating Model" that describes a similar concept, calling it the "Coordination Layer" that ensures agents do not make conflicting decisions or duplicate effort. Whether you call it contextual governance or coordination, the core requirement is the same: agents need organizational awareness, not just task awareness.

Layer 5: Accountability Governance

The final layer connects agent actions to organizational responsibility. As I discussed in the previous article on agentic identity, accountability requires more than logging. It requires a binding chain that connects every agent action to the authorization that permitted it, the delegation that initiated it, the policy that governed it, and the human or organizational entity that is ultimately responsible.

Accountability governance addresses several specific requirements:

Decision provenance. For every significant agent action, the governance layer must capture not just what the agent did, but why it did it: what inputs it considered, what alternatives it evaluated, what confidence level it had, and what policies it applied. This provenance record must be tamper-evident and stored at a granularity that satisfies both internal audit requirements and external regulatory scrutiny.

Delegation chain tracking. When Agent A delegates a task to Agent B, and Agent B invokes a tool that triggers Agent C, the accountability governance layer must maintain the full chain. If Agent C produces an incorrect result, the organization needs to trace back through the delegation chain to understand where the error originated and who had oversight responsibility at each step.

Outcome attribution. When an agent's decision produces a measurable business outcome (positive or negative), the governance layer needs to attribute that outcome to the agent, the policy that governed it, and the human who authorized the agent's operation. This attribution feeds back into the behavioral governance layer, informing future confidence thresholds and authority levels.

Regulatory evidence. With California's AB 316 foreclosing the "AI did it" defense and the EU's Product Liability Directive classifying AI as a product subject to strict liability, accountability governance is not optional. The governance layer must produce evidence that meets legal standards of proof, not just internal reporting standards.

Design Principles for Agentic Governance

Building these five layers is a significant undertaking. Based on the analysis above and the patterns emerging across early enterprise deployments, I see six design principles that should guide the architecture:

Governance as infrastructure, not afterthought. Governance cannot be a feature bolted onto agent platforms after deployment. It needs to be an architectural layer that agents are designed to operate within from the start. This means governance APIs that agents call before taking actions, governance context that agents factor into decisions, and governance policies that are machine-readable and enforceable at runtime. The pattern is analogous to how modern applications are built with security as a design principle, not a retrofit.

Continuous, not periodic. Traditional governance operates on review cycles: quarterly audits, annual compliance assessments, periodic policy reviews. Agentic governance must be continuous. Agents make decisions in milliseconds, and governance evaluation needs to happen at the same speed. This does not mean every action requires a full governance assessment, but it does mean the governance layer must be able to evaluate risk and context in real time and intervene when necessary.

Adaptive, not static. Static governance rules cannot keep pace with the dynamic environments agents operate in. The governance architecture needs to adapt: adjusting authority levels based on agent performance, modifying thresholds based on organizational context, and evolving policies as the organization learns from agent outcomes. This requires a feedback loop between accountability governance (which captures outcomes) and behavioral governance (which sets parameters).

Cross-layer, not siloed. Governance must span the full Future Enterprise architecture. An agent's governance posture in the Enterprise Platform (where it accesses data) must be consistent with its governance posture in the Agentic Platform (where it reasons and acts) and the Collaboration layer (where it interacts with humans and other agents). Siloed governance, where each platform layer has its own governance framework, creates gaps at the boundaries.

Observable, not opaque. Every governance decision (and every governance failure) must be visible to the humans responsible for the agent's operation. This includes real-time dashboards showing agent activity and governance interventions, alerting systems for policy violations and behavioral anomalies, and reporting tools that give executives, auditors, and regulators the visibility they need. If you cannot see how your agents are being governed, you are not governing them.

Federated, not centralized. Large enterprises will not have a single governance authority for all agents. Business units, geographies, and functional domains will have different governance requirements. The governance architecture needs to support federation: a shared framework with common standards that allows distributed governance decisions. This mirrors how enterprises manage human governance today, with corporate policies that set the floor and business unit policies that add specificity.

The Organizational Dimension

Architecture alone is not enough. Agentic governance also requires organizational structures and processes that most enterprises have not yet created.

Agent oversight roles. Someone needs to be responsible for how agents operate within each business function. This is not the IT security team (they own access governance) and it is not the compliance team (they own compliance governance). Behavioral and contextual governance require business domain expertise. The emerging pattern is an "agent operations" function, sometimes embedded within business units and sometimes centralized, that owns the governance of agent behavior and decision quality.

Governance policy development. Machine-readable governance policies do not write themselves. Organizations need processes for translating business intent, risk tolerance, and organizational values into policies that agents can evaluate at runtime. This requires collaboration between business leaders (who define the intent), governance specialists (who translate intent into policy), and technical teams (who encode policies in machine-readable formats).

Incident response for agent failures. When an agent makes a bad decision, the organization needs a response process that goes beyond traditional IT incident management. Agent incidents require tracing the decision provenance, understanding the governance context at the time of the decision, determining whether the failure was a policy gap (the governance rules were incomplete), a behavioral drift (the agent operated outside its baseline), or a contextual failure (the agent lacked organizational awareness). Each root cause requires a different remediation.

Continuous learning loops. The most effective agentic governance architectures will not be the most rigid. They will be the ones that learn fastest. Every agent decision, every governance intervention, and every outcome feeds data back into the governance system. Over time, this data improves confidence thresholds, refines behavioral baselines, and sharpens contextual policies. Organizations that build these learning loops into their governance architecture will see their agent populations become more reliable and more autonomous over time. Organizations that rely on static rules will see their governance become increasingly brittle.

Getting Started: A Pragmatic Approach

Building a five-layer governance architecture from scratch is not realistic for most enterprises. Here is a pragmatic sequence:

• Phase 1: Close the visibility gap. Before you can govern agents, you need to see them. The immediate priority for most enterprises is a complete inventory: how many agents are deployed, what authority do they have, what data can they access, and what decisions are they making. Research suggests that only about a quarter of organizations have full visibility into their agent landscape. Start there.

• Phase 2: Implement graduated authority. Move from binary access controls to the bounded autonomy model. Classify agent decisions by risk level and implement the tiered authority model described in the sidebar. This gives you a practical framework for expanding agent autonomy safely as you build out the governance layers.

• Phase 3: Build behavioral monitoring. Deploy the infrastructure to establish behavioral baselines and detect drift. This does not require a complete behavioral governance layer on day one. Start with the highest-risk agents and the highest-stakes decisions. Expand coverage as you learn what deviations matter.

• Phase 4: Add organizational context. Connect your agents to the context they need: budget data, strategic priorities, risk signals, and the decisions being made by other agents. This is the hardest layer to build because it requires integration across organizational silos, but it is also where the governance architecture starts to produce real business value beyond risk mitigation.

• Phase 5: Close the accountability loop. Implement the full provenance and attribution chain. This is where governance meets the regulatory requirements that are rapidly taking shape, with the EU AI Act's full enforcement for high-risk systems coming in August 2026 and California's AB 316 already in effect.
  
  

The enterprise software industry is at an inflection point. Agents are moving from experimental pilots to production workloads, and the governance infrastructure has not kept pace. The organizations that invest in purpose-built agentic governance now will have a structural advantage: their agents will be more reliable, more trusted, and more capable of taking on high-value work. The organizations that treat governance as a compliance checkbox will find their agent deployments stuck at low autonomy levels, unable to deliver the business value that justified the investment in the first place.

Security and compliance are necessary foundations. But they are the floor, not the ceiling. What enterprises need is governance that can exercise judgment at machine speed, adapt to changing context, and maintain accountability across increasingly complex agent ecosystems. Building that governance architecture is not glamorous work. It is, however, the work that will determine whether the agentic enterprise is trustworthy enough to scale.

Next in the series: "The Pricing Paradox" examining how AI agents are breaking enterprise software pricing models, why value-based pricing fails in practice, and what consumption-based alternatives are emerging.

Here is a question that should keep every enterprise technology leader up at night: when an AI agent negotiates a contract term on behalf of your company, who signed it?

Not which human approved the workflow. Not which system the agent ran on. Who, or what, is the verifiable, auditable, legally attributable entity that committed your organization to that term? Right now, in almost every enterprise deploying AI agents, the honest answer is: nobody knows.

This is not a theoretical concern. Enterprises are deploying agents that process invoices, modify vendor contracts, adjust pricing, and communicate with customers. Each of these actions carries legal and financial consequences. Yet the identity infrastructure that governs these agents (the mechanisms for establishing who an agent is, what it is authorized to do, who it acts on behalf of, and how its actions can be traced) is either absent or borrowed from frameworks designed for a different era.

In the first article in this series, I outlined the Future Enterprise architecture and identified Governance as one of the critical vertical services that spans the entire stack. In the third article, I explored the trade-offs between native and external agents, and flagged trust and accountability as one of the unresolved challenges of the hybrid model. Agentic identity sits at the intersection of both. It is the architectural prerequisite that makes governance enforceable and multi-agent collaboration trustworthy. And it is the layer that most vendors are neglecting.

Why Human Identity Frameworks Do Not Work for Agents

Enterprise identity management has evolved significantly over the past two decades. SAML gave us federated single sign-on. OAuth 2.0 and OpenID Connect gave us delegated authorization and portable user identity. Zero Trust architectures moved us from perimeter-based security to continuous verification. These are mature, battle-tested frameworks. And none of them were designed for what AI agents actually do.

The problem is not that existing identity standards are bad. It is that they rest on assumptions that do not hold in an agentic world.

Assumption 1: The principal is human. OAuth and OIDC are built around human users who authenticate interactively (entering credentials, approving consent screens, responding to MFA challenges). Agents do not authenticate this way. They operate continuously, spawn sub-agents, and act at machine speed without a human in the loop for each action. Treating an agent as just another "service account" misses the point. Service accounts have static permissions. Agents make dynamic decisions about what to do next based on context that changes in real time.

Assumption 2: Sessions are bounded. Human sessions have clear start and end points. You log in, you work, you log out. Agents may run for hours, days, or indefinitely. They may spawn child agents that inherit some permissions but not others. They may delegate tasks to other agents in other systems. The concept of a "session" does not map cleanly to agentic workflows, and the security mechanisms built around session management (token expiration, refresh cycles, idle timeouts) need to be rethought.

Assumption 3: Authorization is relatively static. In traditional IAM, a user gets a role, and that role grants a set of permissions. Those permissions change infrequently (when the user changes jobs, gets a promotion, or leaves the company). Agent authorization needs to be dynamic. An agent processing a routine invoice may have standard approval authority. The same agent encountering an invoice that exceeds a threshold, or that comes from a flagged vendor, or that triggers a regulatory reporting requirement, needs different authorization in real time. Static roles do not capture this.

Assumption 4: Trust is bilateral. Traditional identity is a two-party problem: a user proves their identity to a system. Agentic identity is a multi-party problem. An agent acts on behalf of a human, who is part of an organization, using a model from one vendor, running on infrastructure from another vendor, accessing data from a third vendor, and potentially collaborating with agents from entirely different organizations. The chain of trust is longer and more complex than anything current identity frameworks were designed to handle.

The OpenID Foundation acknowledged this gap directly in their October 2025 whitepaper on identity management for agentic AI, noting that traditional IAM frameworks "presume predictable application behavior and a single authenticated principal" and are insufficient for agents that make autonomous decisions. ISACA put it more bluntly, calling it a "looming authorization crisis" for agentic AI.

The Four Dimensions of Agentic Identity

A complete agentic identity framework needs to address four distinct dimensions. Most current approaches address one or two. None yet address all four.

Authentication: Proving Who the Agent Is

Authentication for agents is not just about credentials. It is about provenance. When an agent presents itself to a system, that system needs to verify not just "this agent has a valid token" but a richer set of claims: which organization deployed this agent, which model powers it, what version of the agent logic is running, and what platform it is executing on.

Think of it as a chain of attestation. The agent identity needs to be cryptographically bound to its deployment context. SPIFFE (Secure Production Identity Framework for Everyone), originally designed for workload identity in cloud-native environments, offers a useful starting point. SPIFFE assigns verifiable identities to workloads based on what they are and where they run, rather than relying on network location or static secrets. Extending this model to agents (where identity is tied to the agent's provenance, capabilities, and deployment context) is a natural evolution.

Microsoft's Entra Agent ID, announced at RSAC 2026, takes a step in this direction by giving each agent a unique identity in the Entra directory. But it is scoped to the Microsoft ecosystem. The broader challenge is establishing authentication that works across vendors, across platforms, and across organizational boundaries.

Authorization: Defining What the Agent Can Do

Authorization for agents needs to go beyond static role-based access control. It requires what I would describe as contextual, dynamic authorization: permissions that adapt based on what the agent is doing, what it is encountering, and what risks are present.

Consider an agent managing procurement. In its normal operating mode, it can approve purchase orders up to $10,000, from approved vendors, for standard categories. But context changes: the agent encounters a purchase order for $50,000 from a new vendor in a restricted country. The authorization decision is no longer just "does the agent have the procurement role?" It involves the transaction amount, the vendor risk profile, the regulatory jurisdiction, and possibly the agent's track record of decisions in similar situations.

This is not role-based access control. It is closer to what the Cloud Security Alliance calls "relationship-based access": ARIA (Agent Relationship-based Identity and Authorization), where authorization decisions incorporate the full context of the agent's relationships, delegations, and current operational state. The OpenID Connect for Agents (OIDC-A) proposal goes further, introducing delegation chain validation so that when Agent B acts on a task delegated by Agent A, the authorization system can verify the entire chain of delegation back to the human or policy that originated it.

Accountability: Establishing Legal Binding

This is the dimension that matters most to the C-suite and the general counsel's office, and it is the one where the infrastructure is weakest. When an agent takes an action that has legal or financial consequences (approving a transaction, modifying a contract term, committing to a delivery date, sending a communication to a customer), there needs to be an unambiguous, legally defensible record of who is accountable.

The legal landscape is moving fast. California's AB 316, effective January 2026, explicitly precludes using an AI system's autonomous operation as a defense to liability. The EU's Product Liability Directive, to be implemented by December 2026, classifies AI software as a "product" subject to strict liability. Courts and regulators are not going to wait for the technology industry to figure out agentic identity. They are going to assign liability, and the organizations that cannot demonstrate clear accountability chains will bear the burden.

Accountability requires more than logging. It requires binding: a verifiable link between the agent's action, the authorization that permitted it, the delegation chain that led to it, and the human or organizational policy that is ultimately responsible. Think of it as the digital equivalent of a signature with a notarized chain of custody. The technology for this exists in pieces (digital signatures, verifiable credentials, distributed ledgers), but nobody has assembled it into a coherent framework for agentic accountability.

Provenance: Tracing the Full History

Provenance answers the question: how did we get here? It is the complete, tamper-evident record of an agent's actions, decisions, and reasoning chain. Not just what the agent did, but why it did it, what data it used, what alternatives it considered, and how confident it was in its decision.

Provenance is critical for three reasons. First, it is a regulatory requirement in many industries (financial services, healthcare, and government all require audit trails that demonstrate how decisions were made). Second, it is an operational necessity for debugging and improvement: when an agent makes a bad decision, you need to trace back through its reasoning to understand what went wrong. Third, it is a trust mechanism; when agents from different organizations collaborate, provenance lets each party verify that the other's agents acted within agreed parameters.

The challenge is scale. An enterprise running thousands of agents, each making hundreds of decisions per day, generates an enormous provenance footprint. The governance infrastructure needs to capture this at the granularity required for compliance without creating a performance bottleneck or a storage problem that makes the data practically useless.

The Cross-Organizational Forcing Function

If agentic identity were only an intra-enterprise problem, it would be important but manageable. Enterprises can impose internal standards, mandate specific identity providers, and enforce governance policies across their own agent deployments. Messy, but solvable.

Cross-organizational agent collaboration changes the equation entirely.

Consider what is already emerging: supply chain scenarios where a buyer's procurement agent communicates with a supplier's fulfillment agent. Financial services where a client's portfolio agent negotiates terms with a counterparty's trading agent. Healthcare where a provider's clinical agent shares information with a payer's authorization agent. In each case, agents from different organizations (with different identity providers, different governance frameworks, different security postures, and different liability structures) need to establish mutual trust and act on it.

This is the problem that makes identity non-negotiable rather than merely important. Inside the enterprise, you can compensate for weak identity with strong network controls, manual oversight, or limited agent autonomy. Across organizations, those compensating controls do not exist. You cannot rely on the other organization's network security. You cannot manually oversee every cross-boundary interaction. And limiting agent autonomy defeats the purpose of deploying agents in the first place.

Cross-organizational collaboration demands what I would describe as federated agentic identity: a model where organizations can issue identities to their own agents, those identities are verifiable by external parties, and the trust relationships between organizations are explicit, auditable, and revocable. This is analogous to what federated identity (SAML, OIDC) did for human users across organizational boundaries, but with the additional complexity of dynamic authorization, delegation chains, and provenance tracking that agents require.

No vendor has solved this. Microsoft's Entra Agent ID works within the Microsoft ecosystem. SPIFFE handles workload identity within and across cloud platforms. A2A and MCP handle agent communication protocols. But the federated agentic identity layer (the infrastructure that lets Organization A's agent prove its identity and capabilities to Organization B's agent, with both sides confident in the trust chain) does not exist yet.

What Vendors Are Getting Wrong

The current vendor landscape for agentic identity falls into three categories, none of which are adequate.

Extending existing IAM. The most common approach is to treat agent identity as an extension of existing identity and access management. Give agents service accounts, assign them roles, manage them in the existing directory. This is what most enterprises are doing today, and it is the equivalent of using horse-drawn carriages on a highway. Service accounts were designed for static, predictable workloads. Agents are dynamic, autonomous, and context-sensitive. Stretching IAM frameworks to cover agents creates the illusion of governance without the substance.

Platform-specific identity. Some vendors are building agent identity into their specific platforms. This solves the problem within one ecosystem but creates new silos. If your agents from Vendor A have identities that Vendor B's systems cannot verify, you have reproduced the same interoperability problem that federated identity solved for human users two decades ago. We should not need to solve it again from scratch.

Security theater. A troubling number of vendors are conflating security with identity. They offer runtime monitoring, anomaly detection, and behavioral analysis for agents (all valuable capabilities), but present them as "agent identity" solutions. Monitoring what an agent does is not the same as verifying who the agent is. Detection is not authentication. Observability is not accountability. These tools complement an identity framework, but they cannot substitute for one.

The deeper problem is that most vendors are treating agentic identity as a security feature rather than an architectural layer. Security is one dimension of identity. But identity also enables trust, accountability, governance, and interoperability. Building it as an afterthought (bolting it onto existing architectures rather than designing it in from the start) will produce the same kind of brittle, incomplete result that enterprises spent years cleaning up when they retrofitted security onto early cloud deployments.

Toward an Agentic Identity Architecture

So what should an agentic identity architecture look like? Based on the analysis above, I see five essential characteristics:

Agent-native, not human-adapted. The identity framework needs to be designed for how agents actually work: continuous operation, dynamic authorization, delegation chains, sub-agent spawning, and cross-platform interaction. Adapting human identity frameworks to agents is a dead end. The industry needs purpose-built standards that account for agent-specific behaviors from the start. The emerging work from the OpenID Foundation, including the OIDC-A proposal, moves in this direction.

Federated by design. Identity must work across organizational boundaries from day one, not as a later extension. The SAML/OIDC lesson is clear: federation that is retrofitted onto a proprietary identity system always produces friction, exceptions, and gaps. Agent identity needs to be federated from the beginning, with organizations issuing and managing their own agent identities within a shared trust framework.

Contextually dynamic. Authorization cannot be a static lookup. It needs to incorporate the agent's current task, the sensitivity of the data it is accessing, the risk profile of the action it is taking, and the full delegation chain that led to the current operation. This requires a policy engine that evaluates authorization in real time, not a role database that is checked at login.

Provenance-rich. Every agent action needs to carry its full provenance: who authorized it, what model produced it, what data informed it, and what the confidence level was. This provenance needs to be tamper-evident, efficiently stored, and queryable at the granularity that regulators and auditors require.

Interoperable across the stack. Identity cannot be locked to one layer of the architecture. It needs to flow from the Enterprise Platform (where data lives) through the Agentic Platform (where agents reason and act) to the Collaboration layer (where agents interact with humans and each other). The same identity framework that governs an agent's access to an ERP database needs to govern its participation in an Agent Service Bus workflow and its communication with a human through the collaboration interface.

None of these characteristics are individually novel. Federated identity, dynamic authorization, provenance tracking, and cross-layer identity propagation all exist in other contexts. What does not exist is a coherent framework that combines them for the specific requirements of AI agents operating at enterprise scale.

What Enterprise Leaders Should Do Now

Agentic identity infrastructure is immature, but that does not mean enterprises should wait. The decisions you make now about how agents are identified, authorized, and governed will be expensive to reverse later. Here is where to focus:

Inventory your agent landscape. Most enterprises do not know how many agents they are running, what permissions those agents have, or how those agents interact with each other. Start with a complete inventory: what agents are deployed, what identities do they use, what data can they access, what actions can they take, and who approved each of those authorizations. If you cannot answer these questions today, you have an exposure you have not sized.

Separate identity from security. Agent monitoring and anomaly detection are important, but they are not identity. Ensure that your agent governance strategy distinguishes between knowing who an agent is (identity), knowing what it can do (authorization), knowing what it did (provenance), and detecting when something goes wrong (security). Conflating these creates gaps.

Push vendors on interoperability. When evaluating agent platforms, ask hard questions about cross-platform identity. Can agents from this platform authenticate to other platforms? Can external agents verify the identity and capabilities of agents running here? If the answer is no, you are building identity silos that will constrain your agent architecture. Demand support for emerging standards like OIDC-A, SPIFFE for agent workloads, and A2A Agent Cards for capability attestation.

Plan for cross-organizational scenarios. Even if your current agent deployments are internal, plan your identity architecture as if agents will need to interact across organizational boundaries. Because they will. Supply chain collaboration, partner ecosystems, and customer-facing agent interactions are all on the near-term roadmap for most enterprises. Building identity for internal-only use and then retrofitting federation is the expensive path.

Engage with the standards process. The OpenID Foundation's AI Identity Management Community Group, IETF discussions around Agent Name Service, and the ongoing A2A and MCP protocol development are all actively shaping the standards that will govern agentic identity. Enterprise voices in these processes matter. If you leave the standards to vendors alone, the standards will reflect vendor interests.

Agentic identity is not glamorous. It does not have the excitement of a new AI model launch or the drama of a trillion-dollar market cap correction. But it is the infrastructure that determines whether enterprise AI agent deployments are trustworthy, governable, and scalable, or whether they become the next generation of ungoverned shadow IT, operating at machine speed with human consequences.

The enterprise software industry spent twenty years building identity infrastructure for human users. It cannot afford to spend another twenty building it for agents. The time to start is now, before the retrofit costs become prohibitive and the regulatory pressure makes the decisions for you.

Next in the series: "Governance Beyond Compliance," examining why traditional security and compliance frameworks are insufficient for governing autonomous AI agents, and what a purpose-built agentic governance architecture looks like.

Every major enterprise software vendor now has an AI agent story. ERP vendors have embedded agents in finance, procurement, and supply chain workflows. CRM platforms have agents handling lead qualification, customer service, and campaign orchestration. HCM suites have agents managing onboarding, scheduling, and benefits administration. At the same time, horizontal AI platforms are building agents that sit outside these applications and orchestrate across them.

This creates a strategic choice that every enterprise technology buyer and vendor needs to confront: do you bet on native agents that are deeply embedded in specific applications, or external agents that operate across applications from a horizontal platform? The answer is not obvious, and getting it wrong has real consequences for cost, flexibility, and competitive positioning.

Two Models for Enterprise Agents

Before we can evaluate the trade-offs, we need to be precise about what native and external agents are. The distinction is not just about where the agent runs. It is about how deeply the agent understands the system it operates on.

Native Agents: Deep and Narrow

Native agents are built into enterprise applications by the application vendor. They operate at the transaction layer; directly inside the data model, the business logic, and the process engine. A native accounts payable agent does not interact with the ERP through an API. It lives inside the ERP. It has direct access to the validation rules, the approval chains, the GL mapping, the tax logic, and the exception handling that governs invoice processing.

This architectural proximity gives native agents several structural advantages. They understand the data model intimately; the relationships between entities, the constraints, the referential integrity rules. They know the business rules without having to infer them from documentation or API behavior. They can operate within the application's transaction boundaries, which means they participate in the same commit/rollback logic as any other operation.

Major enterprise vendors are investing heavily here. ERP vendors have embedded hundreds of AI agents across finance, supply chain, HR, and customer experience. CRM platforms are building agents that understand the full lifecycle of customer relationships. HCM suites are deploying agents that navigate the compliance-heavy world of human resources with embedded knowledge of labor laws, benefit structures, and organizational policies.

The limitation is scope. Native agents only work within their vendor's ecosystem. An ERP agent that brilliantly processes invoices cannot help with the CRM workflow that originated the sales order, or the procurement system that negotiated the vendor contract, or the banking integration that executes the payment. Each agent is deep within its domain but blind to everything outside it.

External Agents: Broad and Shallow

External agents operate from a horizontal platform, outside any specific enterprise application. They connect to applications through APIs, connectors, and integration layers. They can orchestrate workflows that span multiple systems from multiple vendors.

The most prominent example is OpenAI's Frontier platform, launched in February 2026, which positions itself as the orchestration layer for enterprise AI agents. But the pattern extends to other horizontal platforms building similar capabilities. The value proposition is clear: a single agent (or a team of agents) that can work across your entire technology stack rather than being confined to one vendor's applications.

External agents have their own structural advantages. They can see the full picture; orchestrating a process that touches CRM, ERP, HCM, and custom systems in a single workflow. They are vendor-neutral, at least in theory, which means they do not contribute to lock-in with any specific application vendor. And they benefit from the most capable AI models available, since horizontal platforms typically have access to frontier-class reasoning, although most native agents also allow connection to proprietary model or “bring you own” model including the frontier models, that is also vendor neutral. Bring your own model though, usually requires additional licenses which can impact both cost and ROI.

The limitation is depth. An external agent interacting with an ERP system through an API sees only what the API exposes. It does not have direct access to the validation rules, the business logic, or the transactional boundaries that native agents operate within. If the API does not expose a particular rule or constraint, the external agent does not know about it. This creates a reliability gap: the external agent may attempt actions that violate business rules it cannot see or miss edge cases that a native agent would handle automatically.

OpenAI itself has acknowledged a version of this challenge. As agents are deployed widely across the enterprise, system fragmentation becomes more visible because agents deployed in isolation lack the context they need to perform effectively. In extreme cases, every new agent adds complexity rather than reducing it.

Where Depth Wins

Native agents have a clear advantage in three scenarios:

High-Volume Transactional Processes

Invoice processing, payroll runs, inventory management, revenue recognition; these are high-volume processes with deep, complex business rules and strict compliance requirements. A native agent that processes 50,000 invoices per month inside the ERP understands every validation rule, every approval threshold, and every exception path. An external agent attempting the same task through an API would need to replicate all that logic externally, which is both technically difficult and operationally risky.

The math here is straightforward. For a process that runs thousands of times per day within a single system, the native agent's transaction-layer access translates directly into speed, accuracy, and auditability. The overhead of API-mediated access; the latency, the incomplete visibility into business rules, the need to handle errors that the native agent would never encounter; makes external agents a poor fit.

Regulated Workflows

In finance, healthcare, and government, agents need to operate within specific regulatory frameworks. A native HCM agent that manages benefits enrollment understands the compliance rules for ERISA, ACA, COBRA, and state-specific labor regulations because those rules are built into the application it inhabits. An external agent would need to acquire that regulatory knowledge independently and maintain it as regulations change, a significant ongoing burden.

More importantly, governance and auditability are simpler with native agents. The actions a native agent takes are logged within the application's existing audit trail, using the same compliance controls that human users are subject to. An external agent's actions create a separate audit trail that needs to be reconciled with the application's records, adding complexity to an already demanding compliance process.

Application-Specific Optimization

Some tasks are inherently application specific. Optimizing a supply chain planning run, generating a financial close package, or configuring a complex product quote all require deep knowledge of the application's specific data model and logic. These are not generic tasks that benefit from cross-system orchestration. They are specialist tasks that benefit from deep domain integration.

Where Breadth Wins

External agents have a clear advantage in three different scenarios:

Cross-Functional Business Processes

Most business processes that matter to the C-suite span multiple systems. Order-to-cash touches CRM, ERP, billing, and payments. Procure-to-pay spans procurement, accounts payable, vendor management, and banking. Hire-to-retire crosses recruiting, onboarding, HCM, payroll, and benefits. These end-to-end processes are where external agents excel, because no single native agent can see the entire workflow. (Although arguably many enterprise systems span much of the full workflow as well)

Consider a contract renegotiation. The process requires pulling financial data from the ERP, analyzing contract terms from the CLM system, benchmarking market rates from external data sources, updating the CRM with revised terms, and routing the revised contract for approval. No native agent; however deep within its application, can orchestrate all of these steps. An external agent operating from a horizontal platform can. It would require multiple native agents for the same workflow coverage, adding complexity and additional risk.

Multi-Vendor Environments

Large enterprises almost never run a single vendor's stack across every function. They run one vendor for ERP, another for CRM, a third for HCM, and a mix of specialized tools for everything else. In these environments, native agents create islands of automation: each application has its own smart agents, but they cannot coordinate across the vendor boundaries.

External agents are the natural integration layer for multi-vendor environments. They do not care which vendor built which system. They connect to all of them through APIs and orchestrate across the boundaries that native agents cannot cross.

Rapid Innovation and Experimentation

Horizontal AI platforms iterate on model capabilities faster than any application vendor can. When a new reasoning capability emerges; better code generation, improved multi-step planning, stronger tool use; external agents get access to it immediately. Native agents wait for the application vendor to integrate it, which can take quarters or years.

For enterprises that want to experiment with new AI capabilities quickly, external agents provide a faster path. They are not constrained by any vendor's release cycle or model integration timeline.

The Third Path: Native Agents with Open Interoperability

The depth-breadth trade-off creates an obvious question; is there a way to get both? Can you have agents that are deep within their applications but also capable of participating in cross-vendor orchestration?

Emerging interoperability protocols suggest this might be possible. As I discussed in the previous article in this series, A2A (Agent-to-Agent Protocol) and MCP (Model Context Protocol) are establishing the groundwork for agents from different platforms to communicate and collaborate. If native agents can expose their capabilities through standardized protocols and participate in cross-platform workflows, the depth-breadth trade-off becomes less binary.

Picture the scenario: a native ERP agent that deeply understands invoice processing and exposes that capability through a standardized Agent Card. An external orchestrating agent can discover it, delegate the invoice processing task, and coordinate the result with actions in other systems, all without the external agent needing to understand the ERP's internal business logic. The native agent handles depth. The external agent handles breadth. The protocol layer handles the handoff.

This third path is compelling, but it faces real challenges:

Incentive misalignment. Application vendors have a commercial interest in keeping agents within their ecosystem. Exposing native agent capabilities through open protocols makes it easier for orchestration platforms to commoditize the application layer. Vendors will need to find business models that reward openness rather than punish it.

Protocol maturity. As I covered in the previous article, current protocols handle message routing and basic capability discovery, but they do not yet solve intent resolution, contract negotiation, or conflict arbitration. Native agents exposing capabilities through A2A is only useful if the orchestration layer can intelligently decide when and how to invoke them.

Trust and governance. When a native agent executes a task delegated by an external orchestrator, who is responsible for the outcome? The application vendor whose agent performed the action? The platform that delegated it? The enterprise that deployed both? This accountability question is unresolved and will become increasingly urgent as agents take higher-stakes actions.

Performance overhead. Adding a protocol layer between the orchestrator and the native agent introduces latency. For high-volume transactional processes where native agents process thousands of operations per minute, even small amounts of protocol overhead can impact performance. The interoperability layer needs to be efficient enough that it does not negate the native agent's speed advantage.

Despite these challenges, the third path is where I expect the market to converge over the next two to three years. The depth-breadth trade-off is real, but it is not permanent. The vendors and platforms that figure out how to bridge it; combining native depth with open interoperability; will hold a significant competitive advantage.

How Enterprises Should Think About Their Agent Portfolio

Given the trade-offs, how should enterprise leaders approach the native vs. external question? Here is a framework:

Start with the process, not the technology. Map your highest-value business processes and categorize them: processes that live entirely within one application (use native agents), processes that span multiple systems (use external agents or the hybrid approach), and processes that require both deep domain logic and cross-system coordination (candidates for the third path). Let the process requirements drive the agent architecture, not the vendor pitch.

Do not treat this as either/or. Most enterprises will need both native and external agents. The question is not which model wins. It is which model fits which process. Build an agent portfolio the same way you build an application portfolio, with clear criteria for when each approach is appropriate.

Demand interoperability from your vendors. Every time you deploy a native agent, ask your vendor; how does this agent participate in cross-platform workflows? Does it support A2A or MCP? Can an external orchestrator discover and invoke its capabilities? If the answer is "it only works within our platform," you are building a new generation of integration silos.

Invest in the orchestration layer. Whether you use an external agent platform or build your own, the orchestration layer is where multi-agent coordination happens. As I discussed in the previous article, the Agent Service Bus; handling capability discovery, intent resolution, conflict arbitration, and contract negotiation; is the infrastructure that makes a mixed agent portfolio work. Without it, native and external agents operate in parallel but never truly collaborate.

Plan for governance from day one. Native agents inherit existing application governance. External agents need new governance frameworks. A mixed portfolio needs both, plus a way to maintain a unified audit trail across agent types. The governance overhead of a mixed agent environment is non-trivial, and it grows with every agent you add. This is a topic I will address in depth in a future article in this series.

The native vs. external agent debate is often framed as a competition, which model wins? That framing misses the point. Both models exist because they solve different problems. The real strategic question is not which one to choose. It is how to build an agent architecture that gets the benefits of both while managing the complexity of neither.

The enterprises that figure this out will have agents that are deep where depth matters and broad where breadth matters. The ones that bet on a single model, all native or all external, will find themselves either locked into one vendor's ecosystem or operating with agents that lack the domain depth to be reliable in production.

The future enterprise will run on both. The architecture that connects them is what matters most.

Next in the series: "Agentic Identity: The Missing Layer in Enterprise AI Architecture" - examining why portable, verifiable identity for AI agents is the architectural prerequisite that most vendors are neglecting, and why cross-organizational collaboration makes it non-negotiable.

In the first article in this series, I introduced the Future Enterprise framework; a layered architecture for understanding how AI agents are unbundling traditional enterprise applications. The framework has three horizontal layers (Enterprise Platform, Agentic Platform, Collaboration), cross-cutting vertical services, and one piece of connective infrastructure that I called the Agent Service Bus.

Of everything in that framework, the Agent Service Bus may be the most strategically important component, and the one getting the least attention. Everyone is talking about AI models, agent platforms, and the death of per-seat pricing. Almost nobody is talking about the infrastructure that makes agents work together.

That is a problem. Because without a robust Agent Service Bus, the future enterprise does not work. You just get a collection of smart but isolated agents, each capable within its own domain but unable to collaborate, coordinate, or resolve conflicts when their goals intersect.

What the Agent Service Bus Actually Is

The Agent Service Bus sits between the Agentic Platform (where agents live and execute) and the Collaboration layer (where agents and humans interact). It is the connective tissue that enables agents to discover each other, communicate, delegate tasks, and resolve conflicts.

If you worked in enterprise IT during the 2000s, you remember the Enterprise Service Bus (ESB), the middleware layer that connected applications in a service-oriented architecture (SOA). The Agent Service Bus is the next-generation version of that concept, but the requirements are significantly more complex.

An ESB routed messages between applications with known interfaces. The applications were deterministic: given the same input, they produced the same output. The interfaces were defined in advance using standards like WSDL and SOAP. The ESB was a sophisticated message broker, but the things it was connecting were predictable.

AI agents are not predictable. They reason. They make judgment calls. They can produce different outputs from the same input depending on context. They may disagree with each other about the right course of action. They need to negotiate, not just communicate.

That difference in the nature of the endpoints changes everything about what the connective infrastructure needs to do.

Five Functions the Agent Service Bus Must Perform

Based on my analysis of the emerging enterprise agent landscape, the Agent Service Bus needs to handle five distinct functions. Current protocols and frameworks address some of these. None address all of them.

1. Capability Discovery

Before agents can work together, they need to know what other agents exist and what they can do. This sounds simple, but in a large enterprise with hundreds of agents from multiple vendors, it becomes a real infrastructure problem.

Capability discovery requires a registry; a machine-readable catalog of available agents, their skills, input/output specifications, access requirements, and performance characteristics. Think of it as a DNS for agents: instead of resolving domain names to IP addresses, it resolves task descriptions to agent capabilities.

The A2A protocol has made progress here with "Agent Cards", JSON-formatted capability descriptions that agents can publish and query. This is a solid foundation, but it is still early. Current Agent Card specifications do not yet require machine-readable definitions of skill inputs and outputs with typed fields and validation rules, which means automated orchestration can discover what agents exist but cannot always determine the exact structured data required to invoke them without additional documentation.

2. Intent Resolution

When a human or an orchestrating agent says "process this invoice," the Agent Service Bus needs to figure out which agent (or combination of agents) should handle the request. This goes beyond simple routing. It requires understanding the intent behind the request, matching it to available capabilities, and selecting the best agent or workflow based on context.

Intent resolution gets hard when multiple agents could handle the same request. Should the invoice go to the Oracle-native AP agent (which understands the full validation and approval workflow) or to a Frontier agent (which can orchestrate across Oracle, the vendor's portal, and the banking system in a single workflow)? The answer depends on context: the invoice amount, the vendor relationship, the compliance requirements, and the organizational policies that govern the process.

No current protocol handles intent resolution well. Both A2A and MCP assume that the caller knows which agent or tool to invoke. The intelligence required to match intent to capability; especially when multiple agents compete for the same task; lives in the orchestration layer, and there is no standard for how that orchestration should work.

3. Contract Negotiation

When one agent delegates a task to another, they need to agree on terms. What are the expected inputs and outputs? What is the acceptable response time? What happens if the task fails? Who bears responsibility for the outcome?

In the SOA era, service-level agreements (SLAs) were defined in advance between known systems. In an agentic world, contract negotiation needs to happen dynamically; at runtime, between agents that may not have interacted before. This is especially true in cross-vendor scenarios: when an Oracle agent delegates a sub-task to a Salesforce agent, the two need to establish a shared understanding of the task, the quality expectations, and the fallback behavior, all in real time.

This is entirely missing from current protocols. A2A defines task lifecycle states (submitted, working, completed, failed) but does not specify how agents negotiate the terms of a task before accepting it. MCP does not address agent-to-agent negotiation at all; it is designed for agent-to-tool connections, not peer-to-peer collaboration between autonomous agents.

4. Conflict Arbitration

What happens when two agents want to modify the same record? When Agent A (managing inventory) wants to release stock for a rush order and Agent B (managing procurement) wants to hold that stock for an incoming bulk purchase? In a deterministic system, you solve this with database locks and transaction isolation. In an agentic system, you need something more sophisticated; a mechanism for agents to surface conflicts, escalate when necessary, and reach resolution either autonomously or by involving a human decision-maker.

Conflict arbitration becomes even more complex in multi-vendor environments. If the conflicting agents are from different platforms; one native to Oracle, one operating through Frontier; there is no shared governance framework to adjudicate the dispute. Each platform has its own rules, its own priority system, and its own escalation logic.

This is an area where the enterprise software industry has almost no infrastructure. Current agent frameworks handle conflicts by giving the orchestrating agent final authority, which works in simple hierarchical setups but breaks down in the distributed, multi-vendor environments that large enterprises run.

5. Message Routing and Orchestration

The most basic function; and the one where current protocols are strongest; is simply getting messages from one agent to another reliably, securely, and with the right context attached.

A2A handles this reasonably well for agent-to-agent communication, with support for both synchronous and asynchronous (streaming) interactions, structured message formats, and task lifecycle management. MCP handles it well for agent-to-tool connections, with a growing ecosystem of over 10,000 active public servers covering everything from developer tools to enterprise deployments.

But routing alone is not enough. In complex enterprise workflows, the Agent Service Bus needs to orchestrate sequences of agent interactions; managing dependencies, handling partial failures, maintaining state across long-running processes, and ensuring that the overall workflow progresses even when individual agents encounter problems. This orchestration logic is where current protocols leave the most work to the implementer.

What We Learned from the ESB Era (and What Does Not Apply)

The enterprise software industry went through a version of this problem twenty years ago. The ESB era offers some useful lessons, and some cautionary tales.

Lesson 1: Standards matter, but they take too long

The SOA era produced a blizzard of standards: WSDL, SOAP, UDDI, WS-Security, WS-ReliableMessaging, WS-Transaction, and dozens more. The standards were technically rigorous but took years to mature, and by the time they were complete, the industry had largely moved on to REST APIs and pragmatic integration patterns. The lesson: do not wait for perfect standards. Build practical infrastructure now and let standards codify what works.

The agent interoperability space is at risk of repeating this pattern. A2A and MCP are good starting points, but the gap between what they provide and what the Agent Service Bus needs is wide. If the industry waits for protocol committees to close that gap, enterprises will build proprietary solutions that become the next generation of integration silos.

Lesson 2: The middleware layer becomes a control point

In the SOA era, the ESB vendors (TIBCO, IBM WebSphere, Oracle Fusion Middleware) controlled a strategically important layer. They were not the most glamorous companies in enterprise software, but they were among the most difficult to displace once embedded. The same will likely be true for whoever builds the Agent Service Bus. It is a high-switching-cost position because every agent interaction flows through it.

This is why the question of who builds the Agent Service Bus matters so much. If a single cloud provider or AI platform controls it, they gain leverage over the entire agentic ecosystem. If it is built on open standards, the control point shifts to implementation quality rather than protocol lock-in.

Lesson 3: Point-to-point integration does not scale

Before the ESB, enterprises connected applications directly, point-to-point integrations that created a tangled web of dependencies. The ESB solved this by centralizing integration logic. The same pattern is emerging with agents: early adopters are connecting agents directly, building custom integrations between specific agent pairs. This works for small deployments but will not scale to hundreds of agents from dozens of vendors.

The Agent Service Bus exists precisely to prevent this point-to-point mess from recurring. It is the abstraction layer that lets agents interact through a common infrastructure rather than requiring bespoke connections between every pair.

What does not apply: determinism

The biggest difference between the ESB era and the Agent Service Bus era is the nature of the endpoints. ESB-connected applications were deterministic. Agent Service Bus-connected agents are probabilistic. They reason, they have context, they make judgment calls. This means the infrastructure cannot just route messages; it needs to mediate between intelligent entities that may disagree, produce unexpected outputs, or require negotiation to resolve ambiguity. There is no precedent for this in enterprise middleware.

Who Should Build the Agent Service Bus?

This is the strategic question that should concern every enterprise technology leader and vendor. There are several candidates, each with a different angle:

The Cloud Providers

AWS, Azure, Google Cloud, and Oracle Cloud all have the infrastructure expertise and the customer relationships to build Agent Service Bus capabilities into their platforms. Google has already moved aggressively with A2A. The risk is fragmentation: if each cloud provider builds its own Agent Service Bus, you get cloud-specific agent ecosystems that do not interoperate well, exactly the lock-in problem that enterprises are trying to avoid.

The AI Platform Companies

OpenAI (with Frontier), Anthropic, and others could embed Agent Service Bus capabilities into their agent platforms. OpenAI is already building elements of this into Frontier; the Business Context layer and the agent orchestration capabilities are early Agent Service Bus functions. The risk is that the Agent Service Bus becomes captive to a single AI platform, which conflicts with the multi-model, multi-vendor reality of most enterprises.

The Traditional Middleware Companies

Companies with deep integration heritage, including Oracle (which acquired TIBCO-adjacent capabilities), IBM, and MuleSoft (Salesforce), have relevant expertise. They understand enterprise integration patterns, message routing, and the operational requirements of mission-critical middleware. The risk is that they bring ESB-era thinking to an agentic problem that requires new architectural patterns.

Open Standards Bodies

The Linux Foundation, through the Agentic AI Foundation, is already hosting both A2A and MCP. An open-standards approach to the Agent Service Bus would prevent vendor lock-in and encourage ecosystem-wide interoperability. The risk is the pace problem from the SOA era: standards bodies move slowly, and the enterprise cannot wait.

My assessment: the Agent Service Bus will likely emerge as a combination of open protocols (A2A and MCP as the foundation) and proprietary implementations that add the missing functions (intent resolution, contract negotiation, conflict arbitration). The winners will be the companies that build the best implementations on top of open standards; the same pattern that played out with HTTP, REST, and cloud computing.

What This Means for Enterprise Leaders

If you are making technology decisions today, here is what the Agent Service Bus gap means for you:

Recognize that agents without orchestration are just expensive chatbots. The value of AI agents comes from their ability to collaborate, with each other and with humans, across complex workflows. If your agents cannot discover, communicate with, and negotiate with other agents, you have automated individual tasks but you have not transformed how work gets done.

Push your vendors on interoperability. Ask every AI platform vendor and enterprise software vendor the same question: how do your agents participate in multi-vendor workflows? If the answer is "they work great within our ecosystem" and nothing more, that is a warning sign. The future enterprise will not be single-vendor.

Do not build point-to-point agent integrations. It is tempting to connect agents directly -- Agent A talks to Agent B through a custom integration. This is the same mistake enterprises made before the ESB, and it will create the same tangled web of dependencies. Invest in an orchestration layer from the start, even if the first version is simple.

Watch the standards space closely. A2A and MCP are the two protocols that matter right now. Both are under the Linux Foundation. Both are evolving rapidly. The decisions being made in these working groups over the next 12-18 months will shape the agent infrastructure landscape for a decade. If your organization has the resources, participate directly.

Plan for the missing functions. Capability discovery and message routing are largely solved by current protocols. Intent resolution, contract negotiation, and conflict arbitration are not. If you are deploying agents at scale, you will need to build or buy solutions for these functions. Do not assume the protocols will catch up before you need them.

The Agent Service Bus is not glamorous. It is middleware; the plumbing that makes the system work. But in every previous era of enterprise technology, the company or standard that controlled the integration layer ended up controlling the ecosystem. The same will be true for agents.

The infrastructure is not ready yet. The companies and standards bodies that close the gap fastest will shape the future enterprise architecture for the next decade. And the enterprises that recognize this early, that invest in orchestration alongside intelligence, will be the ones that capture the full value of the agentic shift.

Next in the series: "Native vs. External Agents: The Depth-Breadth Trade-off in Enterprise AI", examining the structural advantages and limitations of agents embedded in applications versus agents operating from horizontal platforms.

In February 2026, OpenAI launched Frontier, its agent platform for the enterprise. Within weeks, nearly $1 trillion in SaaS market capitalization evaporated. Investors called it the "SaaSpocalypse." Workday stock plummeted despite beating earnings. Salesforce CEO Marc Benioff went on the defensive, telling the market "this is not our first SaaSpocalypse." The message from Wall Street was blunt: the traditional enterprise application model is under existential pressure.

But the market reaction, dramatic as it was, misses the more interesting story. The real question is not whether AI agents will disrupt enterprise software. They will. The real question is what replaces the current architecture; and who controls the new one.

Enterprise Apps Are Bundles Ready to Unbundle

To understand what is happening, you need to see today's enterprise applications for what they are. Every major enterprise app; whether it is an ERP system from Oracle or SAP, a CRM platform from Salesforce, or an HCM suite from Workday; is a bundle of four things: a data model, business logic, a user interface, and workflow orchestration.

That bundle made sense in a world where humans were the primary users of enterprise software. Humans need interfaces. They need guided workflows. They need applications that present information in digestible forms and walk them through processes step by step.

AI agents need none of that.

Agents do not need a UI. They interact through APIs. They do not need rigid, pre-defined workflows. They can reason about what to do next based on context, rules, and goals. What agents do need is access to trusted data (the system of record), the business rules that govern how the enterprise operates, and the ability to take action.

This is the unbundling thesis: the four components that have been stitched together inside enterprise applications for decades are coming apart. The UI and workflow layers lose strategic importance. The data model and business logic retain their value but get consumed differently, by agents rather than by humans clicking through screens.

The question becomes: what does the stack look like when you reassemble those pieces for an agent-native world?

The Enterprise Shift

The first step in the transition is visible today. The traditional enterprise structure; collaboration tools sitting on top of siloed applications, each with its own data store; is already reorganizing.

Applications do not disappear in this phase. But they shrink in strategic importance. They become interchangeable modules rather than the center of gravity. A CRM system stops being the command center for sales and starts being one of several data sources that agents draw on to manage customer relationships. An ERP system stops being the place where finance teams live and starts being the transactional backbone that agents use to process invoices, reconcile accounts, and generate reports.

The platform layer and the agent layer absorb the functions that used to justify enterprise app lock-in. The differentiation shifts from "which application has the best features" to "which platform gives agents the best access to data, the most robust orchestration, and the strongest governance."

This is already causing real competitive anxiety. Oracle, for instance, is simultaneously an early Frontier customer and a vendor with 600+ embedded AI agents in its own Fusion Cloud applications. That dual positioning, partner and competitor at the same time, tells you everything about how unsettled the landscape is.

The Future Enterprise Architecture

So what does the destination look like? I have been developing a layered architecture framework for what I am calling the "Future Enterprise." It has three horizontal layers, a critical piece of connective infrastructure, and several cross-cutting vertical services.

Enterprise Platform (the Foundation)

The base layer is the Enterprise Platform. It provides the system of record; validated, governed, transactional data; along with business rules and logic. This is what remains after you strip the UI and rigid workflows from today's applications. It is the "source of truth" that both agents and humans depend on.

This layer is where Oracle's database-centric strategy maps most directly. Oracle Database 26ai, with its in-database agents and vector capabilities, is a bet that the database itself becomes the center of the enterprise AI stack. It is also where SAP's business process expertise and Workday's HR domain knowledge live as durable assets, even if the application wrapper around them changes dramatically.

Agentic Platform (Intelligence and Execution)

The middle layer is where AI agents live and operate. It provides three things: agent orchestration (managing which agents run, when, and in what sequence), process and workflow orchestration (replacing the rigid workflow engines of traditional apps with dynamic, AI-driven execution), and the intelligence layer itself; the AI models that power reasoning and decision-making.

This is the layer that OpenAI is targeting with Frontier. It is also where Anthropic, Google, and Microsoft are competing. The Agentic Platform consumes data and business rules from the Enterprise Platform below and exposes capabilities to the Collaboration layer above.

A critical sub-component here is what I am calling the Agent Service Bus; the connective tissue that sits between the Agentic Platform and the Collaboration layer. If you remember the Enterprise Service Bus (ESB) from the SOA era, this is the next-generation version, but significantly more complex. It handles message routing between agents, intent resolution (understanding what an agent is trying to accomplish), capability discovery (which agent can do what), conflict arbitration (what happens when two agents want to modify the same record), and contract negotiation (how agents agree on terms, SLAs, and fallback behavior when delegating tasks to each other).

The Agent Service Bus may be the most strategically important piece of infrastructure in the entire stack, and no one has clearly won it yet.

Collaboration (the Interaction Surface)

The top layer is where all four communication modes converge: agent-to-agent, human-to-agent, agent-to-human, and human-to-human.

Each mode has different requirements. Agent-to-agent communication is API-native and fast. Human-to-agent interaction needs natural language and trust signals; people need to understand what agents are doing and why. Agent-to-human interaction needs proactive notification and escalation logic; agents need to know when to surface decisions to a human rather than acting autonomously. Human-to-human is the collaboration we already know.

The hard design problem is not any single mode. It is the transitions between them. A workflow might start as a human-to-human conversation ("we need to renegotiate this vendor contract"), escalate to human-to-agent ("draft the analysis and identify the key leverage points"), trigger agent-to-agent work (one agent pulls financial data, another analyzes contract terms, a third benchmarks market rates), and surface back as agent-to-human ("here is the recommended negotiation strategy with three scenarios"). Making those transitions seamless; so the humans involved experience it as one continuous workflow rather than four disconnected handoffs; is arguably the hardest UX challenge in the future enterprise.

The Vertical Services

Three cross-cutting services span the entire architecture:

Context and Persistent Memory. This is distinct from the transactional system of record. It is the organizational knowledge graph; contextual memory that spans interactions, accumulates institutional knowledge, and informs future decisions. OpenAI calls this "Business Context" in Frontier. It bridges the Enterprise Platform (structured data) and the Agentic Platform (agent reasoning), providing the persistent state that makes agents smarter over time. Think of it as the difference between an employee who has access to the company database and an employee who has worked at the company for ten years and understands the unwritten rules, the institutional history, and the political dynamics.

Governance. When agents execute transactions, make decisions, and interact with each other, the enterprise needs real-time auditability, explainability, and chain of custody for every action. This goes beyond traditional logging. It is deterministic proof of why an agent did what it did, with what authority, using what data. In regulated industries; finance, healthcare, government; governance becomes the gating factor for adoption. No amount of agent intelligence matters if you cannot prove to a regulator that the agent acted within authorized boundaries.

Metering. If per-seat pricing collapses (and it is collapsing; more on this in a moment), the platform needs native instrumentation for measuring consumption and attributing value. Metering must operate at every layer: data access and compute at the Enterprise Platform, agent invocations and task completions at the Agentic Platform, and outcomes delivered at the Collaboration layer.

Finally, the architecture needs a simulation and testing capability; a sandboxed environment where agent workflows can be tested against production-like data without executing real transactions. This is the DevOps equivalent for agentic systems. You would not deploy a major code change without testing it. You should not deploy an agent workflow that processes invoices, modifies contracts, or communicates with customers without testing it either.

The Center of Gravity Question

The framework raises a strategic question that every enterprise vendor and buyer needs to answer: what becomes the control point that everything else orbits around?

My take is that the answer depends on the time horizon.

In the near term (1-2 years), data wins. Agents need trusted, governed data to act on, and whoever controls that data controls the agents. This is Oracle's bet with Database 26ai. It is also why established SaaS vendors with deep data moats; the transactional histories, the customer records, the financial data; retain significant leverage even as their application layers get disrupted.

In the medium term (3-5 years), intelligence wins. Model capability determines what agents can do. As reasoning quality improves, the differentiator shifts from "who has the data" to "who has the smartest agents." This is OpenAI's bet with Frontier, and Anthropic's, and Google DeepMind's. The platform with the most capable models attracts the most developers, which attracts the most enterprise customers, which generates the most data to make the models even smarter. It is a flywheel.

In the long term (5+ years), business logic might reassert itself. Generic intelligence commoditizes; just as compute commoditized, just as storage commoditized, just as basic AI inference is already commoditizing. The differentiator becomes domain-specific reasoning: understanding the nuances of pharmaceutical supply chains, or insurance underwriting, or manufacturing quality control. That deep vertical expertise lives in today's SaaS incumbents, and it may prove harder to replicate than either raw data or general intelligence.

The smartest enterprises will not bet on just one of these. They will invest across all three; ensuring data quality and governance now, building optionality across AI platforms in the medium term, and deepening domain expertise continuously.

What This Means for Enterprise Leaders

If you are a CIO, CTO, or business leader trying to navigate this shift, here is what I would focus on:

Audit your application bundle. Look at each major enterprise application in your portfolio and ask: which of the four components (data model, business logic, UI, workflow) are we getting value from? Where are agents already capable of replacing the UI and workflow layers? That is where disruption hits first.

Evaluate your platform bets. Are you locked into one vendor's agent ecosystem, or are you building optionality? The Agent Service Bus layer is where lock-in risk is highest and where strategic flexibility matters most. Push your vendors on interoperability and avoid architectures that trap your agents inside a single platform.

Prepare for new collaboration modes. Your organization is going to need to work alongside agents as peers, not just use them as tools. That means rethinking roles, redefining processes, and, critically; building the trust infrastructure (governance, explainability, auditability) that makes human-agent collaboration viable in regulated, high-stakes environments.

Get serious about governance before regulators do. The governance pillar is not optional. It is the gating factor for enterprise adoption of agentic systems. The companies that build robust governance early will move faster than those who treat it as an afterthought and then scramble to bolt it on when regulators come asking questions. (Check out this new Governance-by-Design Research Report).

Rethink your pricing assumptions. Whether you are a software buyer or a software seller, the per-seat model is not the long-term equilibrium. Start planning for hybrid consumption models now and invest in the metering infrastructure that makes those models work.

The enterprise application model that has dominated for the past two decades is not going to disappear overnight. But it is being unbundled, restructured, and reassembled around a new architecture; one where agents are first-class participants, platforms matter more than applications, and the collaboration between humans and AI becomes the primary interface for how work gets done.

The companies that understand this shift and architect for it will thrive. The ones that cling to the old bundle will find themselves on the wrong side of the next SaaSpocalypse.

In the race for AI, most companies are driving with their eyes closed and their foot on the brake. They have seen the headlines. An agent hallucinates a refund policy that does not exist. A chatbot tells a customer something defamatory. A multi-agent workflow leaks confidential data across departmental boundaries. The result is organizational paralysis. Every new deployment triggers the same cycle: excitement from the technology team, followed by a wall of objections from legal, compliance, and the CISO. The Headline Risk of a rogue agent has become the default reason to say no.

But here is the paradox. The companies saying no are not actually safer. They are just slower. Their agents still hallucinate in the pilots they do approve. They still lack the infrastructure to detect drift or prove alignment. They are not avoiding risk. They are avoiding velocity while keeping the risk fully intact.

True competitive advantage in 2026 is not having the biggest model or the most parameters. It is having the best Governance-by-Design. The organizations that will dominate are the ones that built the brakes, the sensors, and the reinforced chassis before they pressed the accelerator. Governance is not the department that says no. It is the department that says yes with structural certainty, the engineering discipline that makes it safe to deploy at scale.

The Velocity Gap: Architecture vs. Auditing

There is a widening gap between two kinds of organizations, and it has nothing to do with model selection or compute budgets. It is a governance gap. On one side are the laggards, companies stuck in what I call “Pilot Purgatory”. They have a handful of agent prototypes sitting in sandboxed environments, each one waiting for a manual audit that takes three to six months. They do not trust the foundation, so they test every output by hand. Legal reviews every prompt template. Compliance signs off on every new data source. The CISO demands a penetration test for every API connection. By the time the agent clears all the gates, the business requirement has changed and the cycle starts over.

Consider a hypothetical logistics company that wants to deploy a procurement agent. Without governance infrastructure, the compliance team insists on reviewing a sample of every vendor interaction the agent produces. That review queue grows faster than the team can process it. After four months, only 60 percent of the sample has been reviewed. The procurement team, still waiting for approval, continues doing everything manually. The agent sits idle. The competitors who automated procurement six months ago are already seeing margin improvements. This is the real cost of Pilot Purgatory: not the risk you avoided, but the advantage you surrendered.

On the other side are the leaders. These organizations invested in governance infrastructure before they scaled their agent deployments. They have the Semantic Interceptor from Article 3 monitoring intent in vector space before any output reaches a user. They have the Three-Tier Guardrail Framework from Article 2 enforcing hard constraints, boundary conditions, and soft nudges at the architectural level. They have Algorithmic Circuit Breakers from Article 7 that detect drift, confidence decay, and feedback loops in real time. When they want to deploy a new agentic swarm, they do not start a six-month audit. They plug the agents into the existing governance stack and go live in days.

The metric that captures this gap is what I call “Time-to-Trust”: the elapsed time from when an agent is conceived to when the organization trusts it enough to put it in production. For the laggards, Time-to-Trust is measured in months or quarters. For companies with Governance-by-Design, it is measured in days or even minutes, because the trust infrastructure is already in place, already tested, and already proven across every prior deployment. Governance-by-Design does not just reduce Time-to-Trust. It collapses it. And that collapse is where competitive advantage lives.

Trust as a Moat: Winning the Customer and the Regulator

In a market saturated with AI claims, trust is becoming the premium brand position. Every vendor says their agents are reliable. Every sales deck promises responsible AI. But buyers, especially enterprise buyers, are getting sharper. They want proof, not promises.

The organization with Governance-by-Design can deliver that proof. In a B2B sales cycle, being the Governed Provider is a differentiator that ungoverned competitors cannot fake. You can show prospects the clustering maps from Article 8, proving that 99 percent of your agent actions stayed within policy boundaries last quarter. You can produce Governance Ledger entries demonstrating explainability for any decision a client questions. You can present the Vibe Map as a sales tool, visual proof that your agents are the most reliable in the market. In a world of deepfakes and hallucinations, mathematical proof of alignment is not a nice-to-have. It is the trust infrastructure that closes deals.

Regulatory resilience adds another layer to the moat. While competitors scramble to comply with new frameworks like the EU AI Act, the Governance-by-Design firm is already compliant by default. Their constraints are not just policy documents sitting in a SharePoint folder. They are mathematical boundaries encoded in vector space, enforced by the Semantic Interceptor, logged by the Governance Ledger, and provable with cosine similarity scores. When the regulator asks for an explanation, these companies do not convene a task force. They pull up the ledger entry. Compliance is not a project for them. It is a byproduct of the architecture.

This creates what I call the “Auditability Premium”: the measurable market advantage of being able to prove your AI is trustworthy. Healthcare companies that can demonstrate their clinical agents operate within evidence-based guidelines get regulatory approval faster. Financial services firms that can show suitability compliance in real time win institutional clients that ungoverned competitors never reach. Technology vendors with governance-grade auditability earn enterprise contracts where the RFP specifically demands it. Trust is not a soft benefit. It is a revenue driver and a barrier to entry for everyone who did not build the infrastructure.

Scaling the Un-Scalable: Multi-Agent Synergy

Single-agent deployments are useful. Multi-agent systems are transformative. But multi-agent systems without governance are catastrophic. This is the scaling paradox that separates governed organizations from everyone else.

The Agentic Service Bus from Article 5 is what makes governed multi-agent collaboration possible. It provides the air traffic control layer that routes messages, enforces token budgets, prevents collusion, and maintains the Chain of Intent across every delegation. When agents are governed, they can collaborate without human babysitting. A research agent can hand findings to an analysis agent, which can pass recommendations to a drafting agent, which can deliver a finished report to a human reviewer. Each handoff is scoped, logged, and constrained by the identity and privilege framework from Article 4. The Human-in-the-Lead model from Article 6 means the human oversees the policy, not every individual output.

This produces what governed organizations experience as Compound Intelligence: the exponential productivity gains that come from agents working together within a trusted framework. Picture a hypothetical consulting firm where a five-agent swarm handles client onboarding. One agent gathers requirements, another maps them to service offerings, a third drafts the engagement letter, a fourth runs a conflict-of-interest check, and a fifth schedules the kickoff. Without governance, any one of those agents could drift, leak data to the wrong client record, or commit the firm to terms outside its approved range. With the full governance stack, each agent operates within its identity scope, the interceptor watches the tone and content of every client-facing output, and the circuit breakers catch anomalies before they cascade. The firm does in two hours what used to take two weeks. That is Compound Intelligence in action.

An ungoverned organization cannot achieve this. Without the Service Bus, agents talk past each other. Without identity scoping, privilege escalation cascades across the swarm. Without circuit breakers, a single drifting agent can corrupt the entire chain. Ungoverned multi-agent systems do not just fail gracefully. They fail spectacularly, and publicly. The governed organization scales safely. The ungoverned organization scales its risk.

The Final Ferrari Metaphor

Throughout this series, we have built an entire governance architecture from the ground up. We encoded brand voice as mathematical coordinates. We installed the Semantic Interceptor to monitor intent before it becomes output. We issued identity credentials and enforced least-privilege access for every agent. We built the Agentic Service Bus to orchestrate multi-agent collaboration. We put humans in the lead as flight controllers, not bottlenecks. We deployed circuit breakers to catch drift, decay, and feedback loops before they cause harm. And we turned every decision into auditable, mathematical proof of compliance.

Now picture the race. The track is treacherous. The stakes are enormous. Every competitor is on the starting line with the same powerful engine. But most of them are crawling. They do not trust their steering. They do not trust their brakes. They inch forward, terrified that any acceleration will send them off the track and onto the front page.

You are different. You have the best brakes, carbon-ceramic, tested at every speed. You have the best sensors, monitoring every curve before you reach it. You have a reinforced chassis that absorbs impact without compromising the driver. You have telemetry streaming back to the pit crew in real time, so they can see exactly what the car is doing at every moment. You are the only one on that track who can floor the accelerator. Not because you are reckless. Because you are governed.

Stop building AI bots. Start building a Governed AI Architecture. The safest companies will be the fastest. And the fastest will win.