The Diamond Model Needs a Control Plane

In The End of the Consulting Pyramid I described the shape that replaces the pyramid: a Diamond built around expert judgment supported by machine systems. The shape answers the staffing question. It does not answer the operating question. A new shape without new controls does not produce better delivery. It produces faster production and more hidden risk. What the Diamond needs, and does not yet have, is a control plane.

In that essay I argued that AI does not make the pyramid more efficient. It puts the pyramid under structural pressure it was never designed to absorb, and what emerges on the other side is a different shape: a Diamond. A narrow point of client trust at the top. A layer of delivery orchestration beneath it. A wide center of domain experts who frame problems, challenge assumptions, and design solutions. And where the analyst base used to sit, AI systems performing the research, synthesis, and drafting under expert direction. That essay made the case for the shape. This one is about the part the shape does not solve.

Because a shape is not an operating model. The Diamond answers a staffing question: who, and what, performs the work now that analysis is cheap. It does not answer the operating question: how that work is governed so the output can be trusted. Those are different problems, and the second one is harder. A firm can adopt the Diamond on an org chart in an afternoon. Making it deliver safely and repeatably is the work of building something underneath it.

This matters because the failure mode is quiet. When you replace ten analysts with three experts and a set of AI systems, the deliverables still look right. The decks are clean, the analysis is fluent, the turnaround is faster than the client has ever seen. What is missing is not visible on the page. It is the assurance that the work was bounded correctly, drew on the right context, can be supported by evidence, and was reviewed where a human needed to review it. Speed without those controls is not progress. It is risk moving faster than anyone is watching. In the high-stakes environments I have worked in, the question is rarely whether a system can produce output. It is whether the organization can explain, defend, and govern the path that produced it.

Shape is not enough

Consider what actually changed when the analyst base became a machine layer. In the pyramid, control was implicit and human. A junior consultant produced analysis; a manager checked it; a partner owned the client relationship and would not put their name on work they did not believe. Authority, review, and accountability were carried by the reporting line itself. The structure did the governing without anyone naming it as governance.

Remove the human base and that implicit control disappears with it. A machine system does not absorb a manager's judgment by working alongside one. It does not know the boundary of its authority unless the boundary is stated. It does not show its reasoning unless the system is built to demand it. It does not escalate when it is out of its depth, because it does not feel out of its depth. Everything the reporting line used to supply has to be rebuilt deliberately, as explicit mechanism, or it is simply gone. That is why smaller teams plus AI tools do not automatically produce better delivery. They produce faster production, and unless something replaces the control the pyramid used to carry, they produce more hidden risk along with it.

The four functions of the control plane

A control plane is the layer that governs delegated work: what may be done, on what basis, and with what proof. For AI-native advisory delivery it has four functions, and they map directly onto the questions the old reporting line used to answer without being asked.

Delegation: who or what is authorized to do which work. Every unit of work in an engagement should have an explicit answer to the question of who may perform it, a person, an AI system, or a system operating only under a named human's authority, and where the limits of that authority sit. Delegation without stated bounds is not delegation. It is abdication.

Context: what information the work is allowed to use. A machine system will use whatever it is given. The control plane governs what it is given: which client data, which prior work, which sources are in scope for a given task, and which are not. Context is a control surface, because the wrong context produces confident, well-formatted, wrong answers.

Evidence: what must be shown to support a conclusion. In the pyramid, a partner could ask an analyst to show the work. The control plane makes that requirement structural: a conclusion that reaches a client should carry its basis, the sources, the reasoning, the assumptions, so it can be reviewed and defended rather than merely asserted. This is the same discipline I argued for in The Prompt Is Not the Product. Output quality is determined by context and verification, not by the fluency of the request.

Review: where human judgment must be applied. Not every step needs a human, and pretending otherwise recreates the bottleneck the Diamond was meant to remove. The control plane names the points where review is mandatory, where the stakes, the ambiguity, or the consequence require an accountable person to decide, and lets the rest flow. Review is a placement problem, not a volume problem.

The Diamond is the shape. The control plane is what makes it safe, repeatable, and trustworthy.

This is not project management

It would be easy to hear all this as delivery management with new vocabulary, and to conclude that a good engagement manager and a project plan already cover it. They do not. Project management coordinates who does what by when. It sequences tasks, tracks status, and manages timelines. It assumes the people doing the work carry their own judgment and accountability, which in the pyramid they did.

A control plane governs something project management takes for granted: whether the actor doing a piece of work is authorized to do it, whether it used the right information, whether its conclusion is supported, and whether a human stood behind the decision. When some of those actors are machines, those are no longer safe assumptions. Delivery orchestration in the Diamond is therefore not scheduling. It is governance over delegated human-machine work. The delivery lead is not moving cards across a board. They are running the control plane.

The advisory firm as early signal

There is a reason to care about this beyond consulting. Advisory firms are simply experiencing first what every enterprise is about to experience: the need to coordinate people, AI systems, context, evidence, and decisions inside work that carries real consequence. Consulting arrives early because analysis and synthesis were among the first things AI learned to do well, so the machine layer showed up in professional services before it showed up in most operations. The firm is the preview, not the exception.

Which means the control plane is not a consulting artifact. It is the same problem, in miniature and ahead of schedule, that a bank, a hospital system, or a government agency will face when they start delegating real work to machine systems. The firms that build the control plane now are not just protecting their delivery. They are learning, in a bounded environment, the discipline that the rest of this series takes up at enterprise scale: how to govern delegated work through delegation, evidence, memory, and accountability. The Diamond is the shape. The control plane is what makes it safe, repeatable, and trustworthy, and the next essay starts where the plane's hardest function lives: in the judgment of the expert who governs the machine.