You have been offered a central AI team. The proposal names a responsible party with a formal mandate to govern agent behaviour across the enterprise. That names the governance accountability this kind of deployment requires. It makes the decision feel straightforward.
In Brief
- A central AI team that owns skill files places accountability for agent output quality in the team furthest from the output.
- A central AI team makes the same structural move Plan-Build-Run made: naming accountability without creating proximity to it.
- Gartner forecasts 150,000 agents per average Fortune 500 enterprise by 2028; only 13% of organisations have the right governance in place.
- Skill files maintained by the Developers who govern each agent team keep quality accountability where the evidence is.
- An independent governance design review shows whether a central AI team proposal resolves the accountability constraint or reinstates it.
The proposal is structurally identical to Plan-Build-Run. That governance model separated the people who built systems from the people who ran them on the premise that specialist ownership would produce higher quality outcomes. Plan-Build-Run named accountability and could not create it, because accountability for output quality requires proximity to the output. A team whose function is to review skill files for other teams’ agents does not have that proximity.
By 2028, the average Fortune 500 enterprise will have more than 150,000 agents in use, and only 13% of organisations believe they have the right governance in place (Gartner, 2026). The central AI team proposal has already been offered at much smaller scale.
Central AI team creates a bottleneck
Plan-Build-Run separated the people who built systems from the people who ran them on the premise that specialisation produces quality. What it produced instead was a handoff layer: work passed from Build to Run, each party accountable for their stage, neither accountable for the outcome that crossed the boundary. Plan-Build-Run named accountability without building the structure that makes it real.
A central AI team owning skill files makes the same structural move at the instruction layer. The Developer closest to each agent, the person who sees what the agent produces each Sprint and updates the governing instructions when a Sprint Retrospective finds a failure (Hodgson & West, 2026b, forthcoming), no longer controls those instructions. They submit a skill file change request to a team with no visibility into that agent’s daily behaviour and no stake in that Sprint’s outcome. Naming the central team as accountable does not create the proximity the accountability requires.
The central AI team does produce output: frameworks, approved skill files, governance documentation. That output is visible. The accountability failure surfaces when the constraint is already in place: quality for each agent’s output still requires a Developer who can observe that agent, update its governing instructions, and verify the change in the next Sprint. A team reviewing submitted skill files at batch scale cannot do that. They can confirm that a skill file meets a documented standard, but they cannot verify whether that standard fits the agent’s actual operating context in that Sprint. The Developer holds the evidence. Approval decisions sit with a team that cannot see it.
Approval checkpoints that do not sit at a genuine irreversibility threshold consume time and add queue length without improving what the team produces (Reinertsen, 2009). Skill file changes are reversible: a Developer can update a governing instruction the same day a Sprint Retrospective identifies the failure (Hodgson & West, 2026a). A central approval layer converts that same-day correction into a queue item. Lead time grows with queue utilisation (Reinertsen, 2009), and in a product area where agents are deployed continuously, the review queue will approach the limit.
The agents govern themselves by default
Accepting the central AI team proposal changes what the board can report about AI governance. It does not change where quality accountability for agent output actually sits. The Developer who governs an agent team will still find, in the Sprint Retrospective, that an agent has been producing inaccurate outputs. The governing instructions that produced those outputs will still need to be updated. That update requires the Developer who watched the agent work, not the central team, which reviewed the skill file three weeks earlier from a submitted document.
A skill file waiting in a review queue cannot be updated. The agent it governs continues operating on the last approved version. In a deployment adding agents continuously, agent behaviour diverges from governing instructions faster than the central team can review them. An enterprise approaching the scale Gartner forecasts, 150,000 agents per average Fortune 500 enterprise by 2028, will have a central review function whose queue grows faster than its capacity to clear it (Gartner, 2026). The agents at the back of that queue operate on instructions that were current when submitted and outdated by the time they are approved.
Adding headcount to the central team does not resolve the accountability between the team reviewing skill files and the Developer who can see what each agent is doing. Clear and routine work benefits from centralised standards (Snowden & Boone, 2007). Governing agent behaviour in a live product environment is not routine: it requires the local context and adaptation that only a Developer with proximity to the agent’s output can supply (Snowden & Boone, 2007). A central team applying routine governance processes to complex work will miss what it cannot see. The same structural failure appeared in financial institutions that centralised risk review: a committee reviewing end-of-day positions could not see what traders had already committed to during the day.
Accountability where the evidence is
The Developer is accountable for the quality of agent output (Schwaber & Sutherland, 2020). Each Developer maintains the skill files their own agents use, and a Sprint Retrospective that identifies a failure in a governing instruction produces a same-day update: a revised skill file improves every agent governed by that instruction in the next Sprint (Hodgson & West, 2026b, forthcoming). That correction happens the same day as the finding — no queue, no wait. A central review queue makes it take weeks.
Each Developer who adds agents to their team extends the governance without requiring the central review function to expand. The Developers and Scrum Masters applying this model at the team level will find the structural argument and practical guidance in the accompanying practitioner post on distributed agent governance.
The governance design question is not who is accountable for AI: it is whether the accountable party has proximity to the evidence they are accountable for reading. An independent governance design review from Zen Ex Machina, examining whether the proposed accountability structure sits where the evidence of agent behaviour surfaces, answers that question before the design is in place.
References
- Gartner. (2026, April 28). Gartner identifies six steps to manage AI agent sprawl. Gartner, Inc. https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl
- Hodgson, M., & West, D. (2026a). Failure modes for agentic systems: What goes wrong, and where human judgment belongs (Empiricism at Machine Speed, Paper 4). Scrum.org.
- Hodgson, M., & West, D. (2026b). The Agentic Nexus: What happens to Scrum when every team member governs agents (Empiricism at Machine Speed, Paper 5). Scrum.org. (Forthcoming)
- Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas Publishing.
- Schwaber, K., & Sutherland, J. (2020). The Scrum guide: The definitive guide to Scrum: The rules of the game. Scrum.org. https://scrumguides.org
- Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 85(11), 68–76.
