AI PMO: Delivery Governance Run by Agents

Status: built and running internally. Used on our own work, not offered as a product, not available to customers, and not a demo you can request. What follows includes what it cannot do.

What we built#

An internal organisation of AI agents with a real hierarchy — governance, executive roles, departments and project teams — where a request from a human is decomposed into tasks and routed to the agent whose role owns that work. Project work is forced through project-manager roles rather than going directly to whoever seems relevant.

The organisation is generated from a single structural definition rather than hardcoded: the build refuses to write when it finds a duplicate identity or a unit with no parent. That constraint matters more than it sounds. An org chart maintained by hand drifts within weeks, and an agent system built on a drifted chart routes work to roles that no longer exist.

At the time of writing it holds 191 organisational units with 190 role dossiers, and has produced 16 substantial deliverables on real internal questions.

What it actually produced#

The deliverables are the honest measure, and they are real documents on real questions — commercial packaging, payment rails, a regulatory boundary review, an evidence standard for one of our own engines. Several were genuinely useful and shaped decisions.

The pattern that emerged: agents are good at producing a structured, comprehensive first pass on a question where the reasoning is the deliverable. They are much weaker where the answer depends on facts only the business holds, and they will produce a confident, well-organised document either way. That is the risk this kind of system carries — the output looks identical whether it is grounded or not.

What broke, and what we changed#

Routing had to be enforced in code, not instructions. Told to route project work through project managers, agents would sometimes go direct. Making the routing structural — the path exists or it does not — ended the problem. This is the same lesson as agent spend caps: a constraint an agent can reason past is not a constraint. See AI agents.

Untrained roles had to be blocked from receiving work. An agent with no role dossier will still answer. It answers generically, which is worse than refusing, because the output is indistinguishable in shape from a good one.

Shared knowledge had to be shared, not copied. Every agent needs the same organisational context. Injecting it once from a common source, rather than baking it into each role, means an update reaches everyone — and it is the difference between an organisation that can learn and one that has 190 diverging copies of a fact.

The limits we will not talk around#

Depth of role knowledge is uneven. A substantial portion of the role dossiers were generated in an early run and are noticeably thinner than the later ones. They are marked as such internally. An organisation whose roles vary in depth produces work that varies in depth, and the variation is not visible in the output.

Grounding is the unsolved part. Where role knowledge came from a model's internalised knowledge rather than verified research, it is bounded by that model's training and is not fact-checked against anything current. We record that status per role rather than presenting all dossiers as equal. Any claim of "researched" would be false.

It has never been run against a customer commitment. Everything above concerns our own internal questions, where being wrong costs us a rewrite. Delivery governance for a customer project has consequences this system has never faced, and we would not claim otherwise.

It does not replace a PMO. It produces the documents and routes the work. Judgement about which risk actually matters, which stakeholder is quietly unhappy, and when to tell a sponsor something they do not want to hear — none of that is in scope, and the interesting question is whether it ever should be.

What we would need before calling it more than an experiment#

• Every role dossier at consistent depth, with grounding verified rather than assumed
• A measured comparison against work produced without it, on the same questions
• Behaviour under a real deadline, with a real dependency failing
• A record of where it was wrong, not only where it was useful

The fourth is the one most likely to be skipped, and the one that would tell us the most.

What transfers to anyone trying this#

Generate the structure; do not maintain it. A hand-maintained agent hierarchy is stale within a month.

Enforce routing structurally. Instructions describing a process are followed most of the time, which is the worst reliability level available.

Share context centrally. Otherwise every fix has to be applied in as many places as you have agents.

Record what each agent's knowledge is based on. Without provenance, you cannot tell a researched answer from a fluent one — and neither can the reader.

FAQ#

Can we buy this or see a demo?#

No. It is internal, it is an experiment, and nothing about it is packaged for anyone else. This page exists because publishing what we tried is more useful than publishing a product page for something that is not a product.

Does it run the company?#

No. It produces work on request and routes it. Decisions are made by people. The human owner is never one of the agents, which is a structural rule rather than a preference.

How many agents is the right number?#

We do not know, and 191 units is almost certainly more than the work requires — it mirrors an organisational design rather than a measured need. A smaller set with deeper role knowledge would plausibly outperform it. That is a real open question, not modesty.

What does it cost to run?#

The meaningful cost is model usage, which scales with how much work you push through it rather than with how many roles exist. Idle roles cost nothing, which is also why it is easy to end up with too many.

Would this work for delivery governance in a real project?#

Unproven. It produces the artefacts competently — charters, plans, requirement documents. Whether the governance judgement holds up when a project is going wrong is exactly what has not been tested, and it is the part that matters.

Is this what "agentic AI" means?#

It is one shape of it: many narrow roles with a routing layer, rather than one agent with many tools. The trade-off is real — hand-offs lose context, and a single well-equipped agent is often better. We would not claim the multi-agent shape is superior; we built it to find out.

What was the most surprising result?#

That the failure mode is confidence rather than incapacity. The system rarely produces obviously bad work. It produces plausible work at uniform quality regardless of whether it had the facts, which puts the entire burden of detection on the reader.

Related Articles#

See AI agents for the engineering discipline underneath, the AI Company Framework for the published operating model, and the PMO Knowledge Center for the delivery practices this experiment automates.

What else is coming for AI PMO