The Floor, Not the Ceiling

Deep Dive #6 in “The Agentic Enterprise” Series

The choice isn’t standardise OR customise. It’s both.

I’ve watched this cycle run in every organisation I’ve worked with, and the pattern doesn’t change. Inconsistency triggers centralisation. Standards are written, compliance mandated, templates distributed. Six months later, everyone’s finding workarounds. Then the pendulum swings back to autonomy. Eighteen months after that, the inconsistency crisis returns.

This isn’t a failure of implementation. It’s a failure of architecture.

The standardisation initiatives that fail treat the standard as a ceiling: “This is how it’s done. Don’t deviate.” The standard claims to anticipate every use case. Deviation is non-compliance. Local teams with legitimate needs the standard doesn’t cover face a choice: be non-compliant or be ineffective. They choose effective. Every time.

A floor standard says: “This is the baseline. If you need more, extend it.” It’s intentionally incomplete — handles the common case, provides extension points for everything else. Extension is the intended design, not non-compliance.

Software engineering solved this decades ago. Every package manager — npm, pip, Maven — provides a dependency with useful defaults and rich extension points. Your customisations survive upgrades because they live in your layer, not hacked into the library’s internals. Thirty billion npm downloads per week, each representing a team using a standard baseline and extending it for their needs. The pattern works at extraordinary scale.

Spotify’s “golden path” applied the same principle to engineering process: opinionated, recommended templates for common tasks — repository, CI/CD pipeline, monitoring, deployment — all pre-configured and working. Not mandatory. Just genuinely easier than the alternative. Most teams used it because it earned adoption through quality, not mandate.

The insight across all of these: centralise the interface, decentralise the implementation. Define the outcome the standard must guarantee. Let local teams own how they achieve it.

The failure mode is predictable. A central team writes a comprehensive standard. But they can’t anticipate all use cases — the organisation’s too complex, local contexts too varied, change too fast. The standard ships with gaps. Local teams hit the gaps immediately, can’t wait for central updates, and improvise. The central team responds with tighter controls. More mandatory fields. More compliance checks. The gap between standard and reality widens. More teams route around it. Enforcement escalates. Resentment escalates. The standard collapses.

Root cause: the initiative was designed to anticipate all use cases upfront. That’s structurally impossible. No consultation process, no steering committee, no design phase can overcome a fundamental epistemological limitation: you can’t know in advance what you can’t know in advance.

The two-tier architecture accepts this limitation. The standard covers what the central team knows well. Extension points cover what they can’t foresee. Good local extensions get absorbed into the standard. The system learns.

AI agents make the two-tier architecture not just preferable but necessary. They also make it dramatically more powerful.

AI agents are naturally configured for the floor standard. An agent executing a skill doesn’t need to understand every local variation across fifty teams. It needs to execute the standard default reliably and know which extension to invoke for which context. The floor standard becomes the agent’s operating system. The extensions become the local configuration layer.

What this looks like in practice:

Consider onboarding. The floor standard defines the interface contract: “A new employee can perform their core tasks independently within thirty days and knows who to contact for any question they can’t resolve themselves.” That’s the outcome. Measurable. Clear.

The AI layer executes the default implementation: scheduling orientation sessions, provisioning system access, assigning training modules, sending check-in prompts at day 7, 14, and 30. This handles 80% of cases without human intervention.

The extension layer handles local variation. The engineering team adds a codebase walkthrough and a paired programming session. The sales team adds CRM training and territory briefing. The legal team adds regulatory orientation. Each extension is owned by the local cell, plugs into the standard interface, and can evolve independently.

The four questions every standard must answer:

1. What’s the interface? What outcome must the standard guarantee, regardless of implementation? “New hires reach independence within thirty days” is an interface. “Complete these seven modules” is an implementation detail masquerading as one.

2. What’s the default implementation? What handles 80% of cases out of the box, requiring no configuration? That’s what the AI executes.

3. Where are the extension points? What are the legitimate ways local teams adapt? These must be explicit, documented, and supported — designed extension mechanisms, not workarounds.

4. How does local learning flow back? When a local adaptation is significantly better than the default, how does it get absorbed into the standard? Without this feedback loop, the standard decays while local adaptations improve.

The capability cell structure reinforces this naturally. Each cell operates with the organisational standard as its floor and owns its extensions. The portfolio manager monitors which extensions are emerging across cells and identifies candidates for absorption into the standard. The AI layer handles execution of both the standard and the extensions. Humans focus on designing better extensions and improving the standard itself.

Concrete organisational changes:

• Standard ownership shifts. The central team’s accountability metric becomes voluntary adoption rate, not compliance rate. If the standard requires enforcement, it isn’t good enough.

• Extension governance becomes lightweight. Local extensions that meet the interface contract need no approval. Extensions that modify the interface require coordination — but that’s a small fraction of adaptations.

• Version management becomes real. When the standard improves, cells update like upgrading a dependency. Their extensions survive because they use the extension points, not internal hacks.

• The AI layer provides automatic telemetry. Which extensions are used most? Where do exceptions cluster? Which cells consistently outperform the standard default? That data drives standard improvement at a pace no manual review process can match.

Organisations that build this architecture stop oscillating between centralisation and decentralisation. The pendulum exists precisely because neither pole solves the real problem.

Pure centralisation fails because local contexts are too varied. Pure decentralisation fails because common problems benefit from common approaches. The two-tier architecture isn’t a compromise between these poles. It’s a different axis entirely.

The standard provides the floor. The extensions provide the fit. The AI executes both. Humans design and improve both. Neither is the ceiling.

The choice was never standardise or customise. It was always both — with architecture that lets both coexist, and an AI layer that makes the floor standard operationally effortless.

Next in the series — Deep Dive #7: The Gate Nobody Likes — How to turn governance from a bottleneck into a capability that people actually want