The dashboard was beautiful. Forty-three signals from support tickets, sales notes and churn interviews, clustered overnight by a model nobody had to configure, labelled “Onboarding friction.” Red, trending up, impossible to ignore.

The meeting took eleven minutes. Great, so we fix onboarding. Six weeks later a shiny new setup wizard shipped. Usage of the wizard was excellent. Churn among the customers who had actually complained didn’t move.

When someone finally read the forty-three signals instead of the label, the picture was different. Most of them came from enterprise tenants above fifty users, and most of those were stuck on one thing: they couldn’t configure DNS for their own domain without a support call — roughly eleven days of implementation time per deal. The wizard was a fine answer. To a question nobody in that cluster had asked.

Nothing in this story is a failure of sensing. The signals were real, the clustering was decent, the team shipped fast. What failed was the step between “here is what’s happening” and “here is what we intend to change.” I call that step Frame.

(And yes, a cluster. The signal kind. Platform engineers may unclench.)

Between the signal and the lever

The best vocabulary I’ve found for this problem comes from Elisabeth Hendrickson and Joel Tosi’s new book, Signals & Levers. Two definitions carry the whole thing:

“A signal is an observable characteristic of the system.”

“A lever is a choice that causes a shift in the system. Every decision you make is potentially a lever, no matter how large or how small.”

Read the signals, find the levers. It’s a deceptively simple loop, and the book is full of ways to do both well.

What I want to add is the step in between. Before anyone can choose a lever, someone has to decide what the signals mean — which problem they point to, for whom, and which choices are even on the table. That decision is Frame. The book already points in this direction; I want to make it explicit. Between the signal and the lever sits the frame, and because so much depends on it, I treat it as a step of its own: signal → frame → lever, and back to signal to check whether the lever actually was one.

With humans doing all the work, Frame used to happen implicitly, in hallway conversations and in the heads of senior people, often through arguments. John Cutler calls this positive friction: the disagreement that slowed things down was also where weak framings got caught. With agents, that friction disappears, and Frame can’t stay implicit anymore. Agents act on whatever framing they’re handed, and they don’t wander down the hallway to ask.

I · Five ways the dashboard misled us

Signals & Levers offers five recommendations for reading signals. Read them next to the onboarding dashboard and they work like a post-mortem.

“Scan broadly and systematically. Use the CREATE framework to overcome blind spots.” CREATE stands for capacity, risk, execution, adaptability, trust and economics. The cluster lived entirely in execution — friction in a workflow. Nobody looked at economics (eleven days of implementation time per deal) or at capacity (an implementation team that was quietly saturated).

“Attend subtle signals. The loudest signals often mislead.” The loudest complaints came from small customers who found the setup screens confusing. The expensive pain was quiet: a few enterprise accounts, each one escalating through a different channel.

“Distinguish noise. … What seems like noise might be a signal if it creates a pattern across multiple aspects of your system.” A single DNS ticket looks like noise. The same issue showing up in support, in sales notes and in implementation timesheets is a pattern.

“Use goal-question-metric thinking. Start with what you are trying to accomplish.” The goal was never “improve onboarding”. It was expansion revenue in the first quarter after a deal closes. Elisabeth and Joel put it precisely: GQM helps you “avoid drowning in data by starting with what you’re trying to accomplish, then working backward to the signals that matter.”

“Question your proxies. … Ask: What is this proxy really measuring?” “Forty-three” measures how many people complained. It says nothing about what the complaints cost.

The book’s own favourite example of a misread proxy is worth repeating: a platform team consolidating duplicate tools after an acquisition decides to keep the “highest-quality” option, judged by open bugs. One tool has a massive backlog, the other has none. Obvious choice — until someone notices the bug-free tool has no users. The issue count was a signal, just not about quality. It was about adoption.

A cluster is that problem at scale. It aggregates what is observed. Elisabeth and Joel are blunt about what matters instead: the key is to “act where the pain is caused, not where it is observed.” That sentence is the job description of Frame.

II · Every playbook starts one step too late

IT Revolution’s new Enterprise Technology Leadership Journal (Fall 2026) is the best collection of agent-era delivery thinking I’ve read this year, and it makes the gap unusually easy to see.

Timothy Cochran, Bryan Finster, Tim Ottersburg, Scott Prugh and Amy Willard open When Coding is Free, Where is the Bottleneck? with an illustrative value stream: about 281 days of lead time, of which actual coding is roughly 32. Make coding free and nearly nine-tenths of the wait is still there. The largest single block in their figure is the fuzzy front end — requirements — at 93 days.

Their bottleneck table names the failure mode in that phase with five words I’d frame and hang on the wall: “The agent builds the wrong thing quickly.” Their intervention is to use AI to synthesize requirements, expose ambiguity and generate testable acceptance criteria before implementation. That works — once someone has decided what the requirement is for. Synthesizing requirements from forty-three signals produces forty-three well-formatted requirements for a setup wizard.

The paper names the metric for the missing step, too. Among the leading measures of whether a dependency left the system, the authors list “the time from idea to clear intent.” They mention it in passing, as one of four. It deserves a piece of its own, so let me pick up the thread.

A second paper in the same issue arrives at the same place from the other end. Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup and James Wickett, building a pattern language for code review in the age of agents, conclude that “ambiguity in intent is the dominant source of failure” — and that by the time code reaches review, the most consequential decisions have already been made.

Anthropic’s AI-Native SDLC Playbook operationalizes the agent-era loop more concretely than anything else I’ve seen, and it makes the same starting assumption. Stage 1 captures intent “in the originator’s own words” as an intent.md, which a product owner reviews and accepts. That’s the right artifact. But it arrives as one originator’s view. Forty-three signals would produce forty-three of them, each well-formed, none of them a frame.

One paper measures from idea to clear intent. The other shows that unclear intent is what review keeps catching too late. And the playbook that runs the loop starts with intent as given. Frame is the step that comes before all three.

III · What Frame produces

FIG 1 — From cluster to intent. The clock that matters runs between them.

Frame takes a cluster and returns an intent.

The options are where the real work is. For the onboarding problem there are at least four serious ones, and each is a different lever:

• (a) Self-service DNS in the product — fix it once, for everyone.

• (b) Customer-success-led onboarding for tenants above fifty users.

• (c) Partners or consulting take over the setup.

• (d) A commercial decision: offer onboarding free of charge, because the expected expansion is worth more than the cost.

Every one of them addresses the pain. Every one of them pulls on the system somewhere else. This is where CREATE does double duty: the same six dimensions that help you read the signals help you weigh the options.

Two things jump out that a feature backlog would never show. The fastest lever (b) is also the most reversible. And the most generous one (d) is the hardest to undo — nobody enjoys explaining why something that used to be free now isn’t.

A table is still a list. To see how the levers interact, Elisabeth and Joel use causal models: circles for quantities, clouds for qualities, arrows marked + when two things move together and − when they move in opposite directions, and a question mark wherever a decision could change the picture.

FIG 2 — The onboarding loop, drawn in the causal-model notation from Signals & Levers.

The model makes the uncomfortable part visible: this is a loop. More expansion means more onboarding load, which means longer waits, which erodes confidence and, eventually, expansion. Lever (a) cuts the days per deal; levers (b) and (c) add capacity; lever (d) props up confidence directly and leaves the loop itself untouched.

In my experience, drawing a model like this together doesn’t make dominant stakeholders less dominant. It does put sales, product, customer success and finance in front of one picture, and that alone changes the conversation. The five maps from Steve Pereira and Andrew Davis’s Flow Engineering complement this well; the outcome and dependency maps in particular often surface the same tensions from a different angle.

So we choose (b), because it’s fast, reversible, and tells us within a month whether implementation time really is the driver. If it is, (a) goes on the roadmap with evidence behind it.

Elisabeth and Joel have a line for why the options matter at all, built on a children’s board game. In Chutes and Ladders you roll a die and do what the board says. What’s the winning strategy? There isn’t one: “In the absence of choice, there can be no strategy.”

A frame with one option is not a decision. It’s an assumption with a deadline.

IV · Why you can’t hand Frame to an agent

The obvious move in 2026 is to ask a model to frame, too. It will produce something that looks exactly like the intent above, in less time than it took you to read it. That’s the problem.

When an intent is vague at the top, it’s usually not because nobody thought hard enough. It’s because two people with authority want different things, and the vagueness lets both of them sign. Improve onboarding is what sales (enterprise deals closed faster) and product (self-service for the long tail) can agree on precisely because it doesn’t choose.

Vague intent is written-down stakeholder conflict. An agent can’t absorb that kind of ambiguity. It resolves it — by picking a side implicitly, at speed, and producing something plausible enough that nobody notices which side lost until the numbers come in.

That’s why Frame needs a human with a mandate. Not because humans write better frames, but because closing a frame means accepting a trade-off on behalf of the organization. The agent can draft the options, surface the evidence, even fill in the CREATE table. Someone with the authority to say we’re doing (b), and here’s what we’re giving up has to close it.

If you use coding agents, you already know the pattern. The planning step feels like a delay. Spending more time there is also the single most reliable way to get a better result — and it’s where the blind spots surface, while they’re still cheap. Anthropic’s playbook makes plan mode the default starting point and has the engineer ask which options Claude chose not to take. Frame is plan mode for the organization.

V · Framing when the information is thin

Most frames start with less information than the onboarding example. A few moves help:

• Talk to the people behind the signals — the support agent who filed the tickets, their peers, the implementation lead. The cluster is a summary; they have the details.

• Look for the pattern across segments. Does the same issue show up in other countries, other industries, other customer sizes? If it doesn’t, that’s a signal too.

• Run small experiments on more than one option to find the lever with the most pull, before committing to the expensive one.

• Close an early feedback loop with customers and internal experts, so the intent stays reversible if it turns out you framed the wrong problem.

One warning from the book that matters more than it looks: “Silence is a signal. When someone asks a question in a meeting and no one replies, it could be an indicator of disagreement, misalignment, or lack of psychological safety.” The first time a team runs a customer-problem investigation like this, I’ve found silence often means something simpler: uncertainty about what’s really being asked. The fix is to bring the intent of the investigation with you — we want to make sure we’re solving the real problem, not the one on the dashboard.

VI · Did you actually pull a lever?

Elisabeth and Joel have a test that every frame should carry with it:

“If you make a choice—change something—and the system does not change at all, whatever choice you made was not a lever within the system.”

That means a frame isn’t finished when we’ve decided what to do. It’s finished when we’ve also decided how we’ll know whether it worked. For the onboarding case: implementation days per deal and first-quarter expansion for tenants above fifty users, checked after eight weeks. If neither moves, (b) wasn’t a lever — and we learned that in a month, not a year.

And there’s the second measurement, the one Cochran and colleagues named: time from idea to clear intent. Start the clock when a cluster crosses whatever threshold makes someone say “we should do something about this.” Stop it when a frame exists that a named owner has accepted: outcome hypothesis, constraints, at least two options, a choice, and a way to check whether the choice was a lever.

Three questions to run on Monday, no tooling required:

1. Take your last five shipped features. For each, can someone state the outcome hypothesis in one sentence — and name the option you didn’t choose?

2. For one recent initiative, count the days from the first cluster or complaint to a decision a named person actually owns. If the answer is “it’s complicated”, that’s your answer.

3. Pick one decision from last quarter. Did the system change afterwards? If nobody checked, you don’t know whether it was a lever.

Close

For thirty years we made building cheaper. Then AI made sensing cheaper, the argument of The Feedback Problem Is Solved. The step between them — turning what we observe into what we intend — is now the scarcest capability in most organizations, and it doesn’t respond to more compute.

Coding was never most of the 281 days. Frame might be.

The next piece picks up what follows: once a frame is closed, who carries the intent? That’s where Team Topologies comes in — and where agents start changing the answer.

Sources

• Elisabeth Hendrickson, Joel Tosi: Signals & Levers: Systems Thinking Tools to Unblock Software Delivery. IT Revolution, 2026. Adapted as Signals and Levers: How to CREATE Real Change, Enterprise Technology Leadership Journal, Spring 2026.

• Timothy Cochran, Bryan Finster, Tim Ottersburg, Scott Prugh, Amy Willard: When Coding is Free, Where is the Bottleneck? A Guide for Leaders Building Agent-Ready Delivery Systems. Enterprise Technology Leadership Journal, Fall 2026.

• Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup, James Wickett: Agentic AI and Code Reviews: Toward a Pattern Language for Code Reviews in the Age of Agentic AI. Enterprise Technology Leadership Journal, Fall 2026.

• Louis Claxton (Anthropic): The AI-Native SDLC Playbook. Anthropic, 2026.

The Enterprise Technology Leadership Journal is published by IT Revolution under CC BY-NC-SA 4.0.

Part of the Intent Architecture body of thought — About.

The model as it stood in early 2025 — three layers, five phases, one cycle for everything.

Eighteen months ago I was telling every organization I worked with the same thing: you don’t have an innovation problem, you have a feedback problem. The creative capacity is already in the building. It’s in the sales engineer watching prospects walk away over a missing integration. It’s in the support analyst emailing the same workaround fifty times a month. It’s in the consultant writing the same playbook page for every new engagement.

What was missing wasn’t ideas. What was missing was the wire — from those observations to the people who could act on them, and back again to the observer.

I built a whole framework around that claim. I wrote the first version of it in early 2025 and spent the next eighteen months revising it against real organizations — three architectural layers, five operating phases, feedback loops as the operating medium rather than a final stage. The diagram above is that version, unretouched. I still think the diagnosis was correct.

I also think it has a shelf life of about another year.

Because the wire is being installed, and nobody had to run a culture change program to do it. An agent that reads every support ticket, every call transcript, every telemetry anomaly, and turns them into structured, deduplicated, cross-linked signals is not a research project anymore. It is a weekend of integration work and a monthly bill. The thing I spent eighteen months arguing organizations should build, they are now getting as a side effect of buying tools.

This is the uncomfortable part of being early: you get to watch your hard problem turn into somebody’s feature.

So the honest question is not whether the feedback framework was right. It’s what happens next — because a bottleneck that disappears doesn’t leave a smooth road behind it. It leaves the next bottleneck, which was always there, standing in plain view with nothing in front of it.

II. What actually dissolved

I keep a list of the eight obstacles that framework was designed to defeat. It is worth going through it honestly, because five of them are simply gone, and the three survivors tell you where the work moved.

Siloed feedback collection across teams. Solved — but not the way anyone planned. We assumed the fix was consolidation: one platform, one process, everyone submits in the same place. The actual fix is extraction. You don’t unify the silos, you read them. Agents don’t care that support uses Zendesk, sales lives in Gong and product analytics sits somewhere else entirely. Consolidation was a workaround for the fact that reading everything was expensive. It isn’t anymore.

No unified aggregation platform. Dissolved with the previous one. Aggregation is a pipeline now, not a platform program. The build-versus-buy debate that used to consume a quarter simply doesn’t have stakes worth arguing about.

Difficulty correlating feedback across personas. Solved, and this one stings a little, because finding non-obvious connections across domains was supposed to be the hard, human, insight-generating part of the job. Cross-domain similarity is precisely what embedding models are good at. The thing I described as an institutional Zettelkasten that organizations had to cultivate is now something they can provision.

Technical integration complexity. Largely solved by standardized connectors. What remains is a permissions and privacy problem, which is real, but it is a different problem with different owners.

Limited resources for infrastructure. Dissolved. The sensing loop is a two-week build, not a funded program. The cost moved from construction to operation.

Five for five. Now the survivors.

Resistance to change didn’t go away, it changed shape. Nobody is resisting a new intake form anymore. They’re resisting an agent that listens to their customer calls. That is not process friction — it’s a surveillance question, and it deserves a real answer rather than a change-management workshop.

Culture not aligned with continuous feedback is not just unsolved, it got harder. “You said, we’re doing” was always the fuel of the system: the originator who hears back is the originator who writes the next signal. But the moment that reply is visibly machine-generated, it stops being an acknowledgment and becomes a receipt. Automated closure of the loop is not closure of the loop. We have made it trivially cheap to produce the form of being heard, which means the substance of being heard is now harder to signal, not easier.

Stakeholder skepticism about ROI moved rather than resolved. The question is no longer “what does this platform get us.” It is “how much autonomous execution are we willing to be accountable for.” That is a risk conversation wearing an efficiency conversation’s clothes, and executives can smell the difference.

Five technical problems evaporated. Three trust problems remain. That ratio is the whole story of the last eighteen months, and not just in this domain.

III. The bottleneck moved twice

