What to Build, Buy, and Federate in an Enterprise AI Platform

Part 2 of 3 — AI Platform Budget Decisions

A platform team that owns domain semantics has confused control with competence. Domain authority belongs to the people who answer for domain errors.

Starting From the Right Question

If you have worked through Part 1 and confirmed that multiple squads have genuine workflow demand, you are now at the architecture decision. The instinct in most organizations is to build a comprehensive end-to-end platform. That instinct is almost always too broad.

The better question is not "What should the platform own?" but "What should the platform never own?"

What Should You Buy?

The infrastructure runtime layer is commoditized. Assigning senior engineers to write a custom model proxy gateway, token metering service, or latency routing engine is misallocated capital. These exist as production-grade open-source or SaaS products today.

Build where internal ownership creates durable domain, risk, or economic leverage that cannot be purchased from a market provider at lower cost and comparable quality. Buy where operational maturity is high and differentiation is low.

The Vendor Shelf Life Problem

The buy decision carries its own risk. The LLM observability and evaluation tooling market evolves fast. Tooling selected today may face deprecation, vendor consolidation, or functional obsolescence within twelve months. Deeply coupling application telemetry to a vendor's proprietary tracing format creates high switching costs when migrating production pipelines.

The mitigation is clean: mandate open standards at the platform integration boundary. Instrument all application code using OpenTelemetry GenAI semantic conventions rather than vendor-proprietary SDK wrappers. This treats the buy layer as an interchangeable utility backend, preserving vendor reversibility without requiring custom internal plumbing.

The Specialized Vendor Exception

Not every vendor is a commodity. A commercial provider with seven years of adjudicated domain data, HIPAA or ISO-27001 certifications, and task-specific evaluation suites that demonstrably outperform internal engineering is not a commodity buy. Maintaining an internal capability contract to preserve "strategic ownership" against that vendor is an expensive error.

Before greenlighting an internal build over a specialized vendor, answer two questions directly:

• Does the internal build create durable enterprise leverage through proprietary customer data and unique domain authority?
• Or does it introduce perpetual maintenance drag without delivering competitive differentiation?

How Should You Federate What You Build?

The structural choice product leaders face is not centralized platform vs. isolated squads. It is designing ownership across three distinct tiers so the central platform team never becomes a cognitive bottleneck on specialized domain logic:

This strict division of labor prevents the platform team from having to understand or approve changes to medical diagnostic formats or accounting line items—the single biggest reason squads bypass central platforms in production.

Staged Centralization: How Does an AI Platform Earn the Right to Expand?

The classic corporate mistake is Premature Centralization. A platform architect pitches leadership: "Let's immediately build a full enterprise AI platform with mission-critical SLAs, automated distillation, custom evaluation engines, and shared infrastructure for all ten squads."

The result is predictable: huge upfront spend, near-zero squad adoption, complaints about slow central intake queues, and a platform team that becomes an expensive organizational bottleneck.

To prevent this, centralization cannot be funded as a blank-check project. You do not get budget and mandate to build a heavier platform layer just because you have an architectural vision. Each stage must earn its right to advance through demonstrated production evidence and verified squad demand from the previous stage:

Advancement gates are not optional checkpoints. They exist because un-sharing a capability is never free.

What Does Reversal Actually Cost?

Decoupling consuming squads from a shared capability contract requires three friction-heavy steps per squad: stripping shared SDKs and unwinding centralized schema bindings, rebuilding prompt assembly and retry mechanics locally, and re-establishing standalone evaluation fixtures and regression baselines.

This refactoring costs two to four engineer-weeks per squad ($16k–$32k). Across four squads, reversing an unvalidated shared service runs $64k–$128k in deadweight friction. Because reversal cost is real and non-zero, promoting a capability from Stage 2 to Stage 3 creates an unpriced balance sheet liability unless reuse economics are proven first.

Is There Actually a Shared Capability?

Before advancing a capability from Stage 2 to Stage 3, product managers must defend the centralization decision against what the architecture literature calls the Reuse Trap.

The Reuse Trap occurs when squads appear to share a capability because they process similar data types with similar tooling—while actually solving structurally incompatible domain problems.

Consider a four-squad organization where every squad extracts fields from documents:

• Squad A (Invoices): Extracts financial line items where a single missing decimal point triggers an immediate reconciliation failure. Error tolerance is near zero; provenance requires cryptographic document coordinates.
• Squad B (Vendor Onboarding): Extracts business descriptions where approximate semantic matching is acceptable. Error tolerance is moderate; latency is flexible.
• Squad C (Patient Intake): Extracts medical histories under strict HIPAA de-identification rules, immutable audit logging, and data residency constraints.
• Squad D (Marketing Collateral): Extracts campaign tags where throughput and sub-second latency dominate, with zero compliance exposure.

Centralizing these four squads into a single "Document Intelligence Service" does not create leverage. It produces a platform choked with seventeen configuration flags, domain-specific exception branches, and conflicting evaluation harnesses. The team has rebuilt the monolith.

The Domain Engineer's Objection

A skeptical domain engineer will push back legitimately:

"You're assuming squads have fundamentally different needs just because their code looks different today. But squads only built custom setups because nobody gave them a shared standard to begin with. You can't tell if their needs are truly incompatible, or if they just reinvented the wheel in silos."

This objection identifies a real blind spot. Waiting for identical schemas to emerge organically will systematically undercount legitimate reuse opportunities.

The resolution: a 2-Week Convergence Spike. Before rejecting centralization, fund a time-boxed, two-week architectural spike between two adjacent squads—tasked with drafting a unified semantic schema and joint assertion suite.

• If 80% or more of the field schemas and validation rules merge without conditional branching, the divergence was artificial. Proceed with centralization.
• If merging requires domain-specific override flags for core validation and authority limits, the divergence is structural. Reject centralization. Keep capabilities local.

The Gated Centralization Assessment

A capability that fails any required gate cannot advance to a shared service.

Required gates (any failure blocks centralization):

Scored dimensions (three or more must demonstrate meaningful overlap):

What Comes Next

Clearing the architecture decision does not close the investment case. Once you know what to build, buy, and federate, you still need to prove that the economics justify the spend—against the right baseline, with phased cash flows, and with a kill rule that accounts for the patient capital AI platforms require.

That is the subject of Part 3.

→ Underwriting the Return on an AI Platform

One-Line Synthesis

The platform team owns the control plane. Domain pods own the contracts. Product squads own the workflow. Crossing those ownership lines is where platforms become bottlenecks.

Related Reading

• Before You Fund an AI Platform: Prove the Workflow First — Part 1: The capability sensitivity test and sequencing thresholds.
• Underwriting the Return on an AI Platform — Part 3: Phased cash flows, real-options logic, and the six failure modes.
• Policy-as-Code for Autonomous Agents — Implementing deterministic verification perimeters around probabilistic reasoning engines.
• EROI Is Not Enough: The Capital Return Trap of Generative AI — Why traditional return on investment metrics miss the systemic depreciation of generative software assets.

The ideas in this post are my own — they emerged from questions I asked while learning applied AI concepts and putting them to work in my job and my projects. The prose was developed with AI assistance.