How the North Star Architecture maps to platform engineering — and why agentic AI is an enhancement, not a fourth platform.
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.