The first piece in this series argued that the bottleneck moved from building to intent. IT Revolution’s new Enterprise Technology Leadership Journal puts a number on the first half of that claim: in the illustrative value stream Cochran, Finster, Ottersburg, Prugh and Willard walk through, coding accounts for 32 of 281 days. Take it to zero and almost everything that made you wait is still there — much of it in the fuzzy front end.

What I want to add is the step in between. For a brief window, the bottleneck was sensing: once you could ship weekly, the limit was knowing what to ship. That’s the window my feedback framework was built for, and it’s the window that just closed. What remains is intent — deciding what should exist, and saying it precisely enough that humans and agents can execute it without loss.

This is not a new observation in the abstract — “garbage in, garbage out” is older than any of us. What’s new is the amplification factor. When implementation was slow, ambiguity was cheap, because the friction of building gave you a dozen chances to catch it. Someone would hit an unclear requirement on Tuesday and ask about it. The estimate would come back absurd and force a conversation. Code review would surface the misunderstanding. The slowness of the system was, among other things, an error-correction mechanism nobody designed and everybody relied on.

recently gave this a better name: positive friction — the moments where a human had to stop, interpret and decide. His warning is the right one: remove it without replacement and you get “AI flattening layered on AI flattening, with no thread back to reality.”

An agent does not ask on Tuesday. An agent does not find the requirement absurd. It takes your ambiguity and converts it, at speed, into a coherent, well-tested, beautifully documented implementation of the wrong thing.

Which produces the defining economic fact of this era: velocity without clarity is more expensive than slowness. Not less valuable — more expensive. You now pay full price for the wrong thing, faster, with better documentation explaining why it was correct.

IV. Three things that didn’t survive contact with agents

I rebuilt the model. Before describing what replaced it, here’s what broke, because the failures are more instructive than the fix.

The funnel broke. Every innovation framework, including mine, assumed a funnel: many signals in, few things out, filtering as the core value-adding activity. Filtering was valuable because building was expensive — you had to be right before you started. When a working prototype costs four hours, the funnel inverts. For a large class of questions, building the thing is now cheaper than the meeting about whether to build the thing. Any process that forces both is charging you twice.

The queue broke. Phases implied handoffs, handoffs implied queues, and queues were where work went to die — but at least they served a purpose: they rationed a scarce resource. With that resource no longer scarce, a queue is pure cost.

The single loop broke. My old model had one cycle. Everything entered at Capture and traveled the same road. That was always a simplification, but a tolerable one, because everything moved at roughly the same speed. Now a prototype iterates in an afternoon while a pricing decision takes six weeks of legal review. Forcing both through one cadence means either governing experiments to death or shipping irreversible decisions like experiments. Most organizations, in my experience, manage to do both simultaneously.

V. The Intent Lifecycle

So: seven nodes, three loops, four enablers. Let me be specific, because the detail is where the argument lives.

The nodes

1 · Capture — what we perceive. Agents extract structured, atomic signals from calls, tickets, telemetry, repositories, reviews. Humans keep writing signals too, deliberately, because a person choosing to report something carries intent that telemetry never does. Volume is now free; the human channel exists for the thing volume can’t buy.

2 · Connect — what belongs together. Clustering, deduplication, cross-domain linking: almost entirely machine work now. What stays human is interpretation — deciding which pattern is a problem and which is merely a correlation. The model will happily find both and present them with identical confidence.

3 · Frame — what the actual problem is. This is a new node, and the most important one. A cluster is not an intent. Turning “forty-three signals about onboarding” into “enterprise tenants above fifty users cannot self-serve DNS configuration, which costs us roughly eleven days of implementation time per deal” is a different act, and it is where the leverage now sits. An agent can draft a frame. A human decides which framing governs. That decision is not delegable, because it is the single point in the system where a wrong answer is both invisible and compounding. This is where I part ways with the most practical agent-era delivery playbook I’ve read this year. Cochran et al. name the failure mode exactly — the agent that builds the wrong thing quickly — and address it by having AI synthesize requirements and acceptance criteria. That works once someone has decided what the requirement is. Frame is the step before. A frame worth committing to carries at least two options and what each would cost us.

4 · Commit — what we take responsibility for. Notice what changed here. Commit used to be primarily about cost: we can’t build everything, so we choose. Building is no longer the constraint. What remains scarce is what you can operate, support, secure, explain to a regulator and live with. Commit is now a filter for consequence, not for capacity. A bet that doesn’t name the options it rejected isn’t a choice. It’s momentum with a signature.

5 · Specify — how intent becomes executable. The second new node. Specification used to be documentation: a description of something a human would then build, valuable mainly as communication. Now it is the interface through which you program the system. Stories, acceptance criteria, edge cases, non-functional requirements, explicit out-of-scope — or, for non-deterministic features, an eval set that defines what good looks like instead of what the thing does. The spec is written once and consumed six times: engineering scope, QA plan, security review, launch criteria, documentation, and agent context. That sixfold reuse is the entire answer to “we don’t have time for specs.”

6 · Deliver — what actually comes into existence. Multi-track delivery — product and enablement and documentation and migration and go-to-market — was the promise every framework made and none kept, because the non-product tracks never had budget. Generated from a shared spec, they are close to free. The ambition wasn’t wrong. It was just unaffordable.

7 · Learn — what it changed. Outcome review, not output review. The new part: learning writes back into the shared context, so the next cycle starts smarter. This is the only mechanism in the whole model that produces compounding rather than throughput.

The three loops

This is the structural claim, and the part I’d defend hardest:

• The Sensing Loop (Capture ↔ Connect ↔ Learn) runs continuously and mostly autonomously. It produces situational awareness, not decisions.

• The Fast Loop (Frame → Specify → Deliver → Learn → Frame) runs in hours or days, for cheaply reversible work. It deliberately bypasses Commit. It bypasses the committee, not the friction. The friction moves into Frame — which is why Frame stays human even here.

• The Governance Loop (Connect → Frame → Commit → Specify → Deliver → Learn) runs in weeks or months, for work that is expensive or impossible to undo.

Which loop applies is decided by reversibility, not by hierarchy or budget size. Classify work three ways — cheaply reversible, expensively reversible, irreversible — and route accordingly.

Reversibility as a decision criterion isn’t mine. Amazon has run on one-way and two-way doors for two decades, and I spent years inside an organisation where that vocabulary was ambient — you learn to ask can we undo this before you ask who signs off. What’s new here is where it gets applied. In the human version, reversibility tells a leader how much deliberation a decision deserves. In an agentic system it becomes a routing rule: it decides which loop the work enters, and how much autonomy an agent is permitted inside it. The same question, load-bearing in a place it was never designed for.

Run this audit on your own portfolio. Take the last twenty initiatives and classify them. In every organization where I’ve done this, roughly seventy percent land in “cheaply reversible” — and all of them went through a governance process designed for the other thirty. That number is usually more persuasive than any framework diagram I can draw.

The four enablers

Running horizontally across every node:

Context Substrate — the shared, versioned store of signals, frames, decisions, specs, evals, telemetry and codified skills. This is what agents actually work from, and it is the real asset. Not the software. The knowledge about the product. Every derived artifact — cluster, frame, spec — links back to the signals it came from, and says how much of it a machine wrote. That thread to reality is what separates a substrate from a very confident summary.

Agent Fabric — orchestration, a charter and a regression set per agent, observability, cost control. Past roughly three production agents, fleet management becomes its own discipline whether you staff it or not.

Platform & Flow — golden paths, self-service, bottleneck removal. Agentic capability is an overlay across your existing platform layers, not a fourth platform.

Trust & Accountability — human-in-the-loop design, the non-delegability of accountability, governance, and visible, credible closure of the loop.

Three of those four got cheaper in the last two years. The fourth got more expensive. Guess which one determines whether this works.

VI. What humans keep

The practical question every leader asks at this point is where the humans go. The answer is more specific than “in the loop,” and it’s better expressed as a matrix than a slogan: for each node, at each reversibility class, what autonomy level is permitted?

Run that exercise honestly and a shape appears. The edges of the process — perceiving, measuring, and yes, building — tolerate high autonomy. The middle does not. Frame and Commit sit at low autonomy across every reversibility class, including the cheap one.

That’s not caution. It’s the job description. Humans decide what holds; agents execute what holds.

Which means the widely-forecast obsolescence of product roles is only half right, and the useful half is the distinction people keep skipping. What’s genuinely threatened is the process role: collecting requirements, writing tickets, grooming the backlog, shepherding handoffs. That work was always a tax on the slowness of the system, and the system isn’t slow anymore.

What’s not threatened is the capacity to look at forty-three noisy signals and say: this is the problem, this is what we believe will change if we solve it, this is how we’ll know, and here’s what we are explicitly not doing. That skill just became the control surface for the entire production system. The people who have it are about to find out they were underpriced.

Kent Beck, Cornelia Davis and their co-authors arrive at the same profile from the talent side, in the same journal: what organizations now need are “architects of intent.” They also name the uncomfortable corollary. The process work I just called a tax was, for many people, where they learned to frame in the first place. Remove it, and the struggle has to be built back in on purpose — they call it synthetic struggle — or the underpriced skill simply stops being produced.

The matrix also gives you something rarer than a philosophy: a progress metric. Every cell you can raise one level without your correction rate rising is coordination work you’ve permanently removed. Maturity becomes measurable — how many cells sit how high, at what error rate — instead of a slide with five stages and a rocket on it.

VII. The part that doesn’t get automated

Let me come back to the three survivors, because I don’t want to end on the engineering.

An organization can install every node in this model, wire up a competent fleet, and still fail — for exactly the reason my original framework identified, and which none of this technology touches. Feedback collected and not acted on is worse than no feedback at all. An open loop costs more than silence, because it teaches people that speaking up is theater.

Agents raise the stakes on that in a specific and slightly perverse way. They make it trivially cheap to generate the appearance of closure: personalized replies, status updates, tidy summaries explaining how valuable everyone’s input was. Volume of acknowledgment goes up while its information content goes to zero — and people are remarkably good at detecting this, usually faster than the person sending it expects.

So the discipline that mattered before matters more now, and it costs the one thing that hasn’t gotten cheaper: a named human being spending attention. Someone who says, in their own words, we read your signal, here’s what we decided, here’s why, and here’s what happened. Including the ones where the answer was no. Especially those.

That is not a nostalgic flourish. It is the input-scaling mechanism of the entire system. Every node downstream depends on signal volume that depends on people believing the wire works.

The same applies to the surveillance question. If an agent reads your team’s customer conversations, the people in those conversations should know it, see what was extracted, and be able to correct it. Not because a regulation requires it — though one probably does — but because the alternative produces a sensing layer that people learn to route around. And a signal system people route around is worse than none, because you’ll trust it.

VIII. Where to start

Not with agents. With two weeks and three questions.

Take five things customers have told you repeatedly over the past six months. Who heard each one first, when, and how long until a decision followed? The answer is usually a three-digit number of days, or “never.” That number has a name now: Cochran et al. list time from idea to clear intent as a leading indicator — and never unpack it. This question is how you start measuring it.

Take your three largest initiatives this year. Where is the intent written down? If the answer is a slide deck, it isn’t.

Take the last twenty initiatives and classify them by reversibility. Compare that distribution to the governance every one of them passed through.

Three numbers. They will be uncomfortable, and that’s the point: they establish that you have a problem in the middle of your process, not at the ends, before anyone spends money at the ends. From there the sequence is boring and it works — one value stream, three sources, sensing loop first; then a shared context substrate and a fortnightly ritual whose only question is “is there an intent here”; then specification discipline in one team; and only then the fleet.

If you start with the fleet, you will automate your silos and call it transformation. I have watched this happen. The demo is always excellent.

IX. Three sentences to take with you

The bottleneck moved from building to sensing to intent — and it moved twice while most organizations were still optimizing for the first one.

Velocity without clarity is more expensive than slowness, because you now pay full price for the wrong thing and get a comprehensive test suite proving it works.

What compounds is context; what doesn’t scale is being heard by a human — and that is now the scarcest input in the system.

Sources: Enterprise Technology Leadership Journal, Fall 2026, IT Revolution — licensed CC BY-NC-SA 4.0. · John Cutler, TBM 441.

Two organizations can have access to essentially the same cloud platforms, AI models, engineering talent and budget — and still produce radically different outcomes.

One moves quickly. It experiments, learns, reuses what works, and steadily increases its ability to deliver value. The other adds AI tools, launches pilots and increases engineering capacity, yet decisions remain slow, platforms become more complex, and teams struggle to turn new capability into measurable business outcomes.

The difference is not the technology. It is the system the technology operates in. And as AI makes implementation dramatically cheaper, that difference stops being a nuance and starts being the whole game.

The question is no longer simply:

If we can build almost anything, what should we build?

The deeper question is:

When implementation stops being the primary constraint, what becomes scarce?

I believe the answer is intent.

Most of the individual pieces of this argument are not new. What I think is underexplored is what happens when you put them together — and what that implies for the people who build internal platforms.

Fig. 1 — Identical inputs, opposite trajectories. The difference is the system around them.

The bottleneck moves upstream

For decades we have invested in the ability to implement: better languages and IDEs, cloud, CI/CD, infrastructure as code, internal developer platforms, AI coding assistants, and now autonomous agents. Each generation removed friction from implementation. Each was worth doing.

But removing a constraint does not eliminate the need for a constraint. It moves it.

When implementation becomes abundant, organizations increasingly struggle with a different class of question:

• What outcome are we actually trying to achieve?

• Which problem is worth solving?

• What context does the person or agent making the decision need?

• Which constraints matter?

• Who has the authority to act?

• What can an agent change autonomously?

• How do we know whether the result created value?

• What should we learn and reuse?

The bottleneck has moved from “Can we build it?” toward “Do we know what should happen next?” That is a very different problem, and it does not respond to more compute.

Fig. 2 — Cheaper implementation did not remove the constraint. It moved it from build to intent.

Intent is more than a requirement

When I use the word intent, I do not mean a vague business requirement or a ticket in a backlog.

Intent is the combination of:

what outcome should be achieved, in which context, under which constraints, with which authority to act — and how we will know whether the outcome was actually achieved.

A traditional requirement might say:

“Build an API that allows customers to change their address.”

Intent asks a much richer question:

“Enable customers to maintain their address without contacting support, subject to these regulatory, security and data-quality constraints, while preserving the integrity of downstream processes.”

The first describes something to build. The second describes an outcome, a context, a boundary and a reason for action.

AI agents are exceptionally good at implementation. They are much less useful when the intent they receive is ambiguous, the context is incomplete, the constraints are unstated or the feedback loop is weak. This is why more execution capacity does not automatically translate into more business value.

One clarification, because this argument is easy to misread. Clear intent is not the same as complete upfront specification. Most product intent is discovered by building, and cheap implementation makes discovery cheaper, not less necessary. The correct response to abundant code is often more experiments, not longer documents.

What has to be clear is narrower than a specification: the outcome being pursued, the constraints that must hold, and how we will know. The solution is allowed to be unknown. “We don’t know yet, and here is the experiment that will tell us” is a perfectly well-formed intent. “Build the thing we discussed” is not.

Fig. 3 — The same request twice. The requirement names a solution; intent fills the five slots around it.

The multiplier matters more than the inputs

A useful way to think about this is:

Outcome = Inputs × Multiplier

Organizations have become very good at increasing inputs: more engineers, more cloud, more data, more models, more tools, more automation. But the multiplier determines whether those inputs compound or merely accumulate.

I use the following model to describe it:

Outcome = Inputs × (A × C × E)

Where:

• A = Adaptive Organization

• C = Compounding Foundation

• E = Evolving Flywheel

None of these are precise metrics. But each has a usable proxy:

• A — Decision latency. How many working days pass between a signal arriving and an authorized actor being able to act on it?

• C — Second-team cost. When a second team needs the same capability, what fraction of the first team’s work do they get for free?

• E — Learning half-life. How long before an operational insight exists as something reusable — a pattern, a policy, a platform capability — rather than as tribal knowledge?

Measure those three and you usually find the real constraint within an afternoon.

The relationship matters more than the precision. If one multiplier approaches zero, adding inputs does not solve the underlying problem. That is why two organizations can make near-identical technology investments and experience completely different outcomes.

Fig. 4 — Multiplied, not added. One multiplier at zero collapses the whole chain.

A — Adaptive Organization

The first multiplier is the organization’s ability to sense, decide and act.

An adaptive organization does not make every decision quickly. It makes the right decisions at the right level, with enough context and authority to act.

Consider a team that discovers a customer problem on Monday but needs three approvals, a platform review, an architecture board decision and a funding discussion before it can respond. The engineers may be excellent, the platform modern, the AI agents powerful. The system still has a long distance between signal and action — and AI shortens the implementation step without changing that distance at all.

