There is a conversation happening in platform engineering right now that sounds like it’s about AI, but is actually about something much older.
I see teams across every vertical are asking some version of the same question: how much do we trust the agent?
The question feels new, but the anxiety underneath that drives it is long-lived.
When a senior engineer reviews a junior developer’s PR, they aren’t just running a deterministic compliance check and checking a box; they’re applying years of contextual knowledge (about the codebase, the team’s standards, the risk appetite of the org, the unwritten rules about what counts as “good enough” in production) in a matter of minutes. That judgment is so embedded it’s nearly invisible - nobody wrote it down, because nobody needed to. The engineer was the institution of trust, and their digital signature at the bottom of the review was the proxy for an entire cultural value system.
In pretty much every organization I’ve worked with, agents don’t have access to that. What they do have access to, though, is whatever you’ve made explicit . If you haven’t started your Agentic Development Platform yet, that “explicitness” factor is probably less than you think.
What “trust in AI” is actually asking for
The approach I keep hearing about from students and the orgs I work with directly is about earning trust over time: start with low-stakes tasks, see how the agent performs, and gradually expand its responsibilities. There’s nothing wrong with that as a phased approach, but in my experience, it tends to place the trust problem on the agent when the trust problem is actually localized around the platform.
Agents and agentic systems don’t become more trustworthy through exposure, though. They become more useful as the system around them gets better at telling them what “done” means, and better at catching the delta between their output and what your org actually needs.
I’m watching people run all over the place, trying to reinvent the wheel to solve this problem through the lens of designing better agents. But the reality is, this is a platform engineering problem, and it's already been solved.
Think of it this way: The evaluation infrastructure that catches an agent’s drift from expectations, definitions of done that every path must now converge on, and policy-as-code that encodes what your security team would have approved in a 45-minute manual review…none of that exists by default. Someone has to build it. The only team positioned to do that work in the modern enterprise engineering org is the platform team, because they are the ones who understand both the technical substrate and the organizational context well enough to translate concepts between them.
This is what I mean when I say integrating agents is fundamentally a human problem. Every architectural decision about how an agent operates is actually a decision about how humans work: Agent identity is a question about human accountability, and evaluation infrastructure is a question about what humans consider acceptable. The hybrid path pattern ( the probabilistic step followed by a deterministic gate, retried until convergence) is a question about human tolerance for uncertainty. This means that whether they realize it or not, the platform team is doing human behavior design when it decides how agents behave, even if most of them aren’t thinking of it or framing it that way.
The definition of done has always lived in someone’s head
This is what the introduction of agents makes uncomfortably undeniable, even though it was always true: your organization has been carrying a definition of “done” in the heads of senior engineers, and nobody’s written it down because it was never necessary in the first place.
The PR workflow worked because there was a human at the end of it who knew the rules and could apply non-deterministic contextual judgment when the rules ran out. Deployment worked because the on-call engineer could read a threshold dashboard and decide whether “good enough” meant something different at 2 AM on a Friday than it did on a Tuesday afternoon. Security reviews worked because someone in the organization had strong pattern-recognition skills and a vague enough sense of unease to spot the exception the policy document had forgotten to cover.
Agents can’t do any of that without explicit instruction. It's not because they’re less capable than senior engineers in a generalized sense (more on my thoughts on this coming in the future), but mainly because the social trust that humans used to navigate ambiguity isn’t accessible or understandable to a non-human actor. Agents need the implicit to become explicit, in their language, at scale - not implied cultural practice. They just don’t work that way.
The platform team is the only team that can do this work. This isn’t because they’re the smartest in the room , so much as it’s because they’re the ones who talk to everyone. They see the security team’s constraints, the developer team’s workarounds, and the exec team’s risk tolerance. They are, whether or not they’ve been asked to be, the organization’s anthropologists. Anthropology is exactly what this moment in the latest technical revolution towards Agentic Development requires: the careful observation of how work actually happens, followed by the difficult task of writing it all down.
The golden cage problem
In a recent online class I ran on AI and platform engineering, a student resurfaced a well-established anti-pattern in the PE space: the golden cage.
The starting point for most platform teams is a well-constructed constraint environment, instead of full agent autonomy. You know what the agent is allowed to do and where the guardrails are. You’ve made the definition of done explicit for that specific path. The idea is that within that bounded environment, the agent is remarkably productive.
The trap, then, is treating the cage as the destination rather than the foundation. Teams that build the cage and stop there are doing controlled automation, not true agentic development. The path toward real autonomy ( where the agent can retrieve context, implement change, validate that change against your actual standards, deploy, and remediate when something goes wrong ) requires incrementally expanding what’s explicit, not incrementally expanding the cage.
This means that the Agentic Software Development Lifecycle (ASDLC) only scales if the platform expands ahead of it. We’ve recently been doing a lot of talking about the ASDLC - you can view my PlatformCon26 talk here that goes through this in detail. It comes down to this: the evaluation infrastructure must exist before you grant the next level of autonomy, and the definition of done must be written before the hybrid loop has anything to optimize against. Start small, build explicitly, then scale deliberately . At every step, remember that what you’re really doing is translating pieces of organizational knowledge from the head of a senior engineer into something codified that a non-human actor can act on.
A social contract is being renegotiated without a conversation
Since the earliest days of platform engineering, the platform has always been far more than just a technical substrate: Every gate is a value judgment, default configurations encode assumptions about what matters and what doesn’t, and golden paths tell developers which way of working is OK and which isn’t. When you introduce agents into that system, you are renegotiating the platform’s social contract with your organization . In most cases, I’m coming across renegotiation happening without anyone realizing what’s going on or pointing it out.
The governance surface expands, which means accountability questions change. Where the platform team used to build a system that provisioned resources for human developers who carried their own judgment, they’re now provisioning identity, context, and capability for non-human actors who carry only what has been made available to them. The same governance ownership applies ; the stewardship of it hasn’t changed, just the subject. At the end of the day, the platform team still owns it.
So, what’s different? The stakes: When a human developer makes a mistake, there’s a PR, a review, and a trail of context. When an agent operating with a high level of autonomy (running multiple sub-agents in parallel, validating outputs against standards, and/or deploying without human sign-off ) makes a mistake, the question of accountability shifts from social to architectural. Who is that dastardly agent? What was it prompted to do? By whose definition of done was this considered acceptable?
Those are questions the platform team has to answer before the agents are running, not after.
What platform engineers are actually being asked to do
The work of integrating agents isn’t primarily an AI literacy problem, and it isn’t primarily a tooling one either. Instead, I think of it more like an excavation problem.
Whether or not you realize it, your organization has always had a definition of done. Its always had an intrinsic risk appetite, set of standards, and collection of implied and hand-shaky agreements about what “good enough” means. None of that was written down, because it didn’t need to be : humans were inside in every workflow and process, and they could be trusted (theoretically) to apply that knowledge in context and in situ.
.png)
The Agentic Development Platform forces all of that to become explicit and documented, not so much because agents are demanding transparency, but because the system can’t function without it: A hybrid loop that combines deterministic and non-deterministic paths? It has nothing to converge on without a written definition. Evaluation infrastructure has nothing to measure against without explicit criteria, and security gates can’t be substituted in for a manual review unless you’ve already encoded what that review was checking for.
Platform teams that understand this are doing something that looks like therapy and acts like archaeology: surfacing the assumptions the organization never knew it was carrying, making them legible, and codifying them into something versionable and traceable.
This is harder than building an internal developer portal and slapping together some metric dashboards, and it’s significantly harder than writing a Terraform standards library. This requires an incredible level of organizational literacy, as well as empathy and people skills ; all muscles that most platform teams haven’t really needed to develop beyond the basic fundamentals.
Given this fast-moving timeline, this is the reality of the platform team’s current work, and no one else in the organization is positioned to do it. If you get this right? The platform team is now the most strategically important team in the AI initiative.
If you want to learn more about getting there, check out this free intro course on Agentic Development Platforms.
