Your First AI Agent Worked. Your Tenth Needs a Platform.
One-off agents feel reasonable until identity, access, governance, observability, and ownership turn into platform sprawl.
Hi, before we continue, a quick word from our sponsor.
AI agents are moving into prod. Is your secrets strategy ready for that?
Find out at the webinar on July 22nd
Hi,
Last week, Jaroslav Pantsjoha opened this series with a blunt argument: your AI demo worked, but that is no longer the impressive part.
The first part was about the production gap. Enterprise AI does not usually fail because teams cannot build useful proofs of value. It fails when those proofs of value reach the production readiness door and run into the harder questions: who owns this, who runs it, who governs it, and what happens when it breaks?
This week’s piece picks up exactly there.
The first agent still looks like a neat business use case. The tenth starts to look like something else entirely. Each one-off may make sense on its own, but together they can become a pile of useful systems nobody can govern as a whole.
That is why the second part is about the hidden platform problem behind enterprise AI. If the first part asked what happens after the demo works, this one asks what the enterprise needs underneath before ten working demos become ten disconnected systems.
Cheers,
Apramit Bhattacharya
Editor-in-Chief
Our upcoming events this month
Agentic DevOps with Claude - Thursday, July 23rd · 11:00 AM EDT
Where do agents and MCP servers actually belong in a Kubernetes stack?
Most platform teams are still guessing. Michael Rishi Forrester (Accenture) spends four hours building a 33-component AI-native IDP live, on a provisioned cluster, with Claude Code doing the actual work: scaffolding Helm values, wiring up ArgoCD’s App-of-Apps, resolving sync issues as they come up. You clone the repo when it’s done and it runs.
Use code EMAIL40 for 40% off.
AI-Powered GitOps & Platform Engineering - Thursday, July 30th · 11:00 AM EDT
Most AI-in-GitOps failures trace back to one thing: stale context, not a bad model. Taylor Dolezal (Head of OSS at Dosu) has seen this pattern across 100,000+ repos, and this session runs a live query against fresh vs. stale knowledge side by side, so you can see where the token cost actually goes and where the accuracy breaks down before you build anything on top of it.
Use code EMAIL40 for 40% off.
Book now →
Both sessions are teaching the same shift from two different angles, Michael’s building the platform itself, Taylor’s making sure the agents on it aren’t running on stale context. Worth sitting through both if you’re the one who’ll own this stack. Bundle Pass gets you both for 25% off - use code BUNDLE25.
The first agent you build feels like a product problem. And it is.
That is the beauty of where we are now. AI and agents let business domain experts amplify what they already know with AI-powered workflows. Someone sees a problem, wraps a model around it, adds a connector or two, and suddenly, there is a working proof of value. Great.
But by the tenth demo, it starts to look different. You realize you have built sprawl where you wanted leverage. You wanted a capability multiplier. What you got was ten bespoke things. The first agent has its own service account. Fine. Good start. A few demos fetch data through connectors. Maybe A2A, agent-to-agent, would be better suited in some cases. Maybe not.
And that is when the real questions start turning up:
How is data access being governed?
Who can see what?
Who decides what one agent is allowed to call?
Who checks that these capabilities stay coherent, consistent, and correctly implemented?
And who can answer any of that across the whole estate?
Together, it becomes a pile of bespoke systems nobody can govern as a whole.
The line I find myself using early now is this: the local AI harness is the easy bit. And yes, I know it has its own challenges. The harness is whatever you wrap around a subscription so you can reuse it. It is the quickest way to get started and the easiest way to show value. That is where the harness stops being enough.
Now you are in platform territory.
The governance. The security controls. The monitoring. The observability. Release management for agents sounds simple enough. It is still programmatic. You still test it. There is no magic to it.
But that is the agent layer sitting on top of an agent platform. And most teams do not have the platform. They jumped straight to the top bit: can I have agents, and can I release them? And they quietly assumed everything underneath already existed.
It doesn’t.
The first agent hides the problem
That is why this is so easy to walk into. The first agent may genuinely not need a platform. It might just be a SaaS-y AI-powered workflow. Think Gemini Enterprise, or something like n8n, plus a few connectors. One use case. One team. One problem to solve. Build a whole platform for that, and you would rightly get called out for over-engineering.
So the trap is obvious only in hindsight. The second agent, the third agent, and the tenth agent each feel like they do not need a platform either, taken alone. Every decision to build another one-off is locally reasonable. It is only when you stand back and look at the whole portfolio that the cost shows up. Now you have ten different answers to questions that should have had one.
The scatter is measurable too. McKinsey’s State of AI in 2025 found that only 23 percent of respondents say their organizations are scaling an agentic AI system somewhere in the enterprise, while another 39 percent are still experimenting. In a separate piece on scaling agentic AI, McKinsey puts the gap even more sharply: nearly two-thirds of enterprises have experimented with agents, but fewer than 10 percent have scaled them to deliver tangible value. That feels right to me.
The shortage is rarely the agent itself. It is agents that connect beyond the one workflow they were built for.
Agents that share identity, access, governance, observability, and evaluation instead of solving all of that from scratch every time. That is where the one-off stops being clever and starts becoming expensive.
What the agent platform actually is
Once you stop looking at each agent as a one-off, the shape gets clearer. I treat the agent platform as its own layer, separate on purpose. At the bottom, you have cloud foundations: deploying projects programmatically, infrastructure as code, the usual base layer. That part is industry vanilla by now. At the top, you have the agent solutions, the actual business use cases. In between sits the agent platform, and everything in and around that platform is the meat.
This is the crux of it. Identity, so an agent acts as a known principal with the right permissions, not a shared god-mode account security will rightly veto. I’m watching agent identity move from ordinary service accounts toward proper, first-class agent identities. Then a gateway, so you have visibility into what each agent does, when it does it, and what it touches.
The point is not to give the agent free rein to “go and fetch me stuff.” The point is to let it work inside the scope it has been given.
Then you need the rest of the platform pieces. An agent registry. The protocol servers you have to run, deploy, and secure. Observability and evaluation, so you know the output is still correct after a model upgrade, not just that the service is up. And governance sitting over all of it.
I build most of this on Google Cloud, so that is the lens I naturally reach for. The managed pieces for identity, gateway, registry, evaluation, and observability are there to stand on instead of hand-rolling everything yourself. More importantly, you inherit governed defaults rather than inventing your own and getting them subtly wrong.
Build each of those once, well, and every team stands on them. Build them ten times, scattered across ten projects, and you have ten times the surface area to secure and no consistent way to answer for any of it.
This is where the agent platform stops being a nice idea and becomes a necessity. It is separation of concerns and separation of duties, applied to agents. And it is a different beast from just standing up another landing zone on another cloud.
The leadership point hiding inside the architecture is simple: a shared platform is shared accountability. Ten teams standing on one governed platform answer for their agents the same way. Ten one-offs answer ten different ways, which usually means no way at all. And treat that governance layer as an accelerator, not a brake. It is the thing that lets you ship the next fifty agents safely instead of re-litigating risk every single time. You can see that shift in the open now. Santander has published open-source AI projects from its AI Lab, including work around governance, hard gates, and decision controls on GitHub When a bank is willing to put that kind of control layer in public, governance has clearly moved from private moat to shared foundation.
The wider industry is circling the same point. a16z’s Big Ideas 2026 frames AI as an enterprise orchestration layer: a move from isolated copilots to coordinated systems that work across teams and tools. That is the platform argument in another language. The durable value is not just in the agent. It is in the layer that coordinates context, tools, permissions, and execution across the whole estate.
We’ve built platforms before. This one’s harder, yet familiar
None of this is entirely new, which is useful to remember. We’ve built platforms before. Container platforms, internal developer platforms, cloud landing zones, paved roads. Different names, same basic instinct: stop every team from solving the same operational problem from scratch. This isn’t the first platform I’ve built and deployed. Think container platforms back in the day. Same shape, more complex.
The complexity now is that there is non-determinism in the ecosystem. The instinct that served me then serves me here: avoid bespoke where you can. I keep custom wheel-creation to a minimum and lean on managed services, because anything bespoke goes out of date fast and turns into operating tech debt.
But here’s the catch that is genuinely new.
Even when you use a managed platform, you still have to make the calls.
Which model do you swap out? When do you swap it? What changes when you do? That is a whole new skills profile, and most teams have to adapt to it.
And the platform cannot become a free-for-all of services either. Interweave too much of it, and you get latency. Before you know it, you cannot tell what speaks to which system, or which one is meant to be the source of truth. That is the classic way these things go badly wrong. One small thing gets tweaked, and the downstream impact gets amplified.
Which is also why I push back early and often: half the time, you do not need an agent for that. It is just automation. It is really good Terraform. Put an agent on a deterministic job, and all you have bought is non-determinism you will have to govern, for no reason.
The vendor changes the names of the services. It does not change the shape of the trap. Whatever stack you are on, the question is the same: is every team solving identity, data access, evaluation, and deployment from scratch, or are they building on a paved road that solved those once?
Who owns the paved road?
Once you decide the enterprise needs that paved road instead of ten one-offs, the next question arrives quickly: who owns it, who runs it, and who keeps the lights on once it is live? Because once it is live, it keeps moving. And someone still has to be accountable for that.
This is where the SaaS pitch starts to become a risk. Everyone is learning how to adopt this at the same time, and the market is full of people selling the dream: deploy it, demo it, go live. But a real enterprise carries legacy. Data sources all over the place. Integration that is genuinely painful. Ownership lines that were already messy before an agent entered the room.
You deploy the shiny thing, and now it is disconnected from your estate, your data, and your moat. We can all agree that is not the most intentional of outcomes. To make it real, you have to blow it out, bring in more stakeholders, and turn it from a clever deployed thing into a reusable agent platform the whole organization can stand on.
And that is not just a technology question anymore. It is a people and process challenge. So if you are ready to keep following this enterprise adoption journey, that is where I want to go in the next post.
About the author
Jaroslav Pantsjoha is a Technical Director, Agentic AI Platforms, and a Google Developer Expert focused on taking AI systems from demos to production. He designs and delivers enterprise agent platforms, with work spanning architecture, governance, delivery models, and the operating changes needed to make AI systems run at scale. His current work focuses on the practical gap most organizations are now facing: how to turn promising proofs of value into production systems that are owned, governed, and accountable.
You can follow him on Linkedin here
Here’s our event for the month of August
Agentic RAG for Network Operations - Thursday, August 25th · 9 AM EDT
Sif Baksh, Principal Solutions Architect at Tines helps you build a RAG-powered NetOps assistant that pulls answers from your own runbooks, device configs, and troubleshooting notes instead of generic internet answers, so it can tell you why a BGP neighbor is stuck in Active, with the actual source cited. You’ll learn with guardrail patterns that stop the assistant from inventing answers or recommending unsafe production changes, so it’s something you can actually trust during an incident.
Use code SPECIAL40 for a 40% off on the event
Before you go, maybe a few books worth having on your shelf
Operational AI with Docker - Ajeet Singh Raina & Harsh Manvar
If Michael's event - Agentic DevOps with Claude IDP build got you thinking about what it actually takes to run agentic workloads in production, not just prototype them, this is the deeper dive. It covers containerizing, serving, and scaling LLMs and multi-agent pipelines with Docker and Kubernetes, the infrastructure layer most "AI for DevOps" content skips past.
AI Networking Cookbook - Eric Chou
Pairs naturally with Sif’s session on Agentic RAG for Network Operations. Where the workshop builds you a RAG assistant for troubleshooting, this book is recipes for the other side, using AI to automate config, monitoring, and threat detection across multi-vendor network environments, with working code for each one.
Microsoft Intune Cookbook, 2nd Edition - Andrew Taylor
For anyone managing endpoints rather than the network layer, practical recipes for securing and automating devices across Windows, macOS, iOS, Android, and Linux, including where Security Copilot and Graph API now fit into day-to-day admin work.