The duplication that looks like autonomy

Software teams have always balanced local speed against shared infrastructure. AI makes the balance harder because the model is a small part of the operating system around it. Sculley and colleagues described the hidden technical debt created by data dependencies, glue code, configuration, undeclared consumers and changing external conditions in machine-learning systems.⁶ Microsoft’s study of teams building AI applications similarly found that data management, model customisation and modularity introduce engineering problems that ordinary application boundaries do not fully contain.⁷

Generative and agentic systems add prompts, retrieval corpora, tool schemas, policy bundles, memory rules and evaluator configurations to that moving state. If every journey assembles those pieces independently, duplication is only the visible cost. The deeper cost is divergent interpretation of obligations that the organisation expected to be common. Two teams can both claim to log a model call while recording different identifiers, retention periods and evidence. A vulnerability fix can be applied to one agent framework and missed in another. A model deprecation can become a portfolio-wide search rather than one governed route change.

A platform can compress that repeated work into a reusable service. The production-scale TFX account is an early concrete example: Google integrated data analysis, validation, training, model evaluation and serving into a common platform, reporting less custom code and a reduction in one deployment path from months to weeks.⁸ That result does not prove every organisation needs the same components. It shows the mechanism by which standardisation can remove fragile orchestration when many pipelines share the same operating burdens.

Thought experiment: one obligation, then one meaning

Imagine ten AI journeys that call the same two model providers. Tomorrow, a provider changes its authentication flow and retires one model version. Hold every business task constant. In the local design, ten teams discover the change, interpret it, update credentials, retest routing and produce ten release records. In the platform design, one gateway team updates a versioned route, runs a shared compatibility pack, canaries the change and publishes the result. The common obligation has one owner and one evidence path. Centralisation earns its cost.

Now change only one causal feature. A lending policy introduces a new exception for a specific product and customer condition. The platform team can supply policy versioning, effective-time fields, test execution and an approval record. It cannot decide the meaning of the exception, select the affected population or set the acceptable false-negative rate. If it absorbs those decisions, centralisation destroys information rather than removing repetition.

The two interventions identify the boundary. Centralise the obligation when consistency itself creates value. Keep the meaning local when correctness depends on situated knowledge and accountable judgement. A model gateway is common because model identity, quota, routing evidence and provider failure handling recur. A credit rule remains domain-owned because its semantics, exceptions and customer consequences belong to the lending process.

The serious negative control

Suppose a research team has one three-week experiment, synthetic data and no path to consequential use. It needs one model, a notebook and a disposable evaluator. There are no other consumers, no shared operational obligation and no durable state. Routing the experiment through a six-month platform onboarding process would make the preferred architecture look absurd because, here, it is absurd.

This negative control matters. It prevents “platform” from becoming a synonym for maturity. A local library, managed provider or short-lived scaffold may be the right mechanism when reuse is low, failure is contained and future support has not been promised. The platform case begins when repeated work, divergence or portfolio externality becomes material. The first use case does not justify a platform merely because a tenth use case is imaginable. It can, however, record what would need to repeat before shared investment becomes rational.