So the questions worth asking are structural:

• How many layers sit between a signal and an empowered decision?

• How expensive is it to change direction?

• Which decisions can be delegated?

• Does the person or agent making a decision have the context required to make it well?

• Can teams act within clearly defined boundaries without waiting for central approval?

AI raises the value of organizational adaptability precisely because it raises the speed at which action is possible. Decision latency becomes both more visible and more expensive.

C — Compounding Foundation

The second multiplier is the technology foundation — and this is where Platform Engineering becomes critical.

A platform is not valuable because it provides more capabilities. It is valuable when those capabilities can be reused safely and repeatedly, so the organization stops solving the same problem twice. Good architecture compounds. Poor architecture compounds too — in the wrong direction.

This leads to a principle I keep returning to:

Architecture sets the sign of the multiplier. Tools mostly set the size.

The sign is deliberate. A bad foundation does not merely add less value than a great one — it actively subtracts, because every new capability makes the next change harder. Tools can make a positive multiplier larger. They cannot flip a negative one.

You can install a world-class data platform inside an organization that takes four months to approve a decision. The platform will be technically excellent and strategically irrelevant.

This is also why Platform Engineering should not be reduced to Developer Experience. Developer Experience matters enormously. But the deeper question is whether the platform makes the system of value creation more effective — and those are not the same question.

E — Evolving Flywheel

The third multiplier is the organization’s ability to learn.

Every technology organization runs some version of a loop:

Sense → Decide → Build → Run → Learn

The problem is that most organizations treat each iteration as independent. A team solves a problem, the solution disappears into production, and another team meets the same problem six months later. The organization learned something. It just never turned the learning into an asset.

A compounding organization converts learning into things that can be picked up again: architecture patterns, platform capabilities, automation, data, policies, operational knowledge, product knowledge, decision context. Each cycle makes the next cycle cheaper.

This becomes particularly powerful with AI, because agents can run more cycles, analyze more data, generate more options and operate continuously. But unless the organization captures what those cycles teach it, additional execution capacity produces motion rather than momentum.

Why intent stays scarce

If intent were merely an information-quality problem, it would already be solved. Write better tickets. Add acceptance criteria. Done.

It is not solved, and the reason is uncomfortable: in most large organizations, intent is ambiguous on purpose.

Vague intent is what unresolved stakeholder conflict looks like once it has been written down. Two executives want different things. The wording that survives the meeting is the wording both can live with — which means the wording that decides nothing. The ambiguity is not a drafting accident. It is the compromise.

Teams have historically absorbed that ambiguity. Someone senior interpreted it, made a call, and the organization never had to admit a decision was missing.

Agents do not absorb ambiguity. They act on it — quickly, at scale, and in whichever direction the prompt happened to lean.

This is why making intent explicit is a political act before it is a technical one. It forces deferred conflicts into the open. That is the real cost, and it is also the real value.

The agentic twist: agents amplify the system

AI agents do not fix a weak organization. They amplify the system they are placed into.

This is not a new observation. Google Cloud’s DORA research program reached the same conclusion in its 2025 State of AI-assisted Software Development report, based on nearly 5,000 technology professionals: “AI’s primary role in software development is that of an amplifier.” It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. And the report locates the returns not in the tools but in the organizational system underneath them — starting with the quality of the internal platform.

What I want to add is the structural consequence.

If your architecture is modular, agents exploit that modularity. If your platform offers reusable capabilities, agents consume them. If your feedback loops are tight, agents learn faster.

But if your architecture is tightly coupled, agents make more changes across a tightly coupled system. If your policies are unclear, agents act with unclear boundaries. If your decision processes are slow, agents produce enormous amounts of work that waits. And if your feedback loops are weak, agents accelerate the production of things nobody can tell whether they should have built.

The equation does not disappear. Agents multiply it. That makes platform and organizational architecture more important, not less.

Fig. 5 — The same agent in two systems. One compounds; the other queues more work in front of the same decision gate.

From Developer Experience to Intent

This creates a significant shift for Platform Engineering.

The traditional platform consumer is a developer. The platform helps them provision infrastructure, deploy software, access services, observe systems, manage environments and automate repetitive work.

Increasingly, a second consumer is arriving: the AI agent.

An agent does not need a nicer developer portal. It needs a machine-accessible environment in which it can safely act — and that environment has three parts.

Know — what the actor can find out:

• Context — what does the agent need to know?

• Capabilities — what can it do?

Do — what the actor may change:

• Constraints — what must it not do?

• Permissions — what is it authorized to change?

• Policies — which organizational rules apply?

Learn — how the system finds out what happened:

• Observability — what did it do, and why?

• Feedback — did the action achieve the intended outcome?

• Human escalation — when must a person decide?

So the platform question is no longer only:

How do we make it easier for developers to build?

It becomes:

How do we create an environment in which humans and agents can safely turn intent into governed action?

That is a considerably bigger platform problem.

Fig. 6 — Two consumers, one platform: what an actor can know, what it may do, and how the system learns.

Intent becomes the scarce resource

The emerging value chain looks roughly like this:

Signal → Intent → Context → Decision → Action → Outcome → Learning

AI dramatically increases capacity on the Action side. Agents write code, create infrastructure, analyze information, execute workflows, test systems and operate services.

Which makes everything upstream more consequential. If the signal is misread, the agent solves the wrong problem. If the intent is ambiguous, it builds the wrong solution. If the context is incomplete, it decides badly. If constraints are missing, it acts unsafely. If the outcome is not observable, nobody learns anything.

The more powerful the execution engine, the more valuable the quality of the instructions and the environment around it.

This is the paradox of abundant implementation:

The cheaper it becomes to build, the more expensive it becomes to be unclear about what should be built.

Fig. 7 — AI inflates the action stage. Everything upstream decides whether that capacity creates value.

The other side of the loop: verification

There is a fair objection to all of this.

If agents can produce unlimited output, the binding constraint is not intent — it is verification. Review capacity. Test coverage. The ability to trust what came back.

I think that objection is correct, and I think it is the same problem.

Intent and verification are two ends of one loop. Verification is only possible against a stated outcome: you cannot review code against a vague requirement, you can only review it against your private assumption of what it was supposed to do. Weak intent does not just produce the wrong software. It makes the wrong software undetectable.

The pair is inseparable. Intent defines what “correct” means; verification is how the organization finds out. An organization that scales execution without scaling either one is not moving faster. It is accumulating unreviewed work.

What this means for Platform Engineering

Platform Engineering has traditionally focused on reducing friction for software teams. The next evolution is broader: platforms become the place where organizational intent is translated into executable capability.

Kaspar von Grünberg and Luca Galante make the platform side of this case at full scale in Thinking in Platforms: platform engineering as the operating model for recurring knowledge work, with paths, capabilities, policy and state that let humans and agents operate reliably. I find that argument convincing.

Their book describes the production system. This post asks what sits in front of it. Where does the intent come from that the production system executes? How do scattered signals become a decision, and how does that decision become an artifact something can act on? Paths make answered questions cheap to reuse. Intent Architecture is about how the questions get answered in the first place — and who is authorized to answer them.

That does not mean turning the platform into a giant orchestration system. It means providing primitives that let autonomous actors operate inside a clearly defined system:

• reusable capabilities instead of one-off implementations

• machine-readable interfaces instead of undocumented dependencies

• policy and governance as executable constraints

• identity and authorization that work for humans and agents alike

• context that can be discovered and trusted

• observability that connects actions to outcomes

• feedback loops that turn operational experience into reusable knowledge

This is where Platform Engineering intersects with architecture, organizational design, product operating models and AI. The platform becomes part of the organization’s decision-to-action system.

A practical diagnostic

Before adding another AI tool or platform capability, run three checks.

1. Where is the constraint?

Run the three proxies against your own organization:

Healthy Worth investigating Your constraint Decision latency days weeks months Second-team cost mostly free partial reuse rebuilt from scratch Learning half-life days to a pattern a quarter never leaves the team

Whichever row is worst is where your next investment belongs — regardless of where the budget currently sits.

2. Are we creating reusable capabilities?

After an AI initiative succeeds, what does the second team get for free? If the answer is “nothing”, you are increasing execution capacity without creating compounding value.

3. Can humans and agents safely act on intent?

Can an authorized actor discover what it needs to know, what it is allowed to do, what it must not do, which capabilities it can use, how success is measured, and when it needs a human? If not, increasing autonomy mostly increases risk and rework.

The next architectural problem

Software architecture originally focused on implementation. Distributed systems forced us to think about communication, consistency and resilience. Cloud changed how infrastructure was consumed. Platform Engineering changed how teams consumed capability. Agentic AI is now changing the economics of execution itself.

That creates a new architectural question:

How do we design enterprises in which intent can reliably become governed action — through humans, agents and platforms?

The answer is not another tool. It requires architecture, organizational design, platforms, governance — and far greater clarity about intent than most organizations currently tolerate.

This is the direction I have started calling Intent Architecture: the emerging discipline of designing the enterprise so that intent can reliably become governed action through humans, agents and platforms.

This is adjacent to, but not the same as, the spec-driven development work happening in the tooling space. Spec-driven development operates at the artifact level: a specification per feature, precise enough for an agent to implement against. That is genuinely useful and largely solved in principle.

Intent Architecture asks the level above it. A perfect spec is worthless if nobody was authorized to commission it, if the constraints it inherits are undocumented, or if nothing downstream reveals whether the outcome was achieved. Specs govern a unit of work. Architecture governs who may commission work, under which constraints, and how the result feeds back. You need both — one without the other produces either well-specified irrelevance or well-governed vagueness.

The name matters less than the problem. The strategic question is what matters:

When implementation becomes abundant, which organizations will be able to turn intent into action, action into learning, and learning into better intent — faster than everyone else?

That may become one of the defining technology leadership questions of the agentic era.

Code was never the goal. Value comes from decisions.

I wrote the North Star Architecture as a five-layer model for moving organisations from Strategic Theater to a Scalable Growth Engine. A follow-up asked what changes when autonomous agents enter the picture. Short version: nothing structural. The five layers hold. Each one just serves two kinds of actor now.

Readers kept asking a better question:

If we’re splitting our platform into cloud infrastructure, an internal developer platform, and a data platform — how do the five layers map onto those three? And where does “the agentic platform” go?

Right now, a lot of large enterprises are answering that second question by standing up an agentic platform as a fourth silo, with its own team, roadmap, runtime and governance.

I think that’s a mistake, and this piece is the decomposition that shows why. Three steps: the platform as a single thing, then split into the three platform types enterprises actually build, then agentic AI added as what it really is — a cross-cutting overlay with one thin coordinating surface.

Why platforms split

Platform engineering exists to reduce cognitive load. A platform team paves roads that stream-aligned teams consume as self-service. Done well, the platform is the fastest path through all five layers.

In a small organisation, “the platform” is one team, one roadmap, one catalog. At enterprise scale that collapses. Infrastructure-as-code specialists, Kubernetes engineers, API gateway people, data platform engineers and MLOps specialists do not fit in one team’s head — and a platform team that exceeds its own cognitive load budget is just a bottleneck with better branding.

So it splits, and industry practice has converged on three:

• Cloud Infrastructure Platform — compute, storage, network, identity foundations, landing zones, observability primitives. Consumed by the other two platforms as much as by product teams.

• Internal Developer Platform — developer-facing self-service, golden-path pipelines, service catalog, API gateway, event bus, design systems, runtime templates. The paved road product teams touch daily.

• Data Platform — ingestion, storage, transformation, governance, analytics, ML-ready datasets. Usually organisationally separate, because the skills and the vendors are.

All three are platforms-as-products. All three are shaped by Team Topologies. All three exist to make product teams faster.

Step 1 — Five layers, one platform

Start with the clean case. Treat the platform as a single entity serving stream-aligned teams, and every layer falls inside platform scope:

• L5 · Speed Infrastructure — provisioning, runtimes, CI/CD, observability, secrets, networking. Self-service here is what separates a paved road from a guided tour.

• L4 · Data Platform — data on tap. Pipelines, governed datasets, analytics surfaces, feature stores.

• L3 · Integration Fabric — the connective tissue. API gateway, event bus, service mesh, identity federation, schema registry.

• L2 · Product Capability — the catalog of reusable services: authentication, workflow, analytics, domain services.

• L1 · Experience — usually underserved; in mature orgs the platform also ships the composability kit. Design systems, frontend shells, feature flags, experimentation tooling.

Clean mapping. Also unsustainable past a certain size — which is the whole reason for Step 2.

Step 2 — Five layers, three platforms

Once the platform splits, the mapping stops being one-to-one. It becomes a matrix with deliberate overlaps.

Layer Primary owner Shared with L1 · Experience IDP — L2 · Product Capability IDP Data Platform (data-heavy capabilities) L3 · Integration Fabric IDP Cloud Infra (identity, network primitives) L4 · Data Platform Data Platform — L5 · Speed Infrastructure Cloud Infra IDP (developer-facing abstractions)

Two observations do most of the work here.

Only Layer 4 maps cleanly 1:1. The Data Platform owns it almost entirely — and it also owns the data-heavy slice of Layer 2 (ML services, analytics capabilities, embedded intelligence), which is the first place the lines blur.

The IDP is the only platform that touches every layer. It dominates L1–L3 and shares L5 with Cloud Infra. Which explains something anyone who has sat in these meetings already knows: most “platform engineering” debates are not about platform engineering. They’re about what belongs in the IDP.

So: the Data Platform is the cleanest scoped, the Cloud Infra Platform is the substrate everything depends on, and the IDP is the wide, contested surface where stream-aligned teams actually live.

Step 3 — Where agentic actually lands

Now the question that started this.

Take every primitive people put inside a proposed “agentic platform” and ask which existing platform already owns that class of problem.

Cloud Infrastructure Platform gains the agent runtime: persistent execution environments for long-running autonomous tasks, sandboxed tool execution, cost and token governance at the compute boundary, safety constraints enforced as infrastructure. This is specialised compute, and Cloud Infra already owns specialised compute — serverless, containers, batch. The agent runtime is the next member of that family.

Data Platform gains vector storage and semantic retrieval, embedding pipelines, the layered memory model (working, session, long-term organisational), RAG pipelines, grounded knowledge management. These are data technologies run by data people. They land exactly where you’d expect.

Internal Developer Platform gains the agent registry, an MCP gateway as a first-class integration primitive, agent-to-agent orchestration patterns, agent observability and reasoning traces, human-in-the-loop experience components, and golden paths for agent development. All developer-facing self-service abstractions — which is the IDP’s entire job description.

Nothing is left over except one thing.

The one exception — the agent control plane

A small set of concerns cuts across all three platforms and sits cleanly inside none of them: agent identity, policy-as-code, behavioural audit, cost ceilings, reversibility gates.

That’s a thin coordinating surface. Call it the agent control plane.

Is it a fourth platform? No. It’s a shared concern — the same way IAM, observability and FinOps cut across all three platforms without being platforms themselves. It’s typically owned by an enabling team during uplift and absorbed into the three platforms’ governance models as they mature.

Naming it matters. The alternative — hand-waving that trust is “distributed across the layers” — is how you end up with agents that can invoke any capability, fan out cost unpredictably, and leave no audit trail. Making the control plane an explicit architectural object is how governance stops being a slide.

Why not a fourth platform

Three reasons, heaviest first.

Conway’s Law. Stand up an agent platform team and you will get an agent platform: its own identity model, its own observability, its own cost governance, its own integration patterns — all disconnected from everything else. That is precisely the outcome platform engineering exists to prevent. It’s also the weakest strategic message available. “AI is a separate stack” ages badly in a market where the winners are becoming AI-native rather than AI-adjacent.

Architectural cohesion. Every agentic concern decomposes into a primitive one of the three platforms already owns. A fourth platform therefore either duplicates those primitives or becomes a thin veneer over them. Pick your failure mode.

Team Topologies. The three-platform split already maps to three platform teams. Agentic uplift is textbook enabling team work: a small, time-boxed specialist group that works across the platform teams, transfers expertise, and dissolves. A permanent fourth platform team fossilises what should be a diffusion.

Worth being concrete about who does what, because this is where the model earns its keep:

• Three platform teams (Cloud Infra, IDP, Data) — own their agentic primitives permanently, offer them X-as-a-Service.

• One enabling team — owns the control plane during uplift, works in facilitating mode, and is explicitly designed to make itself unnecessary. If it still exists in two years, something went wrong.

• Complicated-subsystem team — only where genuinely deep specialism is unavoidable (a model-serving core, a domain-specific inference engine). Not a default.

