Platform Engineering and Context Engineering Converge on the Same Unit

Two disciplines have been walking toward each other for a while, and this month one of them published the map.

In Thinking in Platforms, Kaspar von Grünberg — who coined the term Internal Developer Platform — and Luca Galante, who hosts PlatformCon and writes Platform Weekly, argue that platform engineering is not a tooling category but the operating model for work in the AI era. Part II sets out their conceptual model, the Paths to Outcome:

“A path is one of those routes made deliberate. A user turns up with a single intent and the path serves it end to end. That is the molecular unit of a platform. The input is the ask itself. Think “give me a small Postgres database”. The interface is where the ask goes in, a portal, a CLI, a pull request etc. The capability is what actually fulfills it. The output is the database that gets handed back.”

Four slots: input, interface, capability, output. And note which one the authors chose to name the fulfilment slot — capability.

That word is doing the same job on the other side of the industry. Context engineering — deciding what an AI agent is shown, in what shape, and what it should never have to figure out for itself — has been arriving at the same conclusion: the useful unit is not an endpoint, not a connector, and not a prompt.

Different vantage points, same unit

The two fields overlap more than their vocabularies suggest; plenty of people work in both. What differs is where each starts.

Platform engineering starts from the producer. Its subject is the supply side: services, APIs, data products, infrastructure. Its achievement — inherited from DevOps and SRE, then made systematic — is treating those as a product with owners, contracts and paved roads rather than a queue of one-off requests.

Context engineering starts from the consumer. It has a model with a finite context window, probabilistic selection, and a per-token bill. Its instinct is to remove everything the model does not need to see, and to move every decision it can out of the reasoning loop and into deterministic execution.

Approach from either end and you land on the same object: a small, deliberate, task-shaped route with a declared contract at each end.

The one thing that is genuinely new

“The user is an agent” is a shortcut that hides the interesting part. There are three people involved and one runtime consumer that is not a person.

The platform engineer builds and owns the path. The application developer turns up with a first-order intent — “give me a small Postgres database” — and is the book’s canonical user. The AI engineer turns up with a second-order one: they are building an agent, and what they need is the right tool, shaped correctly, for a consumer that is not them. The agent is the only party that is not human.

The second row is the new thing. In platform engineering the requester is the user, so a confusing interface gets reported — someone reads the docs, or asks a colleague. In context engineering the requester and the consumer are different entities, and the consumer cannot report back in words. The AI engineer designs for something that will silently pick the wrong tool and bill them for it.

That is why the contract has to carry more than a label: typed parameters, a description that survives being read out of context, and explicit behaviour — is this operation safe, idempotent, cacheable? A human never needed those written down. An agent cannot work well without them.

It is also why the output has to be shaped rather than forwarded. Handing back whatever the upstream API said is the most expensive mistake in agent integration, because every unnecessary field is a token, on every turn, forever.

The declarative habit, extended one slot further

Here platform engineering has the head start. It has spent years winning the declarative argument — Kubernetes manifests declare desired state, Crossplane and Terraform declare infrastructure, Argo and Flux reconcile a repository against a cluster. Nobody there needs persuading that writing the thing down beats writing a script.

So the question is not declarative versus code. It is what gets declared. A manifest declares desired state: replicas, memory, a bucket in a region — exactly right for a resource. But a path reaching into a system of record on an agent’s behalf is an interaction, and what a reviewer needs is not its shape at rest but its behaviour: which upstream operations it can invoke, what a bound credential therefore authorizes, and what comes back. That part is still commonly a container of glue code, referenced by a perfectly declarative manifest that says nothing about what the code inside will call.

That gap is not closable by inspection, because you cannot enumerate, by reading general-purpose code, the complete set of upstream operations a credential will ever authorize — computed URLs, branching and dynamic dispatch defeat static analysis, so you end up verifying one observed run rather than the artifact. Declaring the workload has 512MB and two replicas does not help. Declaring the interaction does: every upstream call, every credential binding, every step written down, so the surface is the artifact — lintable and diffable before it runs, exactly as a manifest already is.

The book’s preface makes the same bet from the other end:

“AI amplifies what you have — it doesn’t turn a failing system into a winning one. Organizations only unlock real productivity gains when AI runs on top of clear interfaces, clean data, documented workflows, and deterministic systems. The platform is the prerequisite.”

Clear interfaces, documented workflows, deterministic systems. Note that none of those are properties of infrastructure — they are properties of the interaction layer sitting on top of it, reached from platform strategy rather than protocol design.

That is the bet behind Ikanos, our open source capability engine: one file per capability with the four slots written down, landing in the Backstage catalog and running as a Kubernetes custom resource — inside the platform team’s machinery rather than beside it.

Where the disciplines genuinely differ

Convergence is not overlap. Platform engineering owns far more than the capability slot: identity, policy, state, and the organisational work — the onboarding loop, the ROI case, the argument with the team that would rather keep its own pipeline. None of that lives in a spec file. Provisioning infrastructure is also a different problem from calling a system of record; one creates a durable resource, the other reads or mutates one.

And one asymmetry runs the other way. A platform’s paths are usually authored up front, for a known population of developers. The paths an AI engineer needs get requested while working, because agents surface what is missing mid-task and their engineer finds out from a trace. That argues for a unit cheap enough to author on demand and safe enough to approve quickly.

The takeaway

Platform engineering earned this model. It absorbed the lessons of DevOps and SRE and turned them into something an organisation can run. Making the route deliberate is not an obvious idea; it took a decade of practice, and it generalises to agents because it rests on durable principles rather than a particular generation of tooling.

Context engineering is the newer discipline, and it is inheriting more than it is inventing. What it adds is a consumer that raises the stakes on contract quality — one that cannot ask a colleague which endpoint to call, and bills you for guessing wrong.

If your organisation already thinks in paths, you have most of the model. The AI era does not ask you to replace it. It asks you to write the capability slot down in a form something non-human can consume and something human can approve.

Same unit. A consumer that cannot ask for help. Write it down once.

Further reading

• 📖 Thinking in Platforms — Kaspar von Grünberg and Luca Galante, Weave Intelligence
• 🧩 Beyond iPaaS: why capabilities are the right unit
• 🔌 Capabilities are microservices for agents — and they work with your gateway
• 🎓 Track 1 — context engineering, hands on · ⚙️ Ikanos