In an agentic enterprise, architecture can no longer end at applications and integrations. It must define how outcomes are achieved across trusted data, orchestrated agents, clear decisions, and accountable people.

BY CARSTEN KRAUSE | CDO TIMES | OCTOBER 26, 2026

The Next Architecture Diagram Must Begin With a Business Outcome

Enterprise architecture has spent decades creating visibility into applications, technology dependencies, data flows, standards and investment roadmaps. That work remains indispensable, because an agent cannot reliably serve a customer through infrastructure it cannot identify or data it cannot trust. Yet the next executive question is no longer simply which systems support a capability. It is how a customer request, an employee judgment, a machine-generated recommendation and an authorized business action combine to deliver an outcome. An architecture function that cannot answer that question may maintain a high-quality inventory while the business continues to experience a low-quality journey.

Enterprise architects must help design the work performed across those systems, not merely record the assets already in place. Architecture becomes a discipline of coherence, where decisions, humans, agents and information move together toward a measurable business outcome.

Why the Classic Four-Layer View Is Necessary but Incomplete

Standards such as TOGAF and ArchiMate already acknowledge the relationship between business, applications, information and technology ^[3][4]. The problem is not that enterprise architecture lacks a vocabulary for business processes or capabilities. The problem is how practices are often rewarded:

1. completeness of a repository,
2. conformance of a solution,
3. coverage of standards and
4. speed of design review.

Those outputs can be useful leading indicators, but none independently establishes that a customer obtained a reliable answer or a technician restored equipment sooner. The architecture of work demands that those technical outputs be connected explicitly to owner-approved outcome measures.

Consider the difference between designing an order management application and designing the work of resolving a disputed order. The first exercise documents capabilities, interfaces, data stores and nonfunctional requirements. The second must also establish whose account of the order is authoritative, which evidence the agent may retrieve, when a human must intervene and what the customer sees when the answer is uncertain. It must specify the business decision that can be automated and the decision whose consequences require accountable judgment. Neither effort replaces the other, but the second exposes gaps that a neat system diagram can easily conceal.

FIGURE 1 | Architecture moves from an application-centric view toward an outcome-centric design of people, agents, decisions and records. Original conceptual visualization.

The Six Contracts of an Agentic Enterprise

A practical architecture of work can be represented through six contracts that every consequential human–agent workflow must honor.

1. The outcome contract names the customer or operating result, baseline and accountable owner.
2. The process contract defines necessary steps, handoffs, exception routes and service levels.
3. The information contract identifies authoritative data, meaning, freshness and permissible use, while
4. The action contract specifies which operations can be invoked by which identity and under what limits.
5. The judgment contract defines escalation, review and override, and
6. the evidence contract determines how decisions, tool calls, results and reversals will be logged and evaluated.

This model is intentionally broader than a platform reference architecture. Platforms describe where agents execute and where data are stored, but contracts determine whether those components form a trustworthy business system.

Microsoft’s current guidance on data architecture for AI agents makes the same underlying issue visible:

authoritative sources, governed retrieval and documented API access matter because agents can synthesize information and invoke actions across organizational boundaries ^[5]. Its agent orchestration patterns distinguish sequential, concurrent and handoff designs, each of which creates different coordination risks ^[6]. Architecture leaders should select those patterns according to the work and its risk profile, not because a fashionable multi-agent diagram appears more advanced.

FIGURE 2 | A proposed architecture-of-work reference model, from outcome to governed systems of record. Original framework informed by [3]–[6], [9].

Systems of Record Get More Important When Agents Multiply

Some commentary about agentic AI implies that systems of record will become obsolete as natural-language interfaces replace conventional enterprise software.

I believe that confuses the experience layer with the authoritative state of the business. Orders, assets, customer obligations, prices and financial postings still need consistent identities, transaction integrity, auditability and defined ownership.

Agents may change how information is discovered and actions are requested, but they do not eliminate the need to reconcile the truth across systems.

In fact, greater autonomy increases the consequences of weak master data and ambiguous business definitions, because an agent can act on bad context rather than merely display it.

The architectural response is not necessarily to centralize every application or migrate every record to one platform. It is to make sources of truth explicit, establish semantic and API contracts, maintain useful event histories and apply access policy consistently at the point of action. In many global enterprises the most realistic target is federation with clear ownership rather than a mythical single system for every entity. However, federation without standards can simply institutionalize a new version of fragmentation. The discipline is to distinguish where variation creates legitimate business value from where variation only makes work more expensive and AI less reliable.

Case Study: What mySchneider Illustrates About Composability