• Stream-aligned teams — consume all of the above and own the use case end to end.

One addition that the agentic era forces onto the Team Topologies canon: cognitive load now includes supervising non-human actors. A stream-aligned team running six agents is holding more than the same team running none, even if the headcount is identical. If the platform doesn’t absorb that load — through guardrails, evals and defaults an agent can’t wander past — it shows up as toil in the stream teams, which is exactly what the model exists to prevent.

There is one legitimate scenario for a temporary fourth platform: the earliest exploration phase, when the three platform teams are fully loaded and an agent-focused team needs room to move. Even then, plan the sunset. The primitives migrate into Cloud Infra, Data and IDP as those teams become ready to own them. Treat the fourth platform as a staging area, not a destination.

The category’s founders are arguing the same thing

I built this argument from architecture. It’s worth noting that the people who defined the IDP category are arriving at the same place from platform evolution.

Kaspar von Grünberg and Luca Galante describe the shift from Internal Developer Platform to Agentic Development Platform — and their structural observation is the compressed version of everything above: agents interact with a platform much the way humans do, in that they need identity and paths to consume. Identity and paths. We already have infrastructure for both, which is the entire reason a fourth platform is unnecessary.

Their sequencing argument is sharper still: build agentic capability on top of a mature IDP and you inherit security, transparency and governance, because the harness already exists. Reach for agents first and platform second, and you spend the next two years retrofitting the controls you skipped.

And in Thinking in Platforms they name the discipline underneath: treating probabilistic capabilities as deterministic produces brittle expectations, while treating deterministic capabilities as if variability were fine produces operational chaos. Non-determinism at the interface, determinism in the substrate. That’s a good description of what the control plane is for.

Different starting point, same conclusion. When architecture-first and platform-evolution-first reasoning converge on one answer, that’s usually the answer.

The executive message

The North Star Architecture models how a technology estate compounds innovation over time. Platform engineering is how that model gets built at scale. Agentic AI is the most interesting thing the model has had to absorb — and it needs neither a new model nor a new platform. It needs an extension of what you already run.

So the message is not “we’re building an AI platform.”

It’s “we’re extending our platform to be AI-native — every layer, every team, every actor.”

The five layers hold. The three platforms hold. The agentic overlay makes both more powerful — and the org chart stays recognisable, which your CFO will appreciate more than any architecture diagram.

Next in this thread: why platform engineering is the multiplier in outcome = inputs × (A×C×E) — and how to say that in a sentence that funds your team.

Sources

• Kaspar von Grünberg & Luca Galante — Thinking in Platforms (2026); “The 4 levels of agentic software development,” platformengineering.org, May 2026.

• Weave Intelligence — “From IDP to ADP: Why platform engineers now build agentic development platforms,” June 2026.

• Matthew Skelton & Manuel Pais — Team Topologies: platform, enabling, complicated-subsystem and stream-aligned teams; cognitive load; interaction modes.

• Dirk Herrmann — The North Star Architecture and its agentic extension, @dirkherrma on Medium.

Two companies adopt the same technology in the same year.

Same cloud provider. Same shift to microservices. Same AI tooling — the coding assistants, the agent frameworks, the model APIs everyone is wiring up right now. Comparable talent. Comparable budgets.

Eighteen months later, one of them is shipping faster than it ever has. Each new capability makes the next one cheaper to build. AI has spread out of engineering into support, into sales, into the product itself.

The other has a drawer full of promising pilots, a cloud bill that keeps climbing, and a quiet suspicion that none of it has actually changed the pace of the business. The codebase is harder to reason about than it was two years ago. “AI” has become a word that makes the senior engineers tense up.

Same inputs. Opposite outcomes.

If you have spent any time inside technology transformations, you have seen both of these companies. You may have worked for both. The uncomfortable part is that from the outside, at the start, they looked nearly identical. Same strategy decks. Same vendor logos. Same ambition.

So what separates them?

The question underneath the architecture

Over the past months I have written three posts about what I call the North Star Architecture.

The first — From Strategic Theater to a Scalable Growth Engine — argued that architecture, not cloud adoption, determines innovation velocity, and laid out a five-layer model for building a platform where innovation compounds instead of crawling.

The second — The Five-Layer Architecture in the Age of Agentic AI — took that model into a world where the actors are no longer only human, and asked what holds and what bends when software starts initiating its own actions.

The third — The Platform Isn’t the Product. The Operating Model Is. — moved from the architecture to the people consuming it, and argued that a platform nobody adopts accelerates nothing.

Three angles. One spine.

But underneath all three, readers kept asking a version of the same question — and it is exactly the question the two companies above force into the open:

Why does the same architecture pay off for one organization and stall in another?

The five layers are identical on both whiteboards. The cloud is the same. Increasingly the AI is the same. The architecture explains what good looks like. It does not, on its own, explain why two organizations holding the same blueprint end up in different universes.

That answer lives one level down. Not in what you build — in the thing that decides whether what you build compounds.

Tools are not the lever

Here is the trap, and almost every transformation walks straight into it.

We treat the technology as the cause. “We adopted cloud.” “We’re an AI-first company now.” “We moved to Kubernetes.” Each one is framed as if the tool itself produces the result.

It doesn’t. The same tool produces wildly different results depending on what it gets multiplied by.

It helps to be almost crude about this and write it as an equation:

outcome = inputs × lever

The inputs are the things every transformation buys: cloud, microservices, AI models, agent frameworks, talent, capital. In 2026 these are essentially a commodity. Your competitor can buy the identical stack by Friday. Inputs are necessary. They are never the differentiator, because everyone has them.

The lever is what each unit of input gets multiplied by inside your organization. It is the reason the same euro of AI spend compounds in one company and evaporates in another.

The mistake nearly everyone makes is to keep optimizing the inputs — buy more tools, adopt the newer model, add the shinier framework — while leaving the lever untouched. That is why “Cloud First,” “AI First,” and “Kubernetes” so reliably underdeliver on their own. They scale the part that was never the constraint.

So what is the lever actually made of?

In every engagement, when I strip it down, it comes apart into three drivers. I call them ACE.

A · C · E

A — Adaptive Organization. The human system that senses and acts faster than the world around it changes.

C — Compounding Foundation. The technical substrate — architecture and data — that turns each cycle into a reusable asset instead of disposable work.

E — Evolving Flywheel. The motion: the loop that actually turns, and measurably improves, every time around.

Written back into the equation:

outcome = inputs × (A × C × E)

The order is deliberate. A is the container everything else runs in. C is the substrate it runs on. E is the motion the first two produce. Let me take them one at a time — and then explain why I multiply them instead of adding them, because that choice turns out to be the whole point.

A — Adaptive Organization

Org design beats the org chart — and the stack.

Most organizations are optimized for control, not adaptation. They are built on a quiet assumption inherited from a century of industrial management: that the people who decide and the people who do are different people, separated by six or seven layers of hierarchy.

Every one of those layers sits between a signal and a response. And every layer degrades the signal a little and slows the response a lot. By the time a customer truth that a frontline engineer saw on Monday reaches someone empowered to act on it, it is Thursday, it is third-hand, and it has lost the detail that made it matter.

An adaptive organization does the opposite. It pushes decisions to where the signal arrives. Coordinated autonomy — teams empowered at the edge, aligned by outcomes rather than instructions. Leadership that obsesses over the outcome and stays out of the method. Decisions made at the speed of signal, not the speed of the approval chain.

Two things make this work that are easy to dismiss as soft. Psychological safety is not a wellbeing nicety here — it is the precondition for experimentation, and experimentation is how the loop learns. A team that cannot afford to be wrong cannot learn fast. And cognitive load as a design constraint — you cannot hand a team more than it can hold and still expect it to move quickly.

I put A first because it is the ceiling on everything else. A brilliant architecture inside a six-layer approval hierarchy still moves at the speed of the hierarchy. The org is the container; nothing inside it moves faster than the container allows.

When A is weak, here is what AI does to you. It lands as faster shadow IT. Your teams generate more code, spin up more pilots, produce more divergence — and none of it reaches a decision any quicker than before. You have accelerated the doing and left the deciding exactly as slow as it was. The gap just fills up with more half-finished work.

C — Compounding Foundation

Architecture sets the sign. Tools only set the size.

This is where the architecture trilogy lives — and where one sentence does most of the work:

Architecture sets the sign of the multiplier.

A modular, platform-oriented architecture makes the multiplier positive. Capabilities become reusable. Integrations become predictable. Data accumulates value across products. Every cycle deposits something the next cycle can build on — so each new feature is easier to ship than the last, and innovation compounds.

A tightly coupled architecture makes the multiplier negative. Every change touches everything. Every integration is bespoke. Adding more tooling to that system does not speed it up — it produces breakage faster. You can lift a monolith into the cloud, and you still have a monolith, now with a larger bill.

Sitting alongside the architecture is the data foundation. In the original post I argued that AI is not something you add later — it emerges once a strong data foundation already exists. In the agentic era the inverse bites harder: agents are only as good as the data beneath them. A weak foundation does not merely limit AI. It produces agents that confidently do the wrong thing.

The rest of C is the discipline that keeps the sign positive: reuse by default, usable by any actor — human or agent — that needs it; and guardrails and governance built in rather than bolted on. This, incidentally, is where trust actually lives. Trust is not a fourth driver floating above the model. The behavioural side of it lives in A, as psychological safety; the structural side lives here in C, as governance. Naming it separately just hides where the work has to happen.

All of C reduces to a single property: a low cost of changing your mind. A good foundation makes reversing a decision cheap. A bad one makes every decision a one-way door — and an organization that cannot afford to change its mind cannot afford to learn.

When C is weak, you get the negative-multiplier company: AI poured onto a coupled codebase, accelerating toward the wall. More tooling, faster mess.

E — Evolving Flywheel

Velocity compounds. Scale only adds.

A and C are potential. E is whether anything actually turns.

Every organization runs the same loop, whether it names it or not: Sense → Decide → Build → Run → Learn, and back to Sense. The only questions that matter are how fast and how cheaply it turns — and whether each turn leaves something behind.

That last part is what makes it a flywheel rather than a hamster wheel. Every turn should deposit a reusable asset: a capability, a dataset, and now, increasingly, intelligence itself. An agent that handles support learns which knowledge holds up. An agent that manages deployments learns which patterns precede incidents. Captured properly, that learning makes the next turn cheaper. The platform stops merely accumulating capabilities and starts accumulating intelligence — and intelligence, unlike infrastructure, compounds without an obvious ceiling.

You measure the whole thing with one number: innovation velocity — how fast an idea becomes customer value.

Two properties govern how the flywheel turns. It moves at the rate humans can metabolize change, not the rate the technology theoretically allows — which is the deep reason you cannot big-bang your way to any of this. And it widens: internal first, then product, then ecosystem. A use case that only ever serves the team that built it is a cost. One that generalizes to another team, then reaches the customer, then lets partners build on it, is an asset. So design every AI use case from day one so that someone else could reuse it.

There is an agentic twist worth stating plainly. When execution becomes cheap — and AI is making execution very cheap — the bottleneck does not disappear. It moves upstream, from execution to clarity. The constraint on the flywheel stops being “can we build it” and becomes “can we decide well and fast enough to keep it fed” — which lands you right back in A and C.

When E is weak, you get the company with a thousand pilots and zero platforms. Plenty of motion. No accumulation. Every initiative starts from scratch because nothing the last one produced was ever designed to be reused.

Why I multiply instead of add

The arithmetic is not decoration. The choice between adding and multiplying is the argument.

If these three drivers were additive, a weak one would only lower the total a little. You could compensate for a rigid organization with a beautiful architecture. In practice you cannot — and multiplication is why. A near-zero driver collapses the entire product, no matter how strong the other two. A world-class data platform inside an organization that takes four months to approve a decision produces exactly one thing: a world-class data platform nobody can act on fast enough to matter.

And then there is the sign. Architecture, through C, can make the multiplier negative — and a negative multiplier is the genuinely dangerous case, because it is invisible at year one and brutal at year three. More inputs make a negative multiplier worse, faster. This is the precise mechanism by which an AI investment backfires. You did not fail to adopt AI. You successfully amplified a system that was already subtracting value.

That reframes the entire job. The work was never to maximize the multiplicands. It is to get the multiplier above one — and ideally well above one — before you pour inputs into it.

This is the engine the trilogy was missing

Step back and the three earlier posts rearrange themselves.

The architecture posts were really about C — how to make the multiplier’s sign positive and keep it there.

The agentic post was about what happens to C and E when the actors change. Agents do not alter the lever. They multiply it. Which is exactly why agentic AI is so unforgiving: it amplifies whatever your ACE already is. A high multiplier, and agents compound it. A low or negative one, and agents accelerate the damage with remarkable efficiency.

The operating-model post was really about A — meeting teams where they actually are, so the organization can adopt and adapt instead of resisting.

ACE is the connective tissue between all three. It is the answer to the question the trilogy kept provoking but never quite named: why the same five layers compound in one company and gather dust in another.

How to read your own multiplier

You do not need a maturity model for this. You need three honest questions, one per driver, and the willingness to dislike the answers.

A. How many layers sit between the person who first sees a signal and the person empowered to act on it? Where does work get redone because it was aligned too late?

C. When you change your mind about a decision made six months ago, is that cheap or catastrophic? And could an agent safely reason over your data foundation today — or would it confidently invent the parts that are missing?

E. Name your last three AI initiatives. How many produced something a second team actually reused? If the answer is zero, you have motion without a flywheel.

The point of the questions is not a score. It is to find which driver is closest to zero — because that is the one capping everything else, and in my experience it is almost never the one the budget is currently pointed at.

The North Star, one level down

The North Star Architecture told you where to go. ACE explains why some organizations get there and some don’t, holding the very same map.

The temptation, always, is to buy another input. A newer model, a bigger platform, one more framework. It feels like progress because it is visible and it is purchasable.

But you cannot buy your way across a sub-one multiplier. You can only redesign it.

So stop optimizing the multiplicands. Fix the multiplier.

That is the difference between the two companies I opened with. Not the tools.

It was never really the tools.

This is the fourth piece in the North Star series. The first three — the five-layer north star architecture, its agentic extension, and the operating model beneath it — describe what to build and who owns it. This one is about the lever that decides whether any of it compounds. A later piece will put the full picture together as a single operating system.

A while ago I wrote a blog post outlining a 5 layer architecture to move from strategic theater to a scalable growth engine. Feedback from readers and parallel work on agentic architectures triggered this adapted version of the original North Star Architecture article.

The North Star Architecture was designed for a specific world.

A world where humans initiate actions.
Where software responds to requests.
Where integrations follow contracts.
Where data is queried, not reasoned over.

That world is not disappearing.

But a new one is arriving alongside it. Or in fact, already arrived.

A world where software agents initiate actions without being asked.
Where AI reasons over data instead of querying it.
Where workflows are not orchestrated by humans — they are orchestrated by other AI systems.
Where the boundary between “tool” and “actor” dissolves entirely.

This is the age of agentic AI.

And it raises a legitimate question for anyone who has invested in platform architecture.

Does the five-layer model still hold?

The answer is yes — but not without confronting where it bends, where it breaks, and where it needs to grow.

What Makes Agentic AI Architecturally Different

Before mapping the layers, it is worth being precise about what agentic AI actually changes.

Traditional software is reactive.
A user clicks. A system responds.
The flow is synchronous, deterministic, and human-initiated.

Agentic AI is proactive and autonomous.
An agent perceives a state. It decides an action. It executes — often without human initiation.
The flow is asynchronous, probabilistic, and self-directed.

This creates four architectural tensions that the original model was not designed to absorb.

The actor problem.
The five layers were designed assuming the actor — the entity initiating requests — is a human.
Agentic systems introduce a new actor: the AI agent itself.
Agents don’t just consume the platform. They navigate it, invoke capabilities, generate new data, and trigger downstream workflows.
The architecture has to serve two fundamentally different kinds of actors simultaneously.

The orchestration problem.
Traditional integration assumes predictable, contract-based flows.
Agent A calls API B. API B returns a result. Done.
Agentic workflows don’t work that way.
An agent might invoke five capabilities in parallel, evaluate the results, spawn sub-agents, revise its plan, and retry — all without human involvement.
The integration fabric was not designed for choreography at this level of complexity.

The trust problem.
In traditional systems, trust is structural.
A service is authorized or it isn’t. An API key is valid or it isn’t.
Agents introduce probabilistic, context-dependent behavior.
The same agent, given the same task, might take different actions.
Trust can no longer be purely structural. It must be behavioral and monitored continuously.