flowchart TD
  A["The fourth team asks for the<br/>same thing"] --> B["On this page"]
  B --> C["The duplication that looks<br/>like autonomy"]
  C --> D["Draw the coastline from<br/>obligations"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#5B5CF6,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Draw the coastline from obligations

Good modularity depends on the criterion used to divide the system. Parnas’s classic argument was that modules should hide design decisions likely to change rather than simply follow the visible steps of a process.¹ The same discipline applies to an internal AI platform. A team should not centralise “retrieval” as one block because several diagrams contain a retrieval box. It should identify which retrieval decisions can be hidden behind a durable contract and which decisions remain inseparable from a corpus, entitlement model and business claim.

Four forces pull a capability towards the platform. It recurs across independent journeys. Its interface can be standardised without erasing material distinctions. Inconsistent implementation creates security, reliability, cost or evidence externalities. Its specialist operation benefits from concentrated expertise. Three forces pull in the other direction. Correctness depends on local semantics. The capability is tightly coupled to a journey outcome and accountable operator. Its rules change at the pace of the domain rather than the platform.

Capability names are too coarse for this judgement. “Retrieval” contains at least corpus publication, entitlement checks, indexing, candidate generation, reranking, evidence packaging, freshness and claim-level use. Entitlement enforcement and a provenance envelope may be common obligations. Corpus authority, query intent, conflict handling and the sufficiency of evidence for a decision remain contextual. Drawing one box around retrieval either duplicates the common controls or centralises the meaning. The useful boundary often passes through a capability rather than around its name. The same split appears in evaluation, memory, workflow and tool use.

Three ownership modes, not a binary

A capability can be platform-owned, use-case-owned or federated. Platform ownership fits a stable common promise such as workload identity, an approved model route or a release manifest. Use-case ownership fits a policy, information set or human decision whose correctness is defined by one journey. Federation fits a reusable invariant completed by local meaning: the platform runs an evaluation harness while the journey supplies cases and thresholds; the platform records retrieval provenance while an information owner declares source authority and supersession. Federation is not vague joint ownership. The contract must name who operates the shared primitive, who supplies the local completion, who accepts residual risk and who can suspend the combined service.

Shared does not mean centrally implemented

A platform product may own the interface and user experience while delegating implementation to a cloud service, an internal security team or a domain provider. The CNCF Platforms White Paper makes this distinction explicitly: platform teams curate integrated capabilities and consistent experiences, but should not assume they must implement every underlying service.² The thinnest useful platform often consists of contracts, automation, documentation and support over capabilities supplied elsewhere.

This matters for AI because vendor products change quickly. A platform that hard-codes one model family, one agent framework or one vector database may centralise today’s choice rather than hide tomorrow’s change. A model-access contract can instead express capability, data class, latency range, budget and required evidence. The platform may fulfil that contract through several providers. Journey code depends on the organisational interface, while provider-specific controls remain visible in the platform’s implementation record.

The platform owns the invariant promise and the mechanics required to keep it. It does not own every component behind the promise. This is product work: discovering the user job, selecting the minimum interface, publishing guarantees, supporting failure and managing change. A portal without a maintained contract is a catalogue. A common library without support is a dependency. A platform product must survive users, incidents and upgrades.

Thought experiment: the same score, a different harm

Take one evaluation harness and two systems that both produce grounded drafts. The first summarises an internal meeting. The second drafts a customer communication about a declined credit application. Hold the model, prompt, retrieval stack and average factuality score constant. Change only the consequence and the user’s ability to contest the result.

The platform can run both test suites, preserve manifests, provide judge calibration, record slices and block release on declared gates. It cannot set one universal threshold from the shared score. The customer communication may require exact reason-code preservation, prohibited-claim tests, accessible language, review evidence and a defined correction route. The meeting summary may tolerate omissions that the regulated communication cannot.

The experiment separates evaluation infrastructure from evaluation authority. The harness belongs on the platform because execution, lineage and result structure repeat. The cases, rubric, thresholds and residual-risk decision remain with the journey, control function and accountable business owner. A central “quality score” that replaces these decisions would be a semantic capture disguised as reuse.

Build roads users choose

A platform can have excellent architecture and still fail as a product. It fails when teams cannot discover the right capability, provision it without a ticket, understand a denial, test locally, diagnose an incident or predict the effect of an upgrade. It also fails when its roadmap is a collection of central-team preferences rather than the unresolved jobs of its users.

The CNCF guidance treats platform teams as product teams that research user needs, manage interfaces, gather feedback and measure impact on product value streams.² Its maturity model distinguishes extrinsic push from intrinsic pull: at a scalable stage, teams choose the platform because it reduces cognitive load and supplies better supporting services, not merely because policy requires it.³ That distinction is especially useful for AI. A mandate can produce adoption statistics while teams keep shadow prompts, private gateways and unregistered evaluation scripts.

A paved road is the easiest supported route to an acceptable outcome, with visible guardrails and a governed exit. It is not a concrete wall. The road should make the normal case fast, explain why a request is denied, and let an exceptional use case propose an extension or take a reviewed alternative. Escape data then becomes product research. Repeated escapes may indicate a missing platform capability. One unusual escape may confirm that the platform should remain thin.

Start with one complete user journey

A minimum viable platform is not the smallest possible list of services. It is the smallest platform slice that makes one frequent user journey observably better from start to finish. “Call an approved model” may require model discovery, identity, data-class checks, a route, local test support, cost visibility, a usable error and a trace. Shipping only an API proxy leaves the user to assemble the rest, so the product has not completed the job.

Choose an initial partner team with a real deadline, a repeated problem and enough expertise to challenge the platform. Co-develop the paved road. Observe where the team leaves it, which errors require human interpretation and which controls still arrive as tickets. Publish the first service-level objectives around user-visible tasks, not merely component uptime. Google’s SRE guidance defines an SLO as a target for a measured service level; for an internal platform, the useful service level is often the completion of a user job such as provisioning, deploying, evaluating or rolling back.¹²

Examples could include the proportion of approved model-access requests completed without a ticket, the time from a candidate manifest to a reproducible evaluation result, or the percentage of release traces that satisfy the evidence contract. These are proposed indicators, not universal thresholds. Each organisation must set targets from demand, consequence and operating capacity.

Measure a portfolio of outcomes, not platform activity

DORA’s 2024 report associated internal developer platforms with higher individual, team and organisational performance, while also reporting possible reductions in change stability and throughput.⁴ Its current platform-engineering guidance stresses product management, developer independence, extensibility and clear task feedback.⁵ These are observational findings and practitioner guidance, not a guarantee that installing a portal causes performance.

The right response is measurement across several dimensions. The SPACE framework warns against reducing developer productivity to one metric.¹¹ An AI platform scorecard should therefore combine user experience, delivery, reliability, control and business-outcome evidence:

• User pull: active teams, retained use, repeat adoption, qualitative satisfaction and reasons for escape.
• Task completion: time to first acceptable vertical slice, self-service completion, time to diagnose and time to recover.
• Delivery: lead time for a governed change, release frequency by risk tier and change failure by capability.
• Control: evidence completeness, entitlement denials, unknown outcomes, stale dependencies and unresolved exceptions.
• Portfolio effect: duplicated components retired, common changes propagated, incidents contained and journey outcomes improved.

Token volume, API calls and registered projects are cost and capacity signals. They are not value by themselves. A platform can increase traffic while adding friction, or reduce traffic by replacing repeated model calls with deterministic services. Measure the user job and the accepted outcome, then use activity metrics to explain it.

Each metric also needs a denominator and a comparison. “Eighty per cent self-service” is weak evidence unless the eligible requests, excluded cases and prior route are visible. A faster evaluation run matters only if teams can reproduce it and if release defects do not rise. Adoption should therefore be paired with escape reasons, support demand and shadow implementations. The platform team is testing a causal claim: that this road reduces total effort and control variance without weakening the journey outcome. A baseline, a counter-metric and a review date keep that claim falsifiable.

Operate the boundary, not a catalogue

The platform product is a living set of promises. Every capability needs a user job, interface, owner, service level, change policy, support path and deprecation route. AI capabilities need additional fields because their behaviour depends on models, data and evaluation context. A useful contract states which provider or model changes are transparent, which trigger journey regression, what evidence the platform returns, which data classes are supported and what happens when the outcome is unknown.

Platform and domain contracts also change on different clocks. Provider deprecation, authentication, trace schemas and runtime defects may require an estate-wide response. Product policy, source authority and consequence thresholds may change independently and sometimes more quickly. A federated seam lets each owner publish an effective version without waiting for the other to absorb its meaning. The combined release manifest then records both versions and the compatibility evidence between them. Without this separation, a harmless platform upgrade can force unnecessary business recertification, while a domain change can be hidden inside an application release that the platform cannot interpret.

NIST’s AI Risk Management Framework is deliberately use-case agnostic and flexible across sectors.⁹ That makes it suitable as a common governance vocabulary, but it also marks a limit: contextual risk must still be mapped by the organisation and use case. The Generative AI Profile extends the framework with generative-AI considerations across design, development, use and evaluation.¹⁰ A platform can operationalise common evidence and control hooks. It cannot declare every downstream use trustworthy simply because the shared component passed its own tests.

A production-shaped example: three journeys, one platform seam

Consider three regulated journeys. A credit-memo assistant gathers evidence and drafts an argument for a reviewer. A KYC periodic-review system reconciles identity, documents and screening results. A complaints assistant retrieves current policy and prepares a proposed response. Each journey has different data, expertise, thresholds, human roles and customer consequences. They still share a substantial operating burden.

The platform supplies workload identity, approved model routes, a typed tool registry, a common evidence envelope, durable workflow primitives, evaluation execution, release manifests and incident correlation. The credit team owns financial calculations, lending policy, evidence sufficiency and the reviewer decision. The KYC team owns identity standards, source authority, exception states and disposition. The complaints team owns policy interpretation, remedy rules, communication quality and adviser workflow.

A model upgrade illustrates the contract. The platform qualifies candidate routes against common safety, schema, latency and provider-failure checks. It publishes a candidate route with a manifest. Each journey runs its own regression pack and compares task slices. The platform can block a route that violates an estate-wide control. It cannot approve the credit journey’s residual performance or waive a complaints-policy failure. Release requires both platform evidence and journey acceptance.

A shared incident follows the same structure. If the provider returns malformed tool arguments, the platform contains the route and coordinates failover. If the complaints corpus contains an obsolete policy, the information owner withdraws the source and the journey suspends affected outputs. If a reviewer queue is overwhelmed, operations narrows automation. Ownership follows the boundary that can diagnose and correct the failure. One central “AI support” queue would see the symptoms without holding the necessary authority.

The platform’s own failure modes

Centralisation creates correlated risk. A faulty local library can harm one journey; a faulty platform route or policy bundle can harm every consumer. The product therefore needs versioned contracts, progressive exposure, blast-radius partitions and a rapid withdrawal path. Software provenance standards such as SLSA show how a build platform can generate verifiable information about where, when and how an artefact was produced.¹³ AI release manifests need a broader system record, but the same principle applies: shared production should make lineage stronger, not more implicit.

Another failure is the central queue. When every extension needs the platform team, the road has become a toll booth. Extensibility should let security, data, domain and journey teams contribute capabilities through controlled interfaces. The platform team curates contracts and experience; it need not implement every adapter. Clear contribution tests, compatibility rules and named maintainers turn federation into an operating model rather than an informal exception.

A third failure is semantic laundering. A common component can give an unsupported decision the appearance of institutional approval. Model cards and dataset documentation were proposed precisely because suitability depends on intended use, evaluation conditions, data origin and limitations.¹⁵ High-stakes data research has also documented how neglected data work can create downstream “data cascades”.¹⁴ A platform can require those records and propagate their identifiers. It cannot manufacture missing domain knowledge.

Finally, a platform can become too broad to understand. Every additional abstraction carries support, compatibility and incident cost. The right response is not endless platform growth. It is periodic deletion, delegation and boundary review. Capabilities with one remaining user may return to the journey. Stable domain services may be registered rather than absorbed. Vendor features may replace custom implementations while the platform retains the organisational contract.

The ownership decision instrument

Use the following card before funding or absorbing a platform capability. The aim is to expose the reason for ownership, the user job and the seam. A capability should not enter the platform because a senior architect drew it inside a large box.

The answers should produce an ownership choice: platform, use case, local library or federated contract. “Shared responsibility” is not a choice unless the seam names the decision owner on each side. For a federated capability, write two acceptance statements. One states what the platform proves. The other states what the journey must still prove before release.

stateDiagram-v2
  [*] --> Claim
  state "Thought experiment: one<br/>obligation, then one meaning" as Claim
  state "The serious negative control" as Test
  state "Three ownership modes, not a<br/>binary" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

The executable ownership lab

The companion Python artefact turns the ownership discussion into an inspectable hypothesis. It scores seven declared properties from zero to five, compares platform pull with domain pull, applies one negative-control rule and reports sensitivity. The score is deliberately modest: it cannot decide accountability, and it refuses to disguise close cases as precision.

Save the code as platform_ownership_lab.py and run it with Python 3.10 or later. It uses only the standard library. The positive case assigns a model gateway to the platform. The negative case keeps a one-off demo adapter local. Federated cases retain both central and domain obligations.

"""Ownership lab for 'The AI Platform as a Product'.

Synthetic decision aid. Scores are prompts for an architecture review,
not measurements and not a transfer of accountability.
Python 3.10+. No third-party dependencies.
"""

from __future__ import annotations

from dataclasses import asdict, dataclass
import json
from typing import Literal

Decision = Literal["platform", "federated", "use_case", "local_library"]


@dataclass(frozen=True)
class Capability:
    name: str
    reuse: int
    standardisability: int
    cross_team_externality: int
    evidence_commonality: int
    domain_semantics: int
    outcome_coupling: int
    local_change_rate: int

    def validate(self) -> None:
        for field, value in asdict(self).items():
            if field == "name":
                continue
            if not isinstance(value, int) or not 0 <= value <= 5:
                raise ValueError(f"{field} must be an integer from 0 to 5")


def classify(capability: Capability) -> dict[str, object]:
    capability.validate()

    platform_pull = (
        capability.reuse
        + capability.standardisability
        + capability.cross_team_externality
        + capability.evidence_commonality
    )
    domain_pull = (
        capability.domain_semantics
        + capability.outcome_coupling
        + capability.local_change_rate
    )

    # Negative control: a disposable, isolated capability should not be
    # promoted into a platform merely because its interface is tidy.
    if capability.reuse <= 1 and capability.cross_team_externality <= 1:
        decision: Decision = "local_library"
        reason = "Low reuse and contained failure do not justify a product surface."
    elif platform_pull >= 14 and domain_pull <= 7:
        decision = "platform"
        reason = "Common obligation dominates and can be expressed with low semantic loss."
    elif platform_pull >= 11 and domain_pull >= 9:
        decision = "federated"
        reason = "The invariant is reusable, but domain meaning must complete the contract."
    elif domain_pull >= platform_pull + 3:
        decision = "use_case"
        reason = "Outcome and semantics dominate the ownership decision."
    else:
        decision = "federated"
        reason = "The case is close; split the invariant from the domain completion."

    return {
        "name": capability.name,
        "platform_pull": platform_pull,
        "domain_pull": domain_pull,
        "decision": decision,
        "reason": reason,
    }


def one_step_sensitive(capability: Capability) -> bool:
    """Return True when changing any one score by one changes the decision."""
    baseline = classify(capability)["decision"]
    values = asdict(capability)
    for field, value in values.items():
        if field == "name":
            continue
        for delta in (-1, 1):
            changed = value + delta
            if 0 <= changed <= 5:
                candidate = Capability(**{**values, field: changed})
                if classify(candidate)["decision"] != baseline:
                    return True
    return False


CASES = [
    Capability("model_gateway", 5, 5, 5, 5, 1, 2, 2),
    Capability("task_evaluation", 5, 3, 4, 4, 5, 5, 4),
    Capability("retrieval_provenance", 5, 4, 5, 5, 4, 4, 4),
    Capability("credit_approval_policy", 2, 2, 3, 2, 5, 5, 5),
    Capability("one_off_demo_adapter", 1, 4, 1, 1, 2, 1, 4),
]


def main() -> None:
    results = []
    for case in CASES:
        result = classify(case)
        result["one_step_sensitive"] = one_step_sensitive(case)
        results.append(result)

    assert results[0]["decision"] == "platform"       # positive case
    assert results[1]["decision"] == "federated"
    assert results[3]["decision"] == "use_case"
    assert results[4]["decision"] == "local_library"  # negative control

    print(json.dumps(results, indent=2))


if __name__ == "__main__":
    main()

The lab’s most useful output is often the sensitivity flag. A one-step-sensitive capability sits near a boundary, so the architecture record should identify the uncertain assumption and schedule a review after real usage. A score that remains stable under small changes is still not a proof, but it exposes why the current ownership choice is robust enough to try.

Centralise the obligation, leave the outcome owned

The case for an AI platform is not that every team uses models, retrieval or agents. The case is that several teams repeatedly face obligations whose inconsistent implementation creates avoidable cost and portfolio risk. A platform turns those obligations into supported contracts: identity, routing, evidence, release, recovery and other common mechanics become easier to consume correctly than to recreate.

That leverage disappears when the platform absorbs the meaning it cannot know. Domain data, policy interpretation, task tests, consequence thresholds, human operations and accountable outcomes stay with the journey and its control owners. Many valuable capabilities therefore have a federated seam: the platform proves the invariant; the journey proves fitness for purpose.

The changed architecture decision is to draw the platform boundary from repeated obligations and user jobs, then earn expansion through evidence. Begin with one complete paved road. Publish the contract and the local completion. Measure task success, reliability, control and user pull. Preserve an escape path. Expand only when another journey can reuse the obligation without surrendering information or accountability.

Every boundary is provisional. Review it when a shared incident reveals excessive blast radius, when escape requests cluster around the same missing job, when a domain service stabilises enough to expose a reusable contract, or when a platform capability loses most of its consumers. Moving a boundary is not architectural failure. Refusing to move it after the evidence changes is.

A platform built this way is smaller than a central AI estate diagram and more consequential. It does not claim to own intelligence. It owns the roads by which many teams can use uncertain machinery without rebuilding the same perimeter each time.