In her public July article, Hazak describes mySchneider as a digital experience platform using a composable, headless architecture to separate what customers encounter from the services running beneath the experience ^[1]. That choice is architecturally important because it allows a company to evolve an interaction without rebuilding every underlying capability. It also makes a demanding promise: composability creates business benefit only if the services, data and policies behind the interface remain coherent. The published article does not supply a quantified causal ROI for the architecture, and it would be wrong to invent one. The defensible conclusion is about the design principle rather than a claimed financial return.

Levi Strauss & Co. offers a related external illustration through a Microsoft customer account describing a unified Super Agent that orchestrates specialized agents and joins fragmented business information ^[8]. This is something I have described several years ago looking at master orchestration agents that manage niche AI agents sharing a common memory, actions and tooling.

The case reports faster access to insights and simplification but does not provide independently verified company-wide savings. That distinction matters because an integrated experience is a credible architecture pattern, not proof that every orchestration strategy produces positive ROI. Executives should examine whether shared data semantics, traceability and reusable capabilities are improving across journeys, not merely whether employees prefer a new interface. An attractive front end is an achievement only when the work behind it also becomes easier to govern and improve.

Case Study: Composable Infrastructure With Measured Results

A 2026 Microsoft case study about OYAK ANKER Bank reports that modular, component-based architecture and modern development practices helped reduce new-product time-to-market by approximately 80 percent ^[7]. The same customer account says around 55 percent of previously manual operational workloads are automated and incident-resolution time fell by 50 percent. These are vendor-published outcomes from a specific banking context, and the reported improvements cannot be assigned solely to any one technical component. Still, they illustrate a credible executive connection between design choices and operational performance. Modularity becomes meaningful when it makes change safer, reduces avoidable manual work and accelerates delivery of products customers actually use.

The relevant lesson for enterprise architecture is that outcome measurement should be included in the design review itself. A proposal for a shared identity service should explain how it reduces onboarding friction or risk exposure. A product-data contract should identify which disputed decisions or reconciliation loops it will prevent. An agentic integration platform should show the cost of its controls and the reduction in manual handoffs it expects to enable. These are not after-the-fact communications tasks for a transformation office; they are part of the logic of sound architecture investment.

FIGURE 3 | Vendor-reported OYAK ANKER Bank outcomes. Each percentage represents a different measure, not an additive benefit. Source: Microsoft customer story [7].

Governance Must Follow the Decision, Not the Diagram

An AI agent can be connected to a system, authorized to retrieve context and still be unsuitable for a specific business action. A supplier-price update, a credit approval and a read-only product recommendation have different consequences even when they use the same application or model. BCG’s work on agent authorization argues for policies that constrain both the objective and the path an agent takes to reach it ^[10]. NIST similarly frames AI risk management as an ongoing practice of governing, mapping, measuring and managing risk rather than a one-time checklist ^[9]. The architectural unit of control should therefore be an action in context, bounded by purpose, identity, transaction limits, evidence and escalation.

For an architect, this changes the deliverables of governance from a static compliance statement to a set of executable and inspectable rules. The design should reveal which agent or person can invoke each function, which record provides authority and which events trigger a required handoff. It should document what the system will do when a model is uncertain, a data source becomes stale, or a downstream application is unavailable. It must also preserve a path for revocation, rollback and incident investigation. These details may feel operational, but once agents are allowed to act, they become central architectural properties.

FIGURE 4 | Six design contracts connect business intent to trustworthy AI execution. Original editorial framework.

A New Scorecard for the Enterprise Architecture Practice

Enterprise architecture leaders should continue tracking technical debt, standards conformance, application health and reuse, but those indicators need a second dimension.

The business dimension measures elapsed time across key journeys, number of avoidable handoffs, critical-data quality, control exceptions, speed of authorized change and realized outcome value. The architecture practice should publish a small number of cross-domain measures that business owners recognize as their own, rather than produce an elaborate report that only architects read. It should also track how many critical decisions and agent actions have explicit ownership and tested fallbacks. A useful architecture scorecard therefore asks whether the enterprise is becoming simpler to operate, safer to change and easier for customers to navigate.

This requires a different engagement model with product leaders, operations, data owners and risk teams. Architects need to join the conversation before a solution is selected, while business leaders must accept accountability for standardizing processes that span functions. Architecture review should offer fast paths for low-risk, reusable patterns and reserve deeper scrutiny for consequential decisions and shared dependencies. The best practice will not be the one that stops the greatest number of projects; it will be the one that helps more important initiatives arrive at better designs earlier. In an agentic enterprise, the architecture function earns its relevance by making business change more coherent and measurable.

The First 90 Days of an Outcome-Centric Architecture Practice

Within 30 days, select two enterprise journeys that cross organizational or application boundaries and map them from outcome to decision to data to action. Identify the official applications and the unofficial work required to keep the process moving. In the following 30 days, define authoritative data owners, action permissions, escalation rules and outcome metrics for one journey and build a reusable reference pattern. In the third month, test that pattern in a limited production scope with a business owner, security partner and operations team who can judge success or failure. This program is intentionally small enough to learn from but consequential enough to expose the difference between a software integration and a redesigned operating capability.