The memory problem.
Traditional applications maintain state in databases.
Agents need a fundamentally different kind of memory — context that persists across interactions, that retrieves the right information at the right moment, and that allows the agent to reason effectively without losing coherence.
This is not what data platforms were built to provide.

With these tensions in mind, the five layers look different.

Layer 1 — Experience Layer

The interface now has two kinds of users

The Experience Layer was designed for humans.

Composable interfaces. Feature flags. Experimentation. Design systems.

All of that still matters.

But in an agentic world, the Experience Layer acquires a second class of user.

The agent.

Agents don’t use interfaces the way humans do.
They don’t click buttons. They don’t navigate menus.
They invoke capabilities, read outputs, and decide next steps — programmatically.

This means the Experience Layer must now serve two fundamentally different interaction models.

Human-facing surfaces — the apps, portals, and workflows customers and employees use.

Agent-facing surfaces — structured, machine-readable interfaces that agents can navigate without ambiguity. These include conversational interfaces that accept natural language instructions, tool manifests that describe what an agent can do and how, and action surfaces that expose human workflows as agent-invokable operations.

The implications for architecture are real.

A composable UI designed only for humans will not translate into a reliable agent interface.
An agent interface designed without human oversight capabilities will not be trustworthy.

The most forward-looking organizations are designing both from the start — not retrofitting one onto the other.

They are also introducing a new pattern into the Experience Layer:

Human-in-the-loop surfaces.

Not every agentic action should be autonomous.
Some decisions require human confirmation — an approval step, a review gate, an exception escalation.
These surfaces don’t exist in traditional experience design.
In agentic architectures, they become critical.

Layer 2 — Product Capability Layer

This is where agents live

If the Experience Layer gains a new kind of user, the Product Capability Layer gains an entirely new kind of resident.

In the original model, this layer contained domain services, workflow engines, analytics capabilities, and AI services.

In an agentic architecture, agents themselves become capabilities in this layer.

This is the most structurally significant shift in the entire model.

An agent is no longer just a consumer of the platform.
It is a published, composable, reusable capability — just like an authentication service or a reporting engine.

This has a name in agentic platform design: the agent registry.

The agent registry is the catalog of available agents — their purpose, their inputs and outputs, their trust level, their operational constraints.

Just as the product capability layer makes human-built services available to stream-aligned teams, the agent registry makes agent capabilities available to orchestrating systems, to other agents, and to human product builders.

This enables a pattern that fundamentally changes how products are built.

Agent composition.

Instead of building a workflow from API calls, a product team assembles a workflow from agents — each one specialized, each one accountable for a specific type of reasoning or action.

A research agent that retrieves and synthesizes information.
A planning agent that breaks a goal into subtasks.
A validation agent that checks outputs before they propagate.
An execution agent that takes actions in external systems.

These are not science fiction. They are the building blocks of a mature agentic Product Capability Layer.

The architectural principle from the original model still holds perfectly here:

Build capabilities once. Reuse them across products, markets, and use cases.

It now applies to agents.

Layer 3 — Integration Fabric

The nervous system needs to handle choreography, not just messaging

The Integration Fabric was built for predictable integration.

Standardized APIs. Event-driven communication. Identity federation.

Agentic workflows stress every one of these assumptions.

When an agent executes a complex task, it does not follow a predefined flow.
It plans dynamically, fans out across multiple capabilities, evaluates results, revises its approach, and propagates outcomes — often triggering further agents in the process.

This is not a request-response pattern.
It is dynamic orchestration — and the integration fabric must support it.

In practice, this means several things change.

API contracts must become richer.
Agents need to understand not just what an API does, but when to use it, what its failure modes are, and what alternatives exist if it is unavailable.
This requires a new kind of API specification — one designed for agent consumption, not just developer consumption.
The emerging standard for this is the Model Context Protocol (MCP) — an open protocol that allows agents to discover, understand, and invoke tools and services in a standardized way.
Just as REST APIs standardized how humans and systems communicate over the web, MCP is emerging as the protocol layer that standardizes how agents interact with capabilities.

Event streams must become agent-legible.
Events in traditional systems are structured for consumption by services.
Agents need to consume events too — and reason over them.
The integration fabric must enrich events with enough context that agents can make meaningful decisions from them, not just route them.

Identity must extend to agents.
Traditional identity federation handles humans and services.
In an agentic system, agents are actors too — and they must have identities, permissions, and audit trails.
An agent that can impersonate any user, or invoke any capability without restriction, is not just an architectural problem.
It is a security and compliance failure.

Orchestration must be observable.
When a human-initiated workflow fails, there is usually a clear place to look.
When an agent-initiated workflow fails — having spawned sub-agents, invoked multiple capabilities, and revised its plan three times — the failure can be deeply buried.
The integration fabric must make agent orchestration patterns as observable as traditional service calls.

The underlying principle from the original model holds:

Make integration a strength — not a bottleneck.

But in an agentic world, integration includes the ability to safely orchestrate autonomous actors at scale.

Layer 4 — Data Platform

Memory, context, and grounding become first-class architecture concerns

The original Data Platform layer was designed to transform data from a byproduct into a strategic asset.

Governed ingestion. Unified storage. Cross-product telemetry. ML-ready datasets.

All of that remains foundational.

But agentic AI introduces three new requirements that sit on top of — and interact with — everything the data platform already provides.

Vector storage and semantic retrieval.
Traditional databases answer the question: what record matches these parameters?
Agents need to answer a different question: what information is most relevant to this context?
This requires vector databases — storage systems that represent information as embeddings and retrieve it by semantic similarity rather than exact match.
Without this capability, agents cannot do meaningful retrieval-augmented reasoning.
They either hallucinate — confabulating information that isn’t there — or they ignore vast amounts of relevant knowledge that exists in the platform.

Agent memory architecture.
Agents operate across time. They may handle a task today that depends on context established weeks ago.
This requires a layered memory model:
Short-term working memory — the context an agent holds during a single task.
Session memory — context that persists across a multi-step interaction.
Long-term organizational memory — knowledge that accumulates across all agent activity and is retrievable by any agent that needs it.
The data platform is the home of long-term memory. Without it, every agent starts from scratch. With it, intelligence compounds.

Grounding and knowledge management.
Agents that reason over unverified information will eventually reason their way to the wrong answer.
The data platform must provide not just data, but grounded, governed knowledge — information that has been validated, versioned, and made reliable enough for an agent to act on.
This is a new discipline: knowledge engineering for agentic systems.
It requires rigor that most data platforms have not yet applied to their content.

The original insight from this layer becomes even more consequential in an agentic world:

AI is not something you add later.
It emerges naturally once a strong data foundation exists.

In an agentic architecture, the inverse is also true:

Agents are only as good as the data foundation beneath them.

A strong Data Platform produces capable, reliable agents.
A weak one produces agents that confidently do the wrong thing.

Layer 5 — Speed Infrastructure

A new runtime enters the picture

The Speed Infrastructure layer was about compressing time-to-market.

Elastic compute. CI/CD automation. Developer self-service. Observability tooling.

All of that still matters.

But agentic systems introduce a new class of infrastructure requirement that doesn’t exist in traditional application architectures.

The agent runtime.

An agent is not a traditional application.
It doesn’t run once and exit. It plans, acts, observes, and replans — in a loop.
It may spawn other agents. It may run for seconds or for hours.
It needs access to tools — APIs, code execution environments, browsers, databases.
And it needs to do all of this safely — without causing unintended harm in production systems.

The agent runtime is the infrastructure layer that makes this possible.

It includes:

Sandboxed tool execution environments.
Agents that can run arbitrary code need environments where that code cannot cause unintended damage.
The runtime provides isolated, constrained execution contexts.

Cost and token governance.
Agentic workflows can consume significant compute and LLM tokens — especially when agents spawn sub-agents or retry reasoning loops.
Without governance, costs become unpredictable.
The runtime must provide visibility, limits, and alerting — at the agent level, not just the infrastructure level.

Safety and constraint enforcement.
Agents must operate within defined boundaries.
What systems can they access? What actions are irreversible? What decisions require human confirmation?
These constraints cannot live in the agent’s prompt alone. They must be enforced at the runtime level — structurally, not just instructionally.

Agent observability.
Debugging a traditional application means reading logs.
Debugging an agent means understanding its reasoning — why it made a particular decision, what information it retrieved, which tool it called and with what parameters.
The observability infrastructure must capture agent reasoning traces, not just execution logs.

Latency and throughput management.
Agentic workflows have different latency profiles than traditional applications.
Some tasks are fine to run over minutes. Others — especially those in customer-facing flows — require near-real-time responses.
The infrastructure must handle both, and route appropriately.

The original principle of this layer holds perfectly:

Infrastructure should disappear into the background so teams can focus on building capabilities instead of running systems.

In an agentic world, this principle extends to the agent runtime.
Teams should be able to deploy, monitor, and govern agents without building bespoke infrastructure for each one.

Does the Architecture Need a Sixth Layer?

This is the question worth asking directly.

Some practitioners argue that agentic systems require an entirely new layer — an orchestration and trust layer that sits above everything else and governs how agents plan, act, and interact.

The argument has merit.

But the more precise answer is this:

Agentic orchestration and trust are not a new layer. They are a new concern distributed across all five existing layers — but concentrated most heavily in two of them.

The Product Capability Layer is where agents are defined, published, and composed. This is where agent governance lives architecturally — what agents exist, what they can do, how they are discovered.

The Speed Infrastructure Layer is where agents execute. This is where runtime safety, cost governance, and behavioral observability live.

The integration fabric handles agent communication. The data platform handles agent memory and grounding. The experience layer handles agent-human interaction surfaces.

What this means practically is not that you need a new layer.

It means you need to revisit every existing layer through an agentic lens — and deliberately extend each one to support autonomous actors alongside human ones.

The organizations that treat agentic AI as a feature to be added on top of their existing platform will struggle.

The organizations that treat agentic AI as a new set of actors that the entire platform must be designed to support will compound.

The Architecture Is Now a Platform for Both Humans and Agents

There is a reframe that ties all of this together.

The North Star Architecture, in its original form, was a platform for human-built software serving human users.

In the age of agentic AI, it must become something larger.

A platform for both humans and agents — where each can build, compose, and act — safely, at scale, and in ways that compound over time.

The five layers hold. But each one now serves two classes of actor.

The experience layer serves humans and agents simultaneously.
The product capability layer contains human-built services and agent capabilities.
The integration fabric handles service calls and agent orchestration.
The data platform stores records and provides agent memory and grounding.
The speed infrastructure runs applications and agent runtimes.

The architectural principle that underpins the entire model remains unchanged:

Every capability built into the platform should be usable by any actor — human or agent — that needs it.

This is what separates organizations that deploy AI features from organizations that become AI-native.

Feature deployments add AI on top.

Platform-native AI embeds agents as first-class actors throughout the architecture — composing capabilities, reasoning over data, orchestrating workflows, and surfacing insights at the speed of computation rather than the speed of human decision-making.

The Compounding Effect — Amplified

In the original model, the compounding effect was described this way.

Each new product becomes easier to build than the last.
Capabilities plug together.
Data accumulates value.
Innovation accelerates.

In an agentic architecture, this compounding effect amplifies significantly.

Because agents don’t just consume the platform.

They improve it.

An agent that handles customer support learns which knowledge base articles are most effective.
An agent that manages deployments learns which patterns correlate with production incidents.
An agent that synthesizes research learns which sources are most reliable for which question types.

Over time, this learning — if captured properly in the data platform — makes every subsequent agent better.

The platform doesn’t just accumulate capabilities.

It accumulates intelligence.

And intelligence, unlike infrastructure, compounds without limit.

The North Star — Extended

The goal of the architecture remains the same.

A platform where innovation compounds over time.

But the definition of innovation has expanded.

It is no longer just about how fast human teams can ship products.

It is about how effectively human and agent collaboration accelerates the pace at which the organization turns ideas into customer value.

The Scalable Growth Engine — in the age of agentic AI — is one where:

Humans set direction.
Agents execute, learn, and surface insight.
The platform makes both faster over time.

That is the architecture worth building toward.

Not because AI is the latest trend.

But because the organizations that build platforms capable of hosting autonomous agents alongside human teams will compound their capabilities in ways that purely human-operated platforms simply cannot match.

The five layers hold.

They just need to be built for two kinds of actor now.

Most technology organizations today have ambitious growth strategies.

They talk about AI.
They talk about platforms.
They talk about ecosystems.

Yet when it comes to execution, progress often feels painfully slow.

Features take longer to ship.
Integrations become painful.
Acquisitions slow innovation instead of accelerating it.

At that point the most common conclusion appears obvious:

“We need to move everything to the cloud.”

But cloud rarely fixes the real constraint.

Because the real constraint usually isn’t infrastructure.

It’s architecture.

The Strategy–Execution Gap

A useful way to understand this problem is through a simple leadership lens:

Growth Ambition vs. Execution Capability

Each quadrant represents a different organizational reality.

Maintenance Mode

Low ambition and limited execution capability.
Technology mainly supports existing operations.

Operational Excellence

Efficient delivery and strong execution — but focused on optimization rather than innovation.

Strategic Theater

The most common situation in technology transformations.

Bold strategy.
Ambitious roadmaps.
But underlying systems make change difficult.

Scalable Growth Engine

High ambition combined with high execution capability.

This is where technology becomes a multiplier of innovation instead of a constraint.

The challenge for many organizations is simple:

How do we move from Strategic Theater to a Scalable Growth Engine?

The answer lies in architecture.

The Hidden Constraint: Innovation Velocity

In tightly coupled systems, innovation behaves linearly.

Every change touches multiple systems.
Every integration requires custom work.
Every new capability competes for scarce engineering capacity.

Progress happens — but slowly.

Platform-oriented architectures behave differently.

Capabilities become reusable.
Integrations become predictable.
Data accumulates value across products.

Over time, each new feature or product becomes easier to build than the last.

Innovation begins to compound.

Architecture, in other words, determines the innovation velocity of the company.

The North Star Architecture

To increase innovation velocity, organizations need a clear architectural north star.

One practical way to structure this architecture is through five layers, each building on the capabilities of the layer below.

Together they create a technology foundation where innovation becomes faster, safer, and more scalable.

Layer 1 — Experience Layer

Compose and deliver customer value rapidly — without rewriting the core.

At the top sits the customer experience.

This is where products, interfaces, and workflows deliver value to users.

In modern architectures the experience layer becomes composable.

Teams can:

• expose new features rapidly

• run experiments and A/B tests

• integrate capabilities from acquisitions

• evolve experiences independently from backend systems

The key idea is simple:

Customer value should evolve faster than the underlying systems.

Layer 2 — Product Capability Layer

Build capabilities once — reuse them across products, markets, and acquisitions.

Many organizations accidentally rebuild the same functionality repeatedly.

Authentication.
Reporting.
Workflow automation.
Analytics.

Instead of embedding these capabilities inside applications, they should exist as modular business services.

Examples include:

• domain services

• workflow engines

• analytics services

• AI services

• partner capabilities

When capabilities become modular, they turn into reusable building blocks.

This dramatically accelerates innovation and reduces duplication across teams.

Layer 3 — Integration Fabric

Make integration a strength — not a bottleneck.

This layer is often underestimated but critically important.

The integration fabric connects capabilities through:

• standardized APIs

• event-driven communication

• identity federation

• partner integrations

It becomes the connective tissue of the platform.

This layer also determines whether acquisitions accelerate the company — or slow it down.

Without a strong integration backbone, every integration becomes custom work.

With one, new capabilities can plug into the platform quickly and predictably.

Layer 4 — Data Platform

Transform data from a byproduct into a strategic asset.

Most companies generate vast amounts of data but struggle to turn it into intelligence.

A modern data platform provides:

• governed data ingestion

• unified analytics-ready storage

• cross-product telemetry

• datasets ready for machine learning

The goal is not just reporting.

It is creating a data foundation where insights compound across the organization.

An important insight here:

AI is not something you add later.

AI emerges naturally once a strong data foundation exists.

Layer 5 — Speed Infrastructure

Move from managing infrastructure to accelerating innovation.

At the base of the architecture sits the infrastructure layer.

Historically this meant on-premise environments and manually managed systems.

Modern platforms rely on elastic infrastructure and managed cloud services.

The real value is not simply hosting workloads in the cloud.

The real value is compressing time-to-market.

Infrastructure should disappear into the background so teams can focus on building capabilities instead of running systems.

When These Layers Work Together

Individually, each layer solves a specific problem.

Together they create something far more powerful.

A platform where:

• capabilities can be reused across products

