Everybody is suddenly saying “agentic platform.” Almost nobody can define one. That is exactly what we set out to fix.
I invited Kaspar von Grünberg onto the channel. He has spent years shaping platforms, put the internal developer platform, the IDP, on the map with Humanitec, and built PlatformCon into the largest platform engineering community. He is now building Canyon, a control plane for enterprise AI, and his book Thinking in Platforms is on the way. By the end of this conversation you will know what an agentic platform actually is, why it matters, what it takes to build one, and how to start.
Start With What a Platform Actually Is#
Before you can talk about agentic platforms, you have to be clear about what a platform is in the first place. In the classic sense of platform engineering, a platform is a set of paths along a value stream to a business end point. When you want to achieve something as a knowledge worker, you need things from another team, from documentation, from internal tools. A good platform paves those paths for you. It says: Romano, if you need an ephemeral environment, do this, and here it is.
Platform engineering started in software development, and Kaspar frames it as the discipline of building digital factories. Over the last ten years, software development has gone through its own industrial revolution. The point of the factory is not that the developer becomes a factory worker. The point is that the factory takes care of everything on the way, so the developer can focus on the work that actually matters, the coding. As so often in knowledge work, the pattern originates in software development and then spreads to the rest of the economy. Agile, SAFe, Kanban all took that route.
More Than a Platform With AI On Top#
The obvious pushback is this: we already have platform engineering. Is an agentic platform not just a normal platform with a bit of AI bolted on? Kaspar’s answer is no, and the reason is worth sitting with.
The big problem everyone faces is making agents productive inside the enterprise, and the enterprise is very different from a fifteen-person startup. In an environment with hundreds of thousands of people, you cannot take a frontier model, drop it in, and declare the job done. That is where the job begins. To be productive, agents have to be treated almost like humans. You have to be careful, because they are not human, but the working environment has to be built for them. They work along a value stream, they need a way to be reached, they need to handle exceptions.
Kaspar made the point with a picture that stuck with me. Imagine you hire a brilliant person, then throw them into a Linux environment when they are a Mac user, put everything in a language they do not speak, and give them no onboarding. A week later you are surprised they were not productive. That is exactly what companies are doing with agents right now, and it will not work. The base layer of the platform still has to be there. Without a well defined source of truth, clean pipelines, and a sane resource and hosting setup, you will have a hard time. But on top of that base, agents need more.
The Three Layers of an Agentic Platform#
The internal developer platform Kaspar helped define was, for years, drawn as a developer control plane with a portal and version control, an integration and resource plane, monitored and secured, running somewhere. That was the pre-agentic diagram, and it was built purely for software development. Today you already see Legal Platform Engineers and Sales Platform Engineers on LinkedIn, so the discipline is spreading. The agentic platform he is now describing has three layers, and it can be verticalized into development, marketing, sales, finance, or legal.
The first layer is Tooling. This is largely the platform you already have: control and governance, integration, provisioning, resources, tools, security, observability. In the agentic world it becomes the base that the agents call on. It helps to picture it as a base rather than a top layer, because agents do not work linearly. They move back and forth across the layers.
The second layer is Path Specifications. This is the map that tells agents, and every other part of the system, how to find their way through the platform. You cannot leave that to the agents to figure out.
The third layer is Agent Infrastructure. This is what actually serves the agent: context, capabilities, memory, evaluation. The important insight is that you can swap the tooling per vertical while the path specifications and the agent infrastructure stay the same. Move from development into marketing and you get marketing tools, but the system that governs the agents does not change.
Where the Data Platform Fits#
A question I hear constantly is where the data platform sits in all of this. The data itself lives in the tooling layer of the development platform, the data lakes and databases and resources that run the software. But there is honestly another environment being built alongside it: the data platform for the ML and quant people who own model evaluation and fine-tuning. It is a special form of platform, with a reference architecture but genuinely different requirements.
Kaspar’s recommendation, and mine, is to run two platforms: a data platform and an agentic development platform. Trying to put too much on a single platform is almost always a mistake. He has these conversations with organizations that have four or five thousand developers, and the management impulse is always to build one big platform. There is a natural limit, somewhere around several hundred developers, beyond which one platform stops making sense. Data platforms in particular are different enough that they deserve their own home, especially in industries like finance where data engineering and software engineering are two distinct job roles.
Everything as Code Is the Entry Ticket#
One thing I have been teaching for years is that everything now belongs in code and under source control. Not just the application, but Jira, Confluence, SharePoint, all of it. Kaspar put it plainly: in 2026 this is the winning strategy, and with agents it becomes far more important. If it is not codified, agents cannot work with it.
Path Specifications, and Where the Work Actually Happens#
The path specification is the real newcomer, so it deserves a careful look. Kaspar and his colleagues debate the core question: should you tell an agent exactly what to do, or just say “here is the task, figure it out”? Since Opus 4.5 and 4.7, the model is not the problem. These models are remarkable. The problem is feeding them information efficiently, and that is what the platform is for.
He pointed to an analysis of the Claude Code source code, published late last year, that dug into how the tool is actually built. The striking finding he cited is that only around 1.6 percent of it is where the LLM does its magic, and roughly 98 percent is deterministic routing. The Anthropic engineers give the agent freedom, then constrain it, because letting the model reason through everything from scratch on every round burns tokens and is inefficient.
That is what an agent path is. When you do a PR review, the path says: here are the tools, here is the context, here is your direct route to source control, this is how you do it. Kaspar calls agent paths probabilistic, but look closely and they carry a large number of deterministic demands, with the LLM doing only a few percent of the work. This is where I think the real gains sit, and it is why the complexity moves down into the path specification rather than into the model.
Agent Infrastructure: The Harness and Governance#
Agent files, the agent.md files, list what an agent can do, but they need a system to run on. That system is the agent infrastructure, and it has two parts: the harness and the governance layer.
The harness is, in Kaspar’s words, the operating system for a single agent. It has four components: serving, context management, capabilities, and evaluation. Serving covers the models, GPU hosting, gateways, routers, orchestration, runtime management, and queues. Context management is memory management, efficient serving of context parts, and chunking work effectively when you launch background agents. He made the observation that most of this is one-on-one infrastructure management, which is why infrastructure people matter more than ever. Capabilities is the set of everything the agent can do through protocols, gateways, and tool connections. Evaluation is the LLM-as-judge, the rubrics, the scoring.
Governance is the other part, and it is the management framework for hundreds and thousands of agents. This is where the hardest open questions live right now. How do you handle identity? Is it identity federation? With which identity does an agent actually act, and who is accountable? Kaspar had a fascinating debate about exactly this with a regulated industry in New York. Security and observability of agents sit here too. The agent path is traced and supervised through the governance plane.
The Balance of Power Between Probabilistic and Deterministic#
The deterministic side of all this is not new. CI/CD pipelines that compile, build, scan, and deploy have been in the reference architecture for decades. What matters is the balance of power between the probabilistic and deterministic parts of the system. The probabilistic system does its part, a deterministic gate checks it and returns clear error messages, and the probabilistic system reads those errors and decides whether to proceed.
The more fragile the thing being touched, the more this matters. You would not say “hey agent, go set the production Postgres configuration.” You would say “hey agent path, here are the options,” expose a deterministic endpoint with a clear production database, let the agent choose within bounds, then send that choice against a policy framework like OPA to check it. These are the integration and delivery planes, and putting them together makes the plane hybrid by design.
The Four Levels of Agentic Autonomy#
Kaspar’s team works with four levels of agentic software development. Level 0 is human. Level 1 is a sprinkle of AI, the assistant in your CI that reviews and suggests. Level 2 is human-in-the-loop, where you become the orchestrator. You trigger the system, it does the work, you review it, and you can run two or three in parallel. That is the level slowly entering enterprises today, and it is the target state for most larger organizations.
He walked me through a Level 2 PR review. A developer opens a PR, a webhook triggers an orchestrator, identity is resolved, a lookup happens based on the orchestration, policies are applied, the right capabilities are attached, context is pulled from source control, and only then, well into the flow, does the probabilistic system run and the model do its work. The output goes through model safety, then the eval framework, and the result is fed back to the model to decide whether to redo. Exit criteria are checked, everything is observed, and it lands back with the human for the decision. The user stays in the loop, which is why it is Level 2.
Level 3 needs the full platform. If you have it, you can reach Level 3. If you do not, you cannot, which is why the jump from Level 2 to Level 3 is the big one.
The Dark Factory Is Already Here, at the Edge#
Not many companies are at Level 3 yet, but the frontrunners are much further ahead than most people assume. Kaspar already knows Level 4 companies operating outside the loop, the dark factory. The common misunderstanding is that Level 4 means the entire company runs autonomously. It does not. The reality is that Level 4 demands a machine error rate below the human error rate, and it works best outside regulated industries, where the question of why a human is still in the loop does not carry a compliance answer.
The concrete example he gave: an agent reads the transcripts of a customer support conversation, works out that a component failed for a user, files a PR, approves that it is fixed, and ships it, with no human in the loop. These things exist now, in apps you already use, and it is maybe five percent of what the absolute frontrunners are doing. There is no technical reason we cannot get there. It is pure platform management. In five years this will look the way DevOps and platform engineering look today. It is always a bell curve, and the frontrunners are moving fast.
Standardization Is the Real Unlock#
The uncomfortable truth is that most enterprise source code is a mess, and people use that as an excuse. They say their code is too complex for agents to ever understand, and they are probably right. The answer is not to protect the mess. It is to throw it away and start fresh. If your standard enterprise setup has five hundred different ways to spin up a Postgres database and a staging environment, Go in one microservice, Python in the next, Java and Spring in a third, that makes no sense for humans and even less for agents.
The job, as always in computer science, is to step back. The tide is rising and you have to rise with it. Everything gets standardized. All your Postgres databases look the same, and out of the box everything is built for agents. That completely changes how you build. But you have to reach that realization and act on it, or you have a serious problem.
I see this the way I see the history of programming languages. At university I learned Assembler, working directly on the machine’s registers. Nobody writes Assembler anymore. Then came C, C++, Java, the object oriented languages. We are simply in another step of that evolution, except the output is no longer deterministic in the way machine code always was.
Determinism Was Always an Illusion#
That led to one of my favorite parts of the conversation. I asked whether specifications are the new source code, and whether we get a new application every time we compile. Kaspar’s answer reframed the whole question. The output was never deterministic. Determinism only exists when you have a clean input regime, compile it, and get a clear output. But that is not where errors come from. Errors come from the probabilistic node in every real system, which is the human. Twelve people each do things slightly differently. Our software setups were never deterministic. They were always a fight against the probabilistic nature of the humans in the loop, and that does not go away.
The other misunderstanding is expecting agents to get it right the first time. Humans do not get anything right the first time. Mathematics does not either. If you want the global maximum of a complex function, you do not jump straight to it. You take a shot, analyze, look at the gradient, and iterate. It is always an iterative process, and it always will be. That is why the platform matters, and why the fundamentals become more important rather than less.
The fundamental that matters most is knowing what you actually want. Kaspar’s litmus test after working with fifteen software development teams is to ask why they are building a feature and what problem it solves. In ninety percent of cases, nobody knows. That was the problem of the last decades, and it will be the problem of the next ones.
Multi-Model Is the New Default#
We recorded this in July 2026, at the edge of a fast moving market, so this part is a snapshot. Coming out of Kaspar’s conferences in London and New York, the word among platform engineers is clear: everyone is going multi-model. The reason is speed and lock-in risk. If you bet everything on one model and then that vendor pulls it, or the switching cost becomes intense, you are exposed. Going multi-model means you probably cannot go all-in on a single agent tool either. Betting on one vendor at this point of the development is too dangerous.
There is an economic layer underneath. If someone owns the frontier of both GPUs and the application layer, the incentives pull them together. Hardware providers are moving into the model layer and into the app. Open source models are now roughly on the level of Sonnet, arguably a touch better, and that trajectory continues. Kaspar’s read is that many of the hard components, especially context and memory management, and certainly the governance services like identity, observability, security, and eval frameworks, will be built in-house. He sees no world where you outsource those. He also thinks this is good news for Europe, because the large advantage the US frontier labs hold today erodes as the models converge and self-hosting becomes viable.
What Changes for the Organization#
I have argued for years, in my book on the Cybernetic Enterprise, that the platform is the foundation of an agentic organization, and that organization and processes matter just as much as the technology. So I asked Kaspar whether a company can adopt an agentic platform and keep its organization as it is. His answer was that you cannot avoid the transformation.
His analogy was transforming a bank from the branch floor to a high-performance, computer-driven trading floor. The branch floor becomes less important. What matters are the people in the high-performance program. In our world those are the technical product managers, the good software architects, the people who write the specifications the agents work from, and above all the platform teams. The platform team has to fold in the security and infrastructure people and become a tight group optimizing the platform around the architects and the people who define the interfaces.
His practical advice is to start super small. Any new software you build, build it in the new world, no matter how small. He is a strong advocate for investing in a molecular unit where you test how it actually works, which runs against standard management advice and makes management nervous because they cannot yet see how it scales to hundreds of customers. But you have to get comfortable pointing a large platform group at one tiny app. It is a startup mindset. You do things that do not scale at first, and once it works, you put more energy behind it.
How to Start: The 3-3-3 Rule#
This connects directly to my own hypothesis, that the whole organization should be structured along the value stream, with IT and business working together in one line organization, small product teams of around three plus or minus two people, and the platform team as the new IT underneath. Kaspar agrees, and Zühlke already runs this way internally.
His playbook, which is a whole section of his book, is to build a minimum viable platform. Start super small, start with user interviews, build the first agent capability. It does not have to be big, but you have to get in front of real users. His rule of thumb is 3-3-3: three people, onboarding three teams, in three months. That is the investment. You keep expectations modest, build an MVP with the 3-3-3 method, then move into a production readiness program and get the first thing into production for those three teams. When it is solid and clearly better than what the teams have today, you build the production scaling program and onboard teams one after another.
The line that stuck with me most: a platform is never finished. It is the collection of paths within a value stream, and you work on it for the rest of your working life. You build a good foundation, then it is paths, paths, paths, added by going back to users and gathering what they need. It is the internal product, and in my view it is your factory.
Stay a Platform Engineer#
I asked Kaspar for the one thing to take away. His answer: stay a platform engineer. It is the job of the future, because AI agents are not productive without platforms, which makes platform building more important than it has ever been. We will probably call the role something new, agentic platform engineer or AI platform engineer, even though at its core it is the same discipline we have been practicing all along.
Kaspar’s book, Thinking in Platforms: Platform Engineering as the Operating Model for Work in the AI Era, comes out on August 18. It has three parts: a reflection on platforms, an abstract model for visualizing them from the architects to the boardroom, and a playbook for building them.
Resources from Kaspar#
- Reference architecture
- The four levels of agentic software development
- Kaspar’s newsletter
- University: Agent Infrastructure and Agentic Development Platforms
- Kaspar’s website
- PlatformCon
Thank you, Kaspar, for a genuinely great conversation. I learned a lot. If you want more on how to deal with this kind of AI, subscribe to the channel, and if you have questions or recommendations, leave them in the comments.