Don’t Give the Agent a Lake. Give the Work an Application.

McKinsey published two pieces on agentic AI that sit six months apart and sound, at first, like they disagree.

In April 2026, Building the foundations for agentic AI at scale said the quiet part loudly: most enterprises have tried agents, almost none have scaled them, and eight in ten name data as the blocker. The prescription was architectural. Ingest once. Share meaning, not just tables. Give agents a governed consumption layer so they can read safely, and governed, reconcilable interfaces so they can write.

On 14 September 2026, Stacking the odds: A blueprint for successfully scaling agentic AI said something that should have been obvious in April. Enterprises are scaling agents faster than they redesign the work underneath. Agents do not fail quietly. They amplify every flaw in the operating system, immediately and at scale. Automating a broken process is failure pattern number one. Data that “exists” but is not authoritative is failure pattern number two.

Read together, they are not a contradiction so much as a sequence that consulting firms can sell in either order. First you need a foundation. Then you discover the foundation is sitting on a process nobody would defend. Both statements can be true. Neither is an architecture.

The architecture question is simpler than either article admits.

If the application is the problem, change the application.

If the job spans two applications, build a composite for the role.

Put AI inside that product.

Do not pour the mess into a lake and hire an agent to swim.

What the April article actually sold

The April piece is a data-platform article wearing an agentic headline. The numbers are useful. Two-thirds of enterprises have experimented. Fewer than ten percent have scaled to tangible value. Data quality, integration, and meaning are the usual suspects.

The seven principles are not wrong. Treat ingestion as a product. Give data definitions. Provide a controlled execution layer. A house needs a foundation. Fine.

To be fair to the April authors, they do not say “dump it in a bucket,” and they are not silent on writes. They speak the modern dialect: enterprise ontologies, knowledge graphs, domain data products, a consumption layer for context, and writes through agent-invoked tools and APIs that should “operate through governed, reconcilable interfaces rather than bypassing enterprise quality control.” Agents should retrieve and update inventory, fulfillment, CRM, and payments in real time. Principle 7 is a shared execution layer that enforces enterprise rules and guardrails.

That is a more serious write path than a lake. It is still a layer.

A reconcilable interface can log that a call happened, that it matched a schema, that it did not bypass quality control. It cannot invent a matching rule the application never had. It cannot validate a credit note if the validator lives in the system of record. Reconciliation is an audit property. It is not authority.

The mistake is assuming that renaming the lake, or putting a governed API in front of it, fixes the physics. An ontology is still a read-side projection. A reconcilable write is still a post into whatever the source system will accept. Whether you give the agent an uncurated lake, a pristine semantic graph, or a well-logged interface, none of those objects is the application. None of them holds the meaning of “customer” if SAP, Salesforce, and the claims engine still disagree. A governed consumption layer is a data lake that took Latin in prep school. A governed, reconcilable interface is the same lake with a receipts printer.

“Share meaning, not just data” is the right sentence in that article. The wrong implementation is a glossary in the platform, and a clean API in front of three meanings. The agent then reconciles fiction, confidently, and the interface will happily record that it did.

What September added, and what it still left open

Stacking the odds is the better article, because it is an operations article. The 88 / 39 split is the one that matters: most organisations use AI regularly, a minority can point to enterprise EBIT. The five failure patterns are the ones anyone who has shipped a process system already knows.

Automate the broken process instead of redesigning it.
Treat data readiness as a downstream problem.
Choose build versus buy before you understand the work.
Underinvest in change.
Install governance that reports and cannot stop anything.

The healthcare and medtech examples are doing real work. Version-control mismatches discovered mid-build. An off-the-shelf platform that could not express matching rules, so thirty percent of the intended value never appeared. A steering committee that met on schedule and had no authority to change scope.

The proposed remedy is a four-to-eight-week blueprint: named problem, redesigned workflow, operating model, data assessment, value-sequenced plan, governance that can kill a workstream.

That is closer to enterprise architecture than to a model bake-off. It still leaves a hole. “Redesign the workflow” can mean a workshop and a consumption layer. It can also mean changing the application that actually posts the transaction. Only one of those changes the system of record.

September tells you not to automate the mess. It does not insist that the mess lives in the application, and that the application is the thing you change.

A lake does not redesign a process

This is the move enterprises keep making.

The order-to-cash path is ugly. Exception handling is tribal. Master data is split. Someone proposes an agent. The agent needs context. Context needs a platform. The platform needs a lake, then a reconcilable interface so the agent can write without “bypassing quality control.” Six months later you have a governed copy of a process nobody fixed, and an agent that writes back through a well-logged API that still cannot express the rule.