• integrations become predictable

• data accumulates value over time

• teams innovate without waiting for infrastructure

Technology stops being a constraint.

It becomes a compounding growth engine.

This is what moves organizations from Strategic Theater to Scalable Growth.

Internal Platforms and Ecosystems

Interestingly, the same architecture that powers internal innovation also enables something larger: ecosystems.

Many companies treat ecosystem strategy as a separate initiative.

In reality, the difference between an internal platform and an ecosystem platform is mostly one thing:

exposure.

The same capabilities internal teams consume can eventually be exposed to:

• partners

• customers

• third-party developers

Designing the architecture with this possibility in mind creates strategic optionality.

You may not need an ecosystem today.

But the architecture should never prevent one tomorrow.

The Real Goal: Increasing Innovation Velocity

Technology transformations are often framed around modernization.

New infrastructure.
New tools.
New platforms.

But the real question is simpler.

How fast can the organization turn ideas into customer value?

Architecture determines the answer.

In tightly coupled systems, innovation grows slowly because every change touches everything.

In modular platforms, innovation accelerates because capabilities, integrations, and data compound.

From Software Vendor to Platform Company

Over time, architecture begins to shape the strategic position of a company.

Organizations that master modular platforms gradually evolve from:

software vendors

to

platform companies.

Product companies build features.

Platform companies enable others to build value on top of them.

This shift creates:

• faster innovation

• stronger ecosystem effects

• higher switching costs

• scalable growth

And perhaps most importantly:

innovation stops being constrained by technology.

It becomes constrained only by ideas.

The North Star

The goal of this architecture is not modernization for its own sake.

It is creating a technology foundation where innovation compounds over time.

A foundation where:

• capabilities plug together

• data accumulates value

• integrations become routine

• new products launch faster than the last

In short:

A platform where the company can grow faster with every product, acquisition, and customer.

That is what moves organizations out of Strategic Theater and into a Scalable Growth Engine.

A practical guide to segmenting your product portfolio, tailoring your platform offerings, and using Flow Engineering to align strategy with execution.

1. Context: Cloud Adoption, Platform Engineering, and Why This Matters

Over the last decade, “move to the cloud” has become a default strategic goal for large organizations. Most companies today have a cloud-first strategy on paper, a handful of successful cloud-native products, and a growing list of migration projects. Yet when you ask executives what value they are actually getting from the cloud, the answers are often vague: “We are reducing data center footprint,” “We are improving flexibility,” “We are modernizing legacy systems.”

Those are useful directions, but they are not the full picture.

Cloud is not just a different place to run servers. Done well, it is a way to change how products are built and operated — from waterfall projects to continuous delivery, from multi-year CAPEX cycles to dynamic cost optimization, from siloed operations to shared reliability engineering. The real question is not only how do we adopt cloud? but how do we accelerate the value we get from cloud?

That is where platform engineering comes in.

Platform engineering is the discipline of building internal platforms that make it easier, safer, and faster for product teams to use cloud capabilities. Instead of each team reinventing account structures, networks, security controls, deployment pipelines, and observability stacks on their own, a platform team provides:

• A Cloud Infrastructure Platform that standardizes cloud accounts, landing zones, networking, identity, security policies, and base runtimes across the organization.

• An Internal Developer Platform (IDP) that offers higher-level workflows and golden paths for custom software: CI/CD pipelines, service templates, self-service environments, and developer portals.

If you get this right, platform engineering accelerates both sides of the equation:

Cloud adoption. Migrations become repeatable instead of one-off bespoke projects. Modernization journeys — from bare VMs to managed containers to serverless — follow documented patterns that accumulate organizational knowledge. New products can start on a paved road rather than hacking their own path through an untamed infrastructure jungle.

Cloud value. Product teams spend more time on features and less time on infrastructure scaffolding. Security incidents decrease because guardrails are consistent and centrally maintained. Compliance becomes built-in rather than bolted on. Cost optimization moves from heroic quarterly efforts to a continuous, automated capability.

However, there is a catch. In a large, product-centric organization with dozens of products at different stages of cloud adoption, not every team needs or wants the same kind of platform. Some products primarily operate commercial off-the-shelf (COTS) applications and need reliable, managed cloud operations. Others build custom software and crave a rich developer experience. Some are cloud-mature and autonomy-driven; others are early in their journey and want the simplicity of a managed service.

If you offer a single, monolithic platform to everyone, you will inevitably be too much for some products and not enough for others. You will spend significant time and budget building capabilities that large parts of your portfolio ignore, while the products that could benefit most remain underserved.

This post is about that reality. How do you design cloud operating models across a diverse product portfolio? How do you decide which products should use which model? How do you tailor your Cloud Infrastructure Platform and Internal Developer Platform to different product personas? And how do you use Flow Engineering to connect all of this into a coherent, executable platform strategy?

The answers emerged from working through exactly this kind of environment: an organization in the process of splitting a full-stack platform into a Cloud Infrastructure Platform and an Internal Developer Platform, trying to serve 30+ products with very different needs, skills, and ambitions.

2. The Core Challenge: One Enterprise, Many Products

The illusion of a single target state

When platform teams discuss their long-term vision, a familiar picture tends to emerge: every product becomes a fully autonomous, stream-aligned team that runs on a rich, multi-layer platform, focuses entirely on innovation, and never has to think about infrastructure. It is a compelling ideal, drawn from Team Topologies, the CNCF Platform Maturity Model, and a growing body of platform engineering best practice.

The problem is that this vision assumes a degree of organizational homogeneity that rarely exists in large enterprises. In reality:

• Products differ enormously in their workload composition. Some run SAP landscapes, Oracle databases, and off-the-shelf analytics software. Others build microservices, data pipelines, and custom SaaS products. The platform needs of these two groups are fundamentally different.

• Products differ in their cloud maturity and skills. One product group may have been running Kubernetes in production for three years. Another has never provisioned a cloud account and relies on a managed data center contract that is about to expire.

• Products differ in their desire to adopt a central platform. Some are eager to reduce their operational complexity and will actively contribute to the platform’s development. Others have strong in-house engineering capabilities, a healthy skepticism toward central mandates, and a strong preference for autonomy.

• Products differ in their relationship with central IT. Some see the platform team as a trusted partner. Others — often for historically valid reasons — perceive central IT as a bottleneck and view platform adoption as trading one form of constraint for another.

These differences are not edge cases. They are the rule in any organization with more than a handful of products.

What platform teams typically get wrong

The most common mistake is treating platform engineering as a technical problem rather than an operating model problem. Teams invest heavily in tooling — a Kubernetes platform, a developer portal, a CI/CD factory — and then wonder why adoption remains low. The answer is usually not that the tools are bad. It is that the operating model assumed by those tools does not match the operating model that many products actually need.

A second common mistake is what you might call the commander mindset: the belief that if you build the right platform, product teams should simply adopt it because it is centrally mandated or architecturally optimal. In practice, voluntary adoption in a diverse product organization requires something harder than technical excellence — it requires a compelling, differentiated value proposition that meets each product where it actually is. Compliance and standardization can be enforced at the foundation layer. Everything above that is earned through trust and demonstrated value.

A third mistake is confusing the existence of a platform with the acceleration of cloud value. A platform that products do not use, do not trust, or do not find relevant to their workloads is not accelerating anything. It is a cost center that generates internal friction.

3. From a Full-Stack Platform to a Layered Platform Landscape

The starting point: the monolithic full-stack platform

Many organizations arrive at platform engineering by growing a team around a set of useful shared services. Over time, what starts as a small set of reusable Terraform modules and a shared CI/CD pipeline becomes an increasingly complex full-stack offering that tries to cover everything: cloud accounts, networking, security, runtime environments, deployment pipelines, observability, service catalogs, and developer tooling.

This kind of platform is not wrong — it often represents genuine organizational progress. But it creates several structural problems:

Blurry boundaries. When a single team owns everything from IAM policies to application deployment templates, it becomes unclear who is responsible for what. Product teams do not know where the platform ends and their own responsibility begins. The platform team gets pulled into firefighting at every layer.

Wrong abstractions for many products. A product running SAP on VMs does not need golden path templates for container deployments. A product building microservices does not need the platform team to manage their application runtime. A single full-stack platform inevitably over-serves some products and under-serves others.

A single bottleneck for all problems. When one team owns the full stack, every request — from a new landing zone for a migration to a new CI/CD template for a greenfield product — competes for the same capacity. Roadmap prioritization becomes a political exercise, and products with very different needs fight for the same team’s attention.

The separation: Cloud Infrastructure Platform and Internal Developer Platform

The natural response to this complexity is a deliberate split into two distinct platform layers, each with its own team, ownership, and product focus.

The Cloud Infrastructure Platform covers the foundational layer that every cloud workload needs, regardless of its type or maturity:

• Cloud account structure and landing zones

• Networking, connectivity, and DNS

• Identity and access management (IAM)

• Security policies, guardrails, and compliance automation

• Cost management and FinOps tooling

• Base compute runtimes (VMs, container orchestration, managed databases)

• Shared observability infrastructure

The Cloud Infrastructure Platform is opinionated about security, compliance, and cost. It is not opinionated about how products build their software. Its primary value proposition is removing undifferentiated heavy lifting at the infrastructure level — so that no product team has to re-solve account structure, VPC design, or security baseline policies on their own.

The Internal Developer Platform (IDP) sits above the Cloud Infrastructure Platform and focuses on the workflow layer for custom software development:

• CI/CD pipelines and deployment automation

• Service templates and golden paths for common application patterns

• A developer portal and self-service catalog

• Application-level observability integration

• IaC modules and scaffolding for product teams

• Inner source contribution mechanisms

The IDP is opinionated about developer workflows. Its primary value proposition is accelerating the pace at which product teams can deliver and operate custom software by reducing the cognitive load of cloud-native development.

This separation matters enormously for what follows. The Cloud Infrastructure Platform is a universal foundation — every product that migrates to the cloud needs it. The IDP is a targeted accelerator — primarily valuable for products that build custom software and are ready to adopt a platform-centric development model.

Getting this separation wrong is costly. Organizations that bundle everything into the IDP end up with a platform that is irrelevant to a large portion of their product portfolio. Organizations that invest only in the Cloud Infrastructure Platform miss the opportunity to dramatically accelerate product development for their most capable teams.

4. The Cloud Operating Model Spectrum

Defining a platform strategy for a diverse product portfolio requires a shared vocabulary. One of the most useful tools is a structured spectrum of cloud operating models — archetypal patterns for how responsibility is split between the platform team and each product.

This spectrum is defined by two fundamental questions:

• How much does the platform own?
  From nothing (products are on their own) to everything (products only write code).

• How much does each product own?
  From everything (full autonomy on raw cloud) to almost nothing (pure consumption of managed services).

Five archetypal models emerge along this spectrum.

Model A — Cloud-Native DIY

Products operate directly on the cloud provider, making their own decisions about every layer: accounts, networking, security, compute, CI/CD, and everything else. There is no meaningful central platform.

This model preserves maximum autonomy and works well for large, technically mature product teams with deep cloud expertise. It is, however, the direct equivalent of the old on-premise operating model — just in a different location. For the majority of product teams in a large enterprise, this model means reinventing the same infrastructure foundation over and over, accumulating inconsistent security practices, and creating significant organizational risk.

Model B — Managed Landing Zone

The Cloud Infrastructure Platform provides the foundational layer: cloud accounts, landing zones, networking baselines, IAM structures, and security guardrails. Products operate within this foundation and are responsible for everything above it.

This is the most common first step in an enterprise platform strategy. It eliminates the most duplicated infrastructure work and establishes a consistent security and compliance baseline. However, product teams still carry a significant cognitive load — they must manage their own compute, CI/CD, observability, and everything else above the foundation layer.

Model C — Cloud Infrastructure Platform with Product Platform Teams

The Cloud Infrastructure Platform handles the foundation layer. Products with sufficient engineering capacity build their own thin platform on top — a small, focused internal platform for their specific product domain. This federated model gives technically advanced products the autonomy to make their own architectural choices while still benefiting from a shared, secure foundation.

This model suits organizations where some product groups have genuine platform engineering ambitions and the capacity to execute them. It requires very clear interface contracts between the Cloud Infrastructure Platform and the product-level platforms, but it scales well for autonomous, high-capability teams.

Model D — Layered Platform

The Cloud Infrastructure Platform and the Internal Developer Platform together provide a multi-layer offering. Products consume opinionated workflows, golden paths, and higher-level abstractions without needing to manage the underlying infrastructure or build their own tooling. Their responsibility is largely limited to application code and configuration.

This model represents the sweet spot for the majority of product teams in a well-designed enterprise platform strategy. It dramatically reduces cognitive load, accelerates migration and development, and enables standardization without sacrificing meaningful product-level control. It requires significant platform team investment to build and maintain both layers, and it requires product teams to trust the platform — which must be earned through reliability, developer experience, and responsiveness.

Model E — Full Managed Platform

The platform team manages the entire stack end-to-end. Product teams focus exclusively on writing application code. All infrastructure, runtime, deployment, observability, and operations concerns are abstracted away.

This model maximizes simplicity for product teams and enables the fastest possible onboarding for new workloads. It is the aspirational endpoint of the platform engineering journey and the ideal model for small product groups without dedicated infrastructure capacity. However, it requires an exceptionally mature and high-capacity platform team, and it carries the highest risk of the platform becoming a bottleneck and a single point of failure for the entire portfolio.

Key trade-offs across the spectrum

No single model dominates on every dimension. The table below captures the key trade-offs:

The direction is consistent: moving from left to right trades product autonomy and required skills for standardization, speed, and reduced cognitive load. Every step rightward requires more platform investment and more trust between product teams and the platform.

Why Model D Often Wins the Vote — and Why That’s Not the Full Story

When platform teams present this spectrum to product stakeholders, Model D — the Layered Platform — almost invariably wins the most votes. It is easy to understand why. Model D sounds like the best of both worlds: meaningful abstraction without total loss of control, strong central capabilities without total dependence on the platform team. It matches the narrative of CNCF’s platform maturity model, Team Topologies’ stream-aligned team ideal, and most of the influential writing on platform engineering.

But there is a critical gap between “Model D is the ideal we aspire to” and “Model D is the right model for our product portfolio today.”

A full-stack Internal Developer Platform is primarily valuable for products that build custom software, have development teams capable of adopting new workflows, and are motivated to invest in the onboarding process. For these products, the IDP is a genuine accelerator.

But a product group running SAP, Oracle ERP, or a major COTS analytics suite does not need a developer portal or CI/CD golden paths. What they need is reliable managed operations for their packaged software — backup automation, patch management, monitoring, lifecycle support. Giving them an IDP is not just unnecessary; it actively confuses the value proposition and reduces trust.

Similarly, a product group with a large, mature engineering team and a strong autonomy preference may be technically capable of adopting the full IDP — but they do not want to. They will view mandatory platform adoption as a constraint rather than an enabler, and they are likely to build shadow solutions if pushed too hard.

The key insight is this: Model D is a good target for many products, but not for all products. A successful enterprise platform strategy does not pick a single model and force it on a heterogeneous portfolio. It defines a portfolio of operating models and provides tailored platform offerings that meet each type of product where it actually is.

5. The Product Team Adoption Lifecycle: Three Phases

It’s important to distinguish between different adoption lifecycle phases for each internal customer persona, depending on where those are in their journey of cloud or platform adoption. The following framework helps to break the adoption lifecycle into three main phases:

Phase 1 — MOVE — “Get onto the platform safely”

This is the migration and modernization phase: the product team is in transit. Their primary challenge is not yet getting value from the platform — it’s completing the journey without breaking things.

What they care about:

• Getting workloads onto cloud and/or onto the platform without disruption.

• Understanding what the platform can and cannot do.

• Having a safe landing: a stable baseline environment, clear responsibility boundaries, and help when things go wrong.

• Transforming their workloads (Rehost → Replatform → Refactor) while keeping the business running.

What the platform must provide:

• A reliable on-ramp: landing zones, account setup, migration playbooks.

• Guardrails, not walls — enough safety without blocking progress.

• Hands-on enablement and migration support.

• Clear handover moments: “You’re now live on the platform.”

The platform’s job here is to be a soft landing pad, not a feature showcase.

Phase 2 — LAND — “Operate and stabilize on the platform”

This is the phase you intuitively described as “the platform as a soft landing on cloud.” The product team has arrived. Their workloads are running on the platform. Now the question becomes: can they operate, maintain, and sustain what they’ve built?

What they care about:

• Stability, reliability, and predictability.

• Operational confidence: monitoring, incident response, patching, cost visibility.

• Understanding what good looks like on the platform.

• Beginning to feel the first tangible benefits: less toil, faster change, safer deployments.

What the platform must provide:

• Managed runtime and operations support (especially for Q1 and Q3).

• Observability and cost management as first-class offerings.

• Self-service for common operational tasks (so the platform team doesn’t become the bottleneck).

• Early proof points: “Here’s what you gained by being on the platform.”

The platform’s job here is to deliver on the promise made during Phase 1.

Phase 3 — EVOLVE — “Extract and grow cloud and platform value”

This is the long-term phase. The product team is stable on the platform. Now they shift focus from “getting it to work” to “getting more out of it.” This is where cloud and platform value compounds.

What they care about:

• Cost optimization: FinOps, rightsizing, reserved capacity.

• Security posture evolution: not just compliant, but progressively more secure.

• Organizational evolution: moving toward stream-aligned teams and reducing platform dependencies through better self-service.

• Innovation: using managed AI/ML services, event-driven architectures, advanced data platform capabilities.

• Contributing back: Inner Source, sharing patterns with other product teams.

What the platform must provide:

• Continuous product evolution — the platform must keep improving or teams outgrow it.

• FinOps tooling and cost transparency.

• Advanced developer experience and productivity metrics (DORA metrics, developer satisfaction).

• Community and contribution model: teams co-evolve the platform.

• Enablement for organizational evolution (Team Topologies patterns: enabling teams, reduced cognitive load, shifting team interaction modes).

The platform’s job here is to be a long-term growth engine, not a migration tool.

Crossing the Chasm Mapping

While “Crossing the Chasm” was written in the context of external, end customer products, the same principles apply to platform, if you treat those as products you’re selling to internal product teams. The following diagram maps those 3 adoption phases to different internal customer persona types and shows where Geoffrey Moore’s Chasm applies.

6. Segmenting Products: A 2×2 Matrix

To move from a single monolithic operating model to a portfolio of models, you need a practical way to segment your products. The segmentation should be simple enough to apply to 30+ products quickly, but rich enough to yield meaningfully different platform strategies.

Two dimensions turn out to be particularly powerful.

Dimension 1: Workload profile

This dimension asks: what is the dominant type of workload this product operates?

At one end are COTS-dominant products — product groups where 70% or more of the workload consists of commercial off-the-shelf software, packaged applications, or vendor-managed solutions. Think ERP systems, HR platforms, COTS analytics suites, and similar applications. These products rarely need a developer platform. What they need is reliable, standardized cloud operations: managed runtimes, automated backup and patching, lifecycle tooling, and monitoring.

At the other end are custom-dominant products — product groups where the majority of workloads are custom-built software, microservices, data pipelines, or heavily customized solutions with active development teams. These products are the natural audience for an Internal Developer Platform.

Many products sit somewhere in between. The dimension asks for the dominant profile, not a binary classification.

Dimension 2: Platform maturity and desire

This dimension asks: how ready and willing is this product to adopt a platform model?

At the low end are products that are early in their cloud journey, lack cloud-native skills, or are skeptical of central platforms. They may have had bad experiences with central IT in the past, or they may simply not yet understand the value proposition. They require a very different engagement strategy than products at the high end.

At the high end are products with meaningful cloud experience, a clear understanding of what a platform can do for them, and an active desire to adopt a platform model. They are ready to invest in onboarding, willing to trade some autonomy for platform-level capabilities, and potentially interested in contributing to the platform as inner source collaborators.

This dimension is a compound of several factors that you can assess through surveys and interviews:

• Cloud adoption maturity and existing cloud skills

• Understanding of and attitude toward platform engineering concepts

• Autonomy preference (high autonomy preference correlates with lower platform desire)

• Past experience with central IT (positive correlates with higher platform desire)

• Urgency of migration and modernization needs

The 2×2 matrix: four product personas

Combining these two dimensions yields a 2×2 matrix with four quadrants, each representing a distinct product persona with meaningfully different platform needs.

How to score a product into the matrix

You can position products on the matrix by scoring them on six to eight short survey questions, covering:

1. Custom development intensity — How much custom software does this product develop and maintain?

2. COTS dependency — What percentage of workloads are packaged, vendor-managed, or off-the-shelf?

3. Cloud maturity — How experienced is this product with cloud services and cloud-native practices?

4. Platform desire — How strongly does this product want to adopt central platform services?

5. Autonomy preference — How important is it for this product to make independent infrastructure decisions?

6. Migration urgency — How much pressure is there to migrate from the existing data center?

7. Innovation ambition — How important is technology innovation as a competitive differentiator for this product?

Score each dimension on a one-to-five scale, then derive X and Y coordinates: the workload profile axis from dimensions 1 and 2, and the platform desire axis from dimensions 3, 4, and 5 (with autonomy preference inversely weighted). The result is a visual map of your entire product portfolio — a foundation for product-specific platform engagement strategies.

7. Tailoring Platform Offerings to Each Product Persona

The segmentation matrix is only useful if it drives differentiated action. Here is what each quadrant means for your platform team’s offering, engagement model, and value proposition.

Q1 — Operate & Stabilize: The COTS Operators

Profile. These products primarily operate COTS or vendor-managed software. They have small IT teams, limited cloud skills, and low interest in managing infrastructure themselves. Their typical motivation for cloud migration is data center contract expiry or cost reduction rather than innovation. They are not asking for a developer platform — they want someone to take the infrastructure problem off their hands.

Platform needs. The Cloud Infrastructure Platform is essential — these products need a secure, compliant foundation. Above that, they need a managed cloud operations offering: managed runtime environments, automated backup and patching, COTS-specific lifecycle management tooling, monitoring and alerting preconfigured for their application types, and clear SLAs. The Internal Developer Platform is largely irrelevant to them.

Migration strategy. Rehost (lift and shift) as the default, with selective replatforming to managed cloud services (for databases, for example) where the operational benefits are clear and the migration risk is manageable.

Engagement model. Guided migration with a defined handover to a managed service. Ticket-based support with SLA commitments. Quarterly reviews rather than continuous co-creation.

Value proposition. “We operate your packaged software reliably in the cloud — you focus on business outcomes, not infrastructure management.”

Q2 — Lift & Optimize: The Cloud Skeptics

Profile. These products build custom software with their own engineering teams and have a strong preference for autonomy. They may be technically capable — perhaps more so than the platform team in their specific domain — but they are skeptical of centralized platforms. They have their own CI/CD pipelines, their own Terraform modules, their own monitoring setup. They see a central platform as a constraint, not an enabler.

Platform needs. This group needs the Cloud Infrastructure Platform for the foundational layer — and that is often where it stops. Enforce security guardrails at the account and network level. Offer a well-documented, self-service landing zone. Provide office hours and documentation. Do not try to force the Internal Developer Platform on them.

Migration strategy. Products in this quadrant will typically run their own migration programs on top of the Cloud Infrastructure Platform foundation. Support them with clear documentation, runbooks, and optional enablement sessions — but let them own the execution.

Engagement model. Minimal friction. Self-service, documentation-first, optional enablement. The goal is not deep engagement today — it is keeping the door open and letting demonstrated platform value (visible in Q4 products) gradually shift their perception over time.

Value proposition. “We provide a secure, compliant cloud foundation. What you build on top is your decision.”

Strategic note. Do not try to win this quadrant by force. The path to converting Cloud Skeptics is through visible, undeniable success stories from Q4 products. When they see that the IDP genuinely accelerates development velocity, some will become willing adopters. The goal is to create the conditions for a natural pull, not to manufacture artificial demand.

Q3 — Enable & Empower: The Platform-Ready COTS Products

Profile. These products share the COTS-heavy workload profile of Q1, but they have higher cloud maturity and a genuine desire to leverage a platform. They understand the value of standardization and automation, and they are actively looking for ways to reduce their operational burden. They are often willing inner source contributors — they may not build custom applications, but they have operational knowledge worth sharing.

Platform needs. These products benefit enormously from the Cloud Infrastructure Platform combined with a rich COTS operations automation offering: automated lifecycle management for their vendor software, patch orchestration, backup and recovery automation, cost management dashboards, and unified observability. They may also benefit from limited IDP capabilities where they have custom integrations or lightweight automation built around their COTS systems.

Migration strategy. Rehost initially, transitioning to replatforming where managed cloud services can replace self-managed COTS components (for example, migrating a self-managed database to a cloud-managed equivalent).

Engagement model. Guided migration plus ongoing collaboration. Community of Practice membership. Advisory board participation — these products are excellent candidates for co-designing the COTS operations offering.

Value proposition. “We automate your COTS operations — less time on patching and maintenance, more time on the business outcomes your software delivers.”

Q4 — Accelerate & Innovate: The Full Platform Adopters

Profile. These are your lighthouse products. They build substantial custom software, have experienced engineering teams, are either cloud-mature or actively growing their cloud capabilities, and are genuinely motivated to adopt a platform model. They understand the value of golden paths and developer portals, they want self-service environments, and they are likely to become active inner source contributors who improve the platform for everyone.

Platform needs. The full stack: Cloud Infrastructure Platform foundation, complete Internal Developer Platform offering — CI/CD golden paths, container platform, developer portal and self-service catalog, IaC scaffolding, application-level observability, and inner source contribution mechanisms.

Migration strategy. Replatform and refactor. These products should move to cloud-native architectures — containers, managed services, event-driven patterns — rather than simply re-hosting.

Engagement model. Deep co-design. These products should be involved in shaping the IDP roadmap from the start. Use them as design partners for new capabilities, showcase their successes internally, and build inner source mechanisms that let them contribute IDP features back to the platform.

Value proposition. “We accelerate your product delivery by removing infrastructure complexity — so your engineers spend their time on business innovation, not platform maintenance.”

8. Connecting Product Segmentation to the Platform Roadmap

With the 2×2 matrix in place, the critical question becomes: in what order should you build what?

The Cloud Infrastructure Platform is your universal foundation

Every quadrant needs it. Q1 needs it as the base for managed COTS operations. Q2 needs it as the starting point for their own cloud journey. Q3 needs it as the foundation for operations automation. Q4 needs it as the substrate for the full IDP.

This means the Cloud Infrastructure Platform must be your first, highest-priority investment — and it must be designed to serve all four personas simultaneously. Its value proposition varies slightly by quadrant (guardrails for Q2, managed services foundation for Q1/Q3, golden path substrate for Q4), but the underlying capabilities are shared.

The Internal Developer Platform is a targeted investment

The IDP primarily serves Q4 products and partially Q3. It is largely irrelevant to Q1 and actively unwanted by Q2. This has important implications:

• Do not build IDP features before you have a clear, committed Q4 audience.

• Do not measure IDP success by adoption across the full product portfolio — measure it by depth of adoption and acceleration within Q4.

• Avoid the temptation to generalize IDP capabilities to cover Q1 and Q3 COTS use cases — that leads to a bloated, unfocused platform that serves nobody well.

A phased roadmap

Given the above, a well-structured platform roadmap for a diverse product portfolio tends to follow four phases:

Phase 1: Universal foundation (months 1–6).
Establish the Cloud Infrastructure Platform with landing zones, account factory, networking, IAM, security guardrails, and cost controls. This serves all four quadrants and immediately creates value for the first migration waves.

Phase 2: COTS operations automation (months 3–9).
Build managed runtime and COTS operations capabilities on top of the Cloud Infrastructure Platform. This is high-impact for Q1 and Q3, which together may represent the majority of your product portfolio by count. Backup automation, patch orchestration, and COTS monitoring are practical, high-value capabilities that can be delivered incrementally.

Phase 3: Internal Developer Platform for Q4 (months 4–12).
Build out the IDP with lighthouse Q4 products as design partners. CI/CD golden paths, container platform, developer portal, and self-service environments. Use Q4 products as living proof points. Start demonstrating measurable improvements — deployment frequency, lead time, change failure rate.

Phase 4: Inner source and scale (from month 9).
Open the platform for contributions. Introduce Community of Practice mechanisms. Encourage Q3 products to contribute COTS automation patterns. Allow Q4 products to submit and maintain golden path templates. Begin scaling from lighthouse products to the broader Q3 and Q4 population.

This phasing ensures that early investment creates immediate value across the full portfolio, and that the IDP is built with real demand rather than anticipated demand.

9. Using Flow Engineering to Design the Platform Strategy

Platform strategy is not just a technical blueprint

One of the most persistent failure modes in platform engineering is designing a platform that is technically well-architected but strategically misaligned. The team builds excellent infrastructure but serves the wrong outcomes. They deliver capabilities that product teams find irrelevant. They sequence investments in ways that create value for the platform team but not for the organization.

This happens because platform strategy is typically designed bottom-up — start with the technology, then work outward. What you actually need is a way to work from desired outcomes inward to platform capabilities, then outward to sequenced execution. This is precisely what Flow Engineering, as described by Steve Pereira and Andrew Davis, is designed to enable.

Flow Engineering is a practice for improving the flow of work, information, and decisions across organizations through value streams. At its core, it is a set of five visual maps that help teams move from confusion to clarity — from a fragmented understanding of the current state to a shared, executable path toward a better future. In the context of platform strategy, these maps are not just facilitation tools. They are a way of thinking about the problem.

The five maps in a platform strategy context

Map 1: The Outcome Map.
The Outcome Map asks the most fundamental question: what are we actually trying to achieve? In a platform engineering context, this means making explicit the outcomes that the Cloud Infrastructure Platform and the Internal Developer Platform are supposed to deliver — and being specific enough that you can tell whether you have achieved them.

Outcomes like “improve cloud adoption” or “reduce operational complexity” are starting points, but they are not sufficient. An Outcome Map for a platform strategy should define specific, time-bound targets: an adoption rate across the product portfolio, a reduction in time-to-onboard a new cloud environment, a measurable decrease in security incidents, a target migration velocity. It should also capture the benefits from three distinct perspectives — the product teams as customers of the platform, the organization as the entity investing in platform engineering, and the platform team as contributors. And critically, it should surface the known unknowns: the open questions that must be answered before meaningful progress can be made. In the context of 30+ products with heterogeneous needs, known unknowns include questions like: Which quadrant does each product sit in? What is a realistic adoption target? What does each product persona actually consider valuable?

The Outcome Map prevents the platform team from building for their own architectural preferences rather than for real product outcomes.

Map 2: The Current State Value Stream Map.
The Value Stream Map makes visible how work actually flows today — not how it is supposed to flow, but how it really flows. For platform strategy, this means mapping the current experience of representative product teams: what does it actually take to provision a new cloud environment? How long does it take to get from a request to a running application? Where are the waiting times, the handoffs, the rework loops?

Critically, this map will look very different for each of the four product personas. A Q1 COTS product team navigates a completely different value stream than a Q4 custom software team. Making these current states visible — with real timing data, real bottleneck identification, and real frustrations surfaced — is what creates shared urgency and alignment across product teams and platform teams. It also grounds the platform strategy in actual experience rather than assumed pain points.

Map 3: The Dependency Map.
The Dependency Map reveals the organizational and technical dependencies that constrain flow. For platform teams in large enterprises, these dependencies are often the invisible architecture — the network of relationships, approvals, handoffs, and constraints that nobody has ever drawn on a single page.

In a multi-product cloud migration context, the Dependency Map shows why different products end up in different quadrants of the segmentation matrix. A product that appears technically ready for Q4 may be trapped in Q2 behavior because of a dependency on a central networking team that has a six-week provisioning queue. A COTS product that appears to be in Q1 may be far closer to Q3 readiness than anyone realized, because it has a hidden dependency on a modernization program that is already underway.

Making these dependencies explicit has two immediate benefits: it identifies which platform investments will have the highest leverage in unblocking multiple products simultaneously, and it surfaces the organizational changes (in team structures, governance processes, and decision rights) that are just as important as technical platform capabilities.

Map 4: The Future State Value Stream Map.
Where the current state map shows what is, the future state map designs what should be. For each product persona, the future state map describes the target experience: what does it look like when a Q1 COTS product onboards to the managed operations offering? What does the deployment flow look like for a Q4 product using IDP golden paths? How does a Q3 product contribute a COTS automation pattern through inner source?

This map is where the operating model spectrum becomes concrete. Model D or Model E are abstract frameworks. The future state value stream map translates them into specific, tangible experiences for specific product personas — with measurable timing targets and clearly defined platform capabilities that enable them. It connects the persona segmentation directly to the platform product backlog.

Map 5: The Flow Roadmap.
The Flow Roadmap turns everything above into a sequenced plan for evolving the platform. It answers the question: given our current state, our dependencies, and our future state ambitions for each persona, in what order do we build what?

This is where the phased roadmap described in Section 8 gets its foundation. The flow roadmap is not a Gantt chart of platform features — it is a sequence of flow improvements, each one reducing a specific bottleneck for a specific product persona, each one measurable against the outcomes defined in the Outcome Map. Phase 1 (Cloud Infrastructure Platform foundation) addresses the dependency map’s most universal bottlenecks. Phase 2 (COTS operations) addresses the Q1 and Q3 current state pain points. Phases 3 and 4 deliver the Q4 future state and scale it.

How the five maps complete the picture

The product segmentation matrix tells you who needs what. The operating model spectrum tells you how responsibility should be distributed. The Flow Engineering maps tell you why those choices matter, where the real friction and opportunity are, and what to sequence in your roadmap.

Together, they form a coherent methodology for platform strategy that starts with human outcomes, moves through organizational reality, and arrives at an executable plan — rather than starting with technology choices and hoping outcomes follow.

10. From Model to Action: Practical Next Steps

The framework in this article is designed to be actionable without requiring a multi-month consulting engagement. Here is how to start putting it to work.

Run a lightweight product assessment. Design a short survey — no more than two or three pages, eight to ten questions — based on the two segmentation dimensions. Send it to IT leads across your product portfolio. Follow up with fifteen-to-thirty minute interviews for the ten to fifteen most strategically significant products. You do not need perfect data — you need enough signal to make defensible initial placements on the matrix.

Visualize the portfolio. Place products on the 2×2 matrix. Use bubble size to indicate workload volume, migration urgency, or strategic importance. Look for clusters: which quadrant is most densely populated? Where are the largest, most strategically important products? Are there products that are clearly misaligned with the current platform offering?

Identify lighthouse products in Q4. These are your most important design partners and early adopters. Work with them first, co-design the IDP offering with them, and make their successes visible across the organization. Their results are your most powerful adoption tool for the rest of the portfolio.

Co-design the COTS operations offering with Q3 products. Do not build this in isolation. Q3 products know exactly what they need — involve two or three of them as design partners in defining the COTS operations automation capabilities. This creates co-ownership, increases adoption, and produces a better product.

Use Flow Engineering maps for alignment. Even if you do not run the full mapping workshop, start with an Outcome Map. Get your platform team and key product stakeholders in a room (or a shared Miro board) and answer: what are we trying to achieve, who benefits and how, what is blocking us, what do we not know yet, and what are our next three concrete steps? This single session will surface misalignments and clarify priorities faster than any roadmap review or architectural discussion.

Establish a lightweight Advisory Board. Invite one or two representatives from each quadrant to a quarterly platform review. Give them visibility into the roadmap, give them a formal channel to provide feedback, and give them a mechanism to co-steer the direction. Products that feel heard and respected are far more likely to become willing adopters and contributors.

11. Conclusion

Platform engineering is one of the most powerful levers available for accelerating both cloud adoption and cloud value in large organizations. But its power is only realized when the platform is designed for the actual diversity of the product portfolio it serves — not for a homogeneous ideal that most products do not match.

The framework presented in this article offers a practical way to navigate that diversity:

• Separate the Cloud Infrastructure Platform from the Internal Developer Platform so that foundational capabilities and developer experience capabilities can evolve at different speeds, for different audiences, with different value propositions.

• Define a cloud operating model spectrum (Models A through E) so that stakeholders share a vocabulary for how responsibility is distributed — and so that the conversation is about operating models rather than just tools.

• Apply a 2×2 product segmentation matrix to understand where each product actually sits: COTS-dominant or custom-dominant, low or high platform desire. Let that segmentation drive genuinely tailored platform offerings for four distinct product personas.

• Use Flow Engineering maps to connect outcomes to current reality to future state to a sequenced roadmap — ensuring that the platform strategy is grounded in real product experiences and driven by real outcomes, not by platform team preferences.

The underlying principle is deceptively simple: meet products where they are, not where you wish they were. A Q1 COTS product that gets a managed operations offering it actually needs will generate more platform trust, more adoption, and more organizational momentum than a dozen half-hearted deployments of an IDP that nobody asked for.

Build from outcomes. Segment with honesty. Tailor with purpose. And let demonstrated value — not mandates — drive adoption.

Have thoughts on operating model design for platform engineering? I’d love to hear how your organization has approached the challenge of serving a diverse product portfolio.

In today’s data-driven business landscape, organizations are drowning in information yet starving for actionable insights. Despite having access to more customer data, employee feedback, and stakeholder input than ever before, most companies struggle with a fundamental problem: they lack sufficient feedback loops to drive meaningful decisions across their organizations. This feedback crisis is particularly acute in technology organizations where platform engineering teams serve as the crucial bridge between technical capabilities and business outcomes.

The Critical Importance of Feedback in Organizational Decision-Making

Feedback serves as the nervous system of any organization, transmitting vital information that enables adaptive responses to changing conditions. Research consistently demonstrates that organizations implementing effective feedback loops are 2.5 times more likely to retain customers and see a 14% increase in employee engagement compared to those that don’t prioritize systematic feedback collection and action.

The power of feedback lies in its ability to transform assumptions into empirical observations. When organizations make decisions based on hypotheses rather than validated insights, they operate blindly in an increasingly complex market environment. Feedback loops provide the critical mechanism for grounding decision-making in real data rather than assumptions, enabling leaders to understand their true impact on customers, employees, and business outcomes.

The Multi-Dimensional Value of Feedback

Effective feedback systems create value across multiple organizational dimensions simultaneously. For customers, feedback-driven improvements result in better product quality, faster feature delivery, and more reliable experiences. When platform engineering teams receive direct customer feedback about product performance issues, they can prioritize infrastructure improvements that directly impact user satisfaction.

For organizations, comprehensive feedback systems provide clear demonstration of return on investment, reduce costs through elimination of redundant systems, and accelerate time-to-market for new features. Most importantly, they create a competitive advantage through data-driven decision making that competitors without similar systems cannot match.

For individual contributors, particularly developers using Internal Developer Platforms (IDPs), feedback loops enhance productivity and job satisfaction by reducing cognitive load through better platform abstractions and creating clear connections between their technical work and business outcomes. When developers can see how their platform improvements translate into faster feature delivery and improved customer satisfaction, their engagement and motivation increase significantly.

The Pervasive Feedback Gap: Why Most Organizations Fall Short

Despite the clear value proposition, 70% of feedback management systems fail to deliver tangible results. This staggering failure rate reflects systemic challenges that go far beyond simple tool selection or process design. Understanding these challenges is crucial for any organization seeking to establish effective feedback loops.

Common Pitfalls That Undermine Feedback Effectiveness

The Relevance Gap represents one of the most fundamental failures in organizational feedback systems. Generic templates and one-size-fits-all approaches produce generic insights that don’t reflect organizational context, values, or success metrics. When feedback collection methods aren’t tailored to specific personas and their unique needs, the resulting data lacks the specificity required for actionable insights.

The Preparation Gap emerges when organizations deploy feedback systems without investing in guidance for both giving and receiving feedback constructively. Untrained participants provide unhelpful feedback that often focuses on symptoms rather than root causes, while feedback recipients lack the skills to process and act on input effectively.

The Action Gap creates perhaps the most damaging failure mode: feedback that doesn’t drive change creates cynicism among participants. When employees, customers, or stakeholders see their input collected but never acted upon, they disengage from future feedback opportunities. This creates a vicious cycle where the quantity and quality of feedback diminishes over time.

The Trust Gap manifests when 79% of participants suspect personal agendas influence feedback, undermining the psychological safety required for honest communication. Without robust anonymity protections and quality controls, feedback systems become political tools rather than improvement mechanisms.

The Emotional Gap reflects the reality that 62% of participants experience anxiety during feedback processes. When systems aren’t designed with emotional intelligence, they trigger defensive responses that prevent effective learning and adaptation.

Adoption Blockers: Why Feedback Systems Never Launch

Beyond implementation failures, many organizations never successfully launch comprehensive feedback systems due to persistent adoption blockers. Resistance to change represents the most common barrier, with 54% of organizations identifying it as their primary challenge when implementing new feedback technologies.

Fear of the unknown creates significant anxiety among both feedback providers and recipients. Employees worry about negative repercussions, while managers fear damaging relationships or causing discomfort. This fear often manifests as a preference for familiar but ineffective processes over potentially transformative but uncertain new approaches.

Inadequate communication stands out as a fundamental barrier to successful feedback system adoption. Organizations frequently fail to develop comprehensive communication strategies that explain why feedback changes are necessary and how they’ll benefit all participants. Without clear communication about the “why” behind feedback initiatives, stakeholders default to skepticism and resistance.

Poor user experience in feedback tools and processes creates immediate friction that prevents adoption. Complex interfaces, excessive clicks, and buried functionality frustrate users and reduce participation rates. When collecting feedback feels burdensome, people simply won’t engage with the system.

Lack of senior management buy-in represents perhaps the most critical adoption blocker. Without genuine commitment from leadership — not just lip service support — feedback initiatives fail to gain organizational traction. Senior management must not only endorse feedback collection but actively participate in the process and demonstrate how feedback drives decision-making at the highest levels.

The Organizational Context: Why Feedback Loops Are Missing

Understanding why organizations lack sufficient feedback loops requires examining the broader organizational and cultural factors that inhibit feedback system development. These systemic issues go beyond individual resistance to touch fundamental aspects of how companies operate.

Structural Barriers to Feedback Culture

Siloed organizational structures create natural barriers to comprehensive feedback systems. When departments operate independently with separate tools, processes, and success metrics, creating unified feedback loops becomes technically and politically challenging. Platform engineering teams often find themselves caught between product development silos, infrastructure operations silos, and business stakeholder silos, making it difficult to establish coherent feedback mechanisms.

Organizational culture not aligned with continuous feedback represents a deeper challenge than simple resistance to change. Many companies operate under cultures that view feedback as criticism rather than opportunity, creating environments where honest communication is discouraged. In such cultures, feedback systems fail not because of technical limitations but because of cultural incompatibility.

Limited resources for implementing comprehensive systems reflects a common prioritization challenge. Organizations often underestimate the true cost of effective feedback systems, which includes not just technology but also training, process design, change management, and ongoing maintenance. When feedback initiatives are under-resourced, they inevitably fail to meet expectations.

Technical complexity of integrating multiple feedback channels creates practical barriers that many organizations struggle to overcome. Modern feedback systems must aggregate input from customer support systems, developer productivity tools, employee engagement platforms, and business intelligence systems. The technical challenge of creating unified views across these disparate sources often proves overwhelming.

The Psychology of Feedback Avoidance

Underdeveloped feedback literacy represents a critical but often overlooked barrier. Most individuals lack the intrapersonal skills, emotional intelligence, and communication competencies required to give and receive feedback effectively. This literacy gap affects not just individual interactions but organizational capacity to design and implement effective feedback systems.

Confirmation bias leads both feedback providers and recipients to favor information that confirms existing beliefs while disregarding contradictory insights. In organizational contexts, this bias can cause feedback systems to reinforce existing assumptions rather than challenge them, limiting their effectiveness for driving meaningful change.

Power dynamics between different organizational levels create psychological barriers to honest feedback. Employees may feel intimidated about providing feedback to leaders, while managers struggle with giving honest feedback to subordinates due to concerns about maintaining authority or damaging relationships.

The Platform Engineering Opportunity: Leading Organizational Transformation

Platform engineering teams are uniquely positioned to lead organizational transformation in feedback systems due to their role as enablers of developer productivity and their direct connection to business outcomes through technical capabilities. Unlike other organizational functions that may operate in isolation, platform engineering naturally bridges technical implementation and business value creation.

The Strategic Advantage of Platform-Led Feedback

Platform engineering teams possess several advantages that make them ideal champions for comprehensive feedback systems. They understand system integration challenges that often derail feedback initiatives in other parts of the organization. Their experience with developer experience optimization translates directly to user experience design for feedback systems.

Technical credibility enables platform teams to gain buy-in from skeptical stakeholders who might resist feedback initiatives from other organizational functions. When platform engineers demonstrate how feedback loops improve system reliability and developer productivity, technical leaders take notice in ways they might not for soft-skill focused initiatives.

Cross-functional relationships developed through platform service delivery create natural channels for feedback collection across different organizational personas. Platform teams already interface with end customers through product reliability, internal developers through IDP services, and business stakeholders through operational metrics.

The Multi-Persona Integration Model

The most effective approach for platform engineering teams involves establishing unified feedback loops across three critical personas: end customers using software-based products, internal developers consuming IDP services, and company stakeholders who need visibility into platform ROI.

This integrated approach creates powerful synergies where feedback from one persona informs improvements that benefit others. Customer complaints about product performance directly inform platform prioritization decisions. Developer productivity gains from platform improvements translate into faster customer feature delivery. Stakeholder feedback about business priorities helps focus platform roadmap items that maximize both developer experience and customer value.

Cross-functional insights emerge when feedback loops interact effectively, creating results greater than the sum of individual feedback streams. This convergence manifests in adaptive learning cycles where insights from one persona continuously inform improvements that benefit all others, creating positive feedback loops that accelerate overall platform maturation and organizational alignment.

The Path Forward: Establishing Feedback-Driven Decision Making

Creating effective feedback loops requires systematic approach that addresses both technical implementation and cultural transformation. Organizations must move beyond viewing feedback as a periodic activity to embrace it as a continuous capability that drives daily decision-making.

Building Feedback Literacy Across the Organization

Developing feedback literacy represents the foundational requirement for any successful feedback initiative. This involves training individuals in intrapersonal skills like self-awareness and emotional intelligence, interpersonal skills for effective communication, and technical skills for feedback system usage.

Creating safe environments where feedback is viewed as growth opportunity rather than criticism requires deliberate culture change efforts. Leadership must model vulnerability and openness to feedback while establishing clear guidelines that separate feedback on performance from personal attacks.

Establishing clear objectives ensures feedback collection efforts focus on actionable insights rather than generic satisfaction scores. Organizations must define specific, measurable goals for feedback processes and align them with broader business objectives.

Technical Implementation Strategies

Unified feedback aggregation platforms provide the technical foundation for effective multi-persona feedback systems. These platforms must support various input channels while maintaining cross-persona visibility and enabling correlation analysis between different feedback types.

Real-time feedback mechanisms ensure timely input that can drive immediate course corrections rather than quarterly reviews of historical data. Modern feedback systems should support continuous collection through embedded surveys, in-app feedback widgets, and automated analytics.

Advanced analytics capabilities transform raw feedback into actionable insights through pattern recognition, sentiment analysis, and correlation detection across different feedback streams. Machine learning capabilities can help identify emerging trends and prioritize the most critical feedback items.

Cultural Transformation Requirements

Leadership commitment must extend beyond initial endorsement to ongoing participation in feedback processes and transparent communication about how feedback drives decision-making. Leaders must demonstrate vulnerability by seeking feedback on their own performance and openly discussing how input influences their decisions.

Closing feedback loops through transparent communication about actions taken based on input builds trust and encourages continued participation. Organizations must establish systematic processes for acknowledging feedback, communicating decisions, and updating stakeholders on progress.

Continuous refinement of feedback systems ensures they remain relevant and valuable as organizations evolve. Regular evaluation of feedback effectiveness, response rates, and business impact enables continuous improvement of the feedback capability itself.

Conclusion: From Feedback Crisis to Competitive Advantage

The feedback crisis facing most organizations represents both a significant challenge and a tremendous opportunity. Organizations that successfully establish comprehensive feedback loops across multiple personas will create sustainable competitive advantages through faster adaptation, better decision-making, and stronger stakeholder relationships.

Platform engineering teams, with their unique combination of technical capabilities, cross-functional relationships, and business outcome focus, are ideally positioned to lead this transformation. By establishing unified feedback loops that connect customer satisfaction, developer productivity, and business value creation, platform teams can demonstrate clear ROI while building organizational capabilities that benefit the entire company.

The path forward requires commitment to both technical implementation and cultural transformation. Organizations must invest in feedback literacy development, create psychologically safe environments for honest communication, and implement sophisticated technical systems that support continuous feedback collection and analysis.

Most importantly, they must view feedback not as a periodic assessment activity but as a continuous capability that enables adaptive response to changing conditions. In an increasingly complex and rapidly evolving business environment, the ability to collect, process, and act on feedback effectively may well determine organizational survival and success.

The question is not whether your organization needs better feedback loops — it’s whether you’ll take action to build them before your competitors do. Platform engineering teams have the opportunity to lead this critical transformation, turning the feedback crisis into a strategic advantage that drives both technical excellence and business growth.