What BCG's report shows
In How CIOs Can Govern Agentic AI at Scale, BCG describes a shift that traditional software governance was not built for. Two dynamics drive it: business-led agent sprawl, where experiments multiply into thousands of ungoverned agents, and an engineering productivity paradox, where AI-assisted development raises output while piling on technical debt.
Their projected scale is the part worth sitting with. In a 2028 scenario, a typical enterprise with 300 to 400 core processes and up to 1,300 subprocesses could see each subprocess underpinned by five to seven agents, producing over 100,000 new technology assets. BCG's answer is a new backbone on four pillars: GenAI platform services, AI graduation pathways, continuous refactoring, and ITSM adapted for an Agent Development Life Cycle (ADLC). The report's own phrase for the enforcement model is telling: guardrails-as-code with runtime enforcement, applied at machine speed.
BCG is describing an organizational operating model. It is right about the scale and the direction. The four pillars govern how the enterprise runs agents. They do not specify how a single agent stays architecturally correct as it writes code.
Why traditional governance starts too late
Most governance discussion still lives at deployment: identity, permissions, monitoring, observability, runtime controls. By the time those apply, the code already exists. The agent has already chosen a database, introduced a dependency, and settled a boundary. Runtime governance can observe that a decision was made. It cannot un-make it.
BCG's ADLC pushes governance earlier, toward continuous checks wherever an agent acts. That is the right direction. The earliest possible point, though, is before generation, when architectural decisions become executable constraints the agent must consult first.
The missing layer: architectural intent
Only about 15% of companies, by BCG's count, have the enterprise backbone in place today, and the gap closes more slowly than agentic adoption grows. Closing it requires a layer the four pillars assume but do not build: architectural intent made executable.
Concretely, this is the set of decisions that define how a system is meant to be built. Architecture decision records. Approved and forbidden patterns. Dependency policy. Repository boundaries. Engineering standards. Runtime governance asks whether a deployed agent behaves safely. Architectural governance asks a different question: does this change comply with how this system is designed, before it lands?
Two complementary layers
| Layer | Question it answers | When it acts |
|---|---|---|
| Runtime governance | Is the deployed agent behaving safely? | After deployment |
| Architectural governance | Does this change follow our decisions? | Before code is written |
These are not competing. BCG's platform services, graduation pathways, and ADLC give the enterprise its control fabric. Architectural intent is what makes that fabric enforce engineering decisions rather than only cataloging agents.
Why this matters at the scale BCG describes
Without executable architectural intent, every coding agent makes its own assumptions. At 100,000 assets, those assumptions do not average out. They compound. Architectural drift accumulates, code review becomes the enforcement mechanism of last resort, and teams spend their productivity gains fixing inconsistency that a constraint could have prevented. The pillars scale the organization. Architectural intent is what keeps the software it produces coherent.
What teams should do
- Compile decisions into constraints. Turn ADRs and standards into machine-evaluable rules that run before generation, not documents that agents may or may not read.
- Enforce independently of the agent. The same constraints should apply across every coding tool the enterprise adopts, so governance is not tied to one vendor.
- Treat architecture as part of the ADLC. Add a pre-generation check to BCG's lifecycle, so governance begins the moment an agent proposes its first line.
As the Agent Development Life Cycle matures, governance will not begin at deployment. It will begin the moment an agent proposes a change.