You did not redesign work. You photographed it, then gave the photograph a POST method.

McKinsey’s own September diagnostic almost gets there: it cites disconnected environments and the lack of a shared consumption layer as blockers. April’s answer to the write is the governed, reconcilable interface and the shared execution layer. That does not abdicate the HTTP call. It still abdicates the business rule.

When the agent has to reserve inventory or flip a state machine, someone still has to run available-to-promise in the fulfillment system. If that rule is wrong or missing, a reconcilable API posts a wrong reservation with a better audit log. Quality control on the interface is not the same as the application being able to say no.

If the application cannot express the rule, buying a lake, a graph, or a reconcilable interface does not create the rule. That is the medtech matching-workflow story again. The platform was not the process. The process was never encoded.

Extend the application. If it is bad, change it.

The default that should win more often is unfashionable.

Put capability on the system of record. Agent in the transaction screen. Tool-calling against the application’s own APIs. An agentic panel that drafts, searches attachments, and proposes an action the application already knows how to validate. Coding agents that change the application. McKinsey’s own 2026 survey says nearly a third of organisations have already skipped a software purchase because they can build the feature internally.

That last point is the quiet strategic shift. If you can build the missing workflow in the system that owns the data, you do not need a second system that pretends to own it.

When the application is structurally wrong, because of vendor constraints, a mainframe that will not grow a clean API, or a BPO process that only exists as email, wrap it. Wrapping is still an application boundary. It is not a lake, and it is not a reconcilable interface in front of an unfixed app.

Writes are the test. If the agent cannot post through the same validation the human uses, you do not have automation. You have a suggestion engine with production side effects, even if every side effect is reconcilable.

Cross-system work is a composite problem, not an agent problem

The standard objection is: the job is not in one system. Claims needs policy admin and billing and documents. Planning needs forecast and inventory. The agent is how we span them. April’s multi-agent picture is the same objection in platform language: specialised agents updating several systems through a shared graph and fine-grained access.

That is how you get an improvised composite. Same joins, same write-back, same permission model, reconstructed every session from prompts and tool calls, now with a reconcilable log. You pay the integration cost forever, in tokens and incident reviews.

A role composite pays it once.

A composite application for a role is a designed contract:

which objects appear
which system is authoritative for each field
which writes go back where
which exceptions stay human
who owns the product when the meaning of “open case” changes

Claims adjuster workspace. Planner cockpit. Recruiter desk. These are not portals from 2005 with a chat box bolted on. They are the process, made explicit, for the person who does the job every day. The “governed, reconcilable interface” belongs inside that product as the contract to each system of record, not as a mesh over the unfixed landscape.

Stable work belongs in a product, not a conversation. A designed view is one query path. An agent re-discovers the join every morning. Audit is cheaper when the screen is the process.

Put AI in the composite. Draft the letter. Search the unstructured pile. Handle the long-tail exception the screen cannot enumerate. Use coding agents to evolve the composite. Do not use an agent as the integration layer so you can avoid designing the product.

That last sentence is the current fashion, and it is a repeat of enterprise application integration with non-deterministic glue.

A stack you can defend

System of record stays the system of record. Authority, validation, and audit live there.
If the process is wrong, change the application, or replace it. Do not copy it.
If the job spans two records, build a role composite with explicit read and write contracts.
Put AI inside that product. Assist, draft, exception-handle. Do not put it over the unfixed landscape.
A lake, a graph, or a reconcilable interface is a read-side cache and an integration contract, not where the process lives. Use them to talk to the application. Do not use them instead of the application.
Governance that cannot change the application cannot change the work. A steering committee over a lake is still decoration.

This is slower to demo than “we stood up an agent mesh on the enterprise corpus.” It is faster to own six months later, when someone asks who posted the credit note and which rule allowed it.

What to do with the two articles

Keep September’s warning. Do not automate a process you would not defend. Do not treat data readiness as a cleanup sprint after go-live. Do not buy a platform before you can write “the system may decide X, must escalate Y, must not touch Z.”

Keep April’s write sentence, then relocate it. Governed, reconcilable interfaces are how a composite talks to systems of record without bypassing quality control. They are not a substitute for the composite, and they are not a substitute for encoding the rule in the application that owns the transaction.

Discard the implication that the missing object is a consumption layer.

The missing object is usually an application. Either the one you already have, made honest, or a small composite for the role that was never given a screen.

Agents are a capability of that application. They are not a substitute for designing it.