The CIO should resist turning the work into another central architecture bureaucracy with a glossy enterprise model and no delivery ownership. Likewise, the enterprise architect should resist declaring victory because a new platform has been standardized or an agent has been connected. The target is a pattern that can be applied responsibly to the next journey with less effort and greater confidence.

McKinsey’s research on human–agent organizations reinforces the importance of coordinating organization design, ownership, talent and technology rather than optimizing each in isolation ^[11]. The future enterprise architect is not simply the custodian of systems of record but a designer of the work that makes them useful.

ECI: The Architecture of Elevated Collaborative Intelligence

Elevated Collaborative Intelligence (ECI™) provides a practical lens for this next architecture mandate:

ECI = (HI + AI) × T − R

Here, HI represents Human Intelligence, AI represents Artificial Intelligence, T is the Technology Accelerator, and R represents Risk and Regulatory Constraints.

It is a conceptual leadership framework, not a numerical performance formula. People must define the purpose, exercise judgment, own consequential decisions and manage exceptions; AI can expand analysis, coordination and execution; and enterprise architecture must make their collaboration interoperable, reusable, observable and governed. When that collaboration removes unnecessary handoffs and protects accountability, the next business journey can be delivered with less rework and greater confidence.

The future enterprise architect is not simply the custodian of systems of record, but the designer of work in which human and artificial intelligence produce measurable outcomes together.

The CDO TIMES Bottom Line

Enterprise architecture is not becoming less important as AI agents mature; its mandate is becoming more concrete. Systems of record remain essential, but value is realized through the journeys in which people, data, decisions and agents produce business outcomes.

Elevated Collaborative Intelligence (ECI™)—ECI = (HI + AI) × T − R—offers an operating lens:

human intelligence supplies direction, judgment and accountability; AI expands analytical and execution capacity; technology accelerates trusted coordination; and risk and regulatory constraints must be designed into the work.

The CIO should demand repeatable, business-owned outcomes rather than another central architecture bureaucracy; the architect should demonstrate fewer handoffs, less rework, stronger controls and better employee and customer results—not merely standardized platforms or connected agents.

The true test is whether the next journey can be delivered with less effort, more trust and clearer ownership than the last.

Sources and Verification

[1] Audrey Hazak, “Building resilient technology for a customer experience that is simpler, faster, and more human,” July 30, 2026 https://blog.se.com/digital-transformation/2026/07/30/building-a-resilient-tech-stack-for-customer-experience/

[2] Audrey Hazak, Day 45 as Group CIO, publicly indexed LinkedIn reflection https://fr.linkedin.com/in/audreyhazak

[3] The Open Group, ArchiMate specification and certification program https://www.opengroup.org/certifications/archimate

[4] The Open Group, Benefits of TOGAF Standard, 10th Edition https://www.opengroup.org/togaf/benefits

[5] Microsoft, “Data architecture for AI agents across your organization,” Cloud Adoption Framework https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/data-architecture-plan

[6] Microsoft, AI agent orchestration patterns, Azure Architecture Center https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns

[7] Microsoft Customer Stories, OYAK ANKER Bank transformation, 2026 https://www.microsoft.com/en/customers/story/27135-oyak-anker-bank-microsoft-365-apps-for-enterprise

[8] Microsoft Customer Stories, Levi Strauss & Co. simplification with Microsoft Foundry, June 2026 https://www.microsoft.com/en/customers/story/26647-levi-strauss-and-co-microsoft-foundry

[9] NIST, AI Risk Management Framework, Govern/Map/Measure/Manage https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

[10] BCG, “The Authorization Gap,” September 22, 2026 https://www.bcg.com/publications/2026/authorization-gap-ai-agent-governance

[11] McKinsey, “AI is changing work. Now it has to change the organization,” October 5, 2026 https://www.mckinsey.com/capabilities/people-and-organization/our-insights/ai-is-changing-work-now-it-has-to-change-the-organization

Evidence note. Published company case studies and self-reported survey responses are identified as such. No unpublished Schneider Electric operating metrics are used. Figures with original frameworks are editorial analysis, not observed company results.

• Rethinking enterprise architects’ roles for agile transformation – CIO
• CDO TIMES AI Agent Architecture Framework
• The Dawn of Digital Delegation: A Seismic Shift of Autonomous Agents Reshaping Work
• Artificial Intelligence News for the Week of December 20; Updates from Anthropic, Cognizant, NVIDIA – Solutions Review
• Redefining enterprise transformation in the age of intelligent ecosystems – CIO

CDO TIMES | Strategic analysis for CIOs, CDOs, enterprise architects and operational leaders.