Based on the LeadDev panel discussion "Governance Is the Platform Problem Worth Solving," hosted in partnership with Harness, August 5, 2026.
AI agents are no longer waiting for a human to approve their next move. They open pull requests, adjust configurations, and act on behalf of the people who deployed them — often faster than any review cycle can keep up. That single fact was the starting point for a recent LeadDev panel, "Governance Is the Platform Problem Worth Solving," where engineering leaders from Yelp, Platformable, and Harness argued that the old model of governance — a policy document someone reads after an incident — no longer holds up.
A policy document isn't governance anymore
Every engineering organization is now working through the same question: how do you automate governance, and where should it live? Centralized with CTO buy-in? Federated through team-level style guides? Owned outright by an enablement or platform team? There isn't a single right answer yet, but the panel agreed on one thing — governance has to be automated and enforced continuously, not documented and hoped for.
Agents need their own controls, not just human ones
Governance built for human contributors doesn't map cleanly onto agents. Panelists described teams having to stand up controls that didn't previously exist:
- Audit trails that capture what both humans and agents changed, not just commit history
- Access controls between agents, not only between agents and humans
- Role-based access and data controls for information moving between agents, since agents now read and write on each other's behalf
On the build side, the panel pointed to concrete starting moves: mandate experiment tracking for anything agent-related, build a golden test set to evaluate against, log prediction latency and volume as a baseline monitoring signal, and make sure there's a rollback path to a prior model or agent version.
Observability and deployment ownership are shifting
Platform and AI teams are moving from watching dashboards to deciding what they want agents to do on their behalf — and baking observability into the pipeline itself instead of bolting it on afterward. Several teams described effectively bootstrapping a "deployment babysitter" function, candidly admitting they can't fully predict how an agent-driven change will behave once it reaches production. It raises a question every platform team is now sitting with: is incident response for AI-driven changes a different discipline, or the same discipline applied to a new kind of actor?
The platform is where guardrails actually get enforced
The internal developer platform came up repeatedly as the practical place to put guardrails: access control policies, authentication and authorization, and clear rules for who or what an agent is allowed to impersonate and act on behalf of. Governance that isn't expressed in the platform layer tends to stay theoretical — a slide in a deck rather than a control that actually fires.
Governance is a business conversation, not just an engineering one
Two points tied the discussion together. First, governance buy-in doesn't stop at engineering. Security, legal, and finance all need a seat at the table before agents get broad access. Second, governance metrics only matter if they translate into business metrics leadership already tracks, like churn rate. As one panelist put it: you can't improve what you don't measure, and you can't budget for what you can't improve.
Where this leaves platform teams
The panel's throughline is simple to state and hard to execute: AI generates the code and takes the actions, and it's the platform's job to govern the consequences. That means audit trails that include agents, access controls between agents, and Policy as Code enforced in the pipeline — not a review meeting after the fact. Teams that treat this as a platform investment now will be the ones with an answer ready the next time security, legal, or finance asks who's watching what the agents are doing.
