Executive briefThe enterprise does not build or buy one AI stack

A board asked to buy the AI platform is being asked to approve nine materially different choices as though one product settled them. Accelerator scheduling has different economics from domain decision policy. A managed model has different change risk from an entitlement-aware context service. Evaluation evidence, system-of-record writes and customer workflow design carry accountabilities that a suite licence cannot transfer. The whole-stack binary hides these differences until implementation exposes them as exceptions and duplicated work.

The right unit is the layer capability. Source compute, models, gateway, context, agent runtime, integration, evaluation, operations and domain experience according to the control the enterprise must retain, the learning it seeks to own, the specificity of the asset, the rate of change, available competence, lifecycle economics and exit exposure. Compose the stack only after each choice shows its interfaces and dependencies. This makes an integrated suite an admissible result rather than an unexamined starting point.

Build, buy, adopt and partner are not mutually exclusive labels for the final system. A company may buy serving, adopt an open evaluation library, co-develop a specialised model, build domain policy and integrate everything through an internal gateway. Within one layer it may combine a managed base service with proprietary configuration and controls. Classify those commitments honestly. A thin wrapper around a vendor API is integration work and dependency, not necessarily a strategic proprietary asset.

The strongest rival: one integrated suite

A strategic suite can reduce contracting, identity, telemetry, integration, skills and support. Standard requirements may reach production faster and more reliably through one provider’s coherent services. Native integration can deliver measurable value that a lowest-common-denominator modular layer would lose. If lifecycle economics hold and concentration is within appetite, accepting coupling can be rational.

Ring-fence the decisions the suite must not absorb: domain policy, data meaning and entitlement, task evaluation, outcome evidence, risk acceptance and practical export. Resolve which provider services support those enterprise objects and which merely host them. Test the critical exit route instead of demanding theoretical substitution everywhere. A modular architecture has its own design and operating cost, so flexibility must serve plausible change rather than become an aesthetic requirement.

Layer Control LedgerSource nine capabilities on their own terms

Layer boundaries are analytical before they are technical. A suite may implement several, while one layer may use multiple suppliers. The ledger forces a separate claim about why the responsibility arrangement works. It then exposes coupling: a model choice can constrain serving, a context product can constrain entitlement, and a proprietary agent runtime can pull applications into its tool schema.

Nine decision columnsRecord what the enterprise must know and retain

Required control and accountability. Name intended use, data, policy, risk, outcome and evidence duties that cannot be delegated by contract. Distinguish who operates a control from who sets it and who accepts residual exposure. A managed service can enforce an enterprise rule while the enterprise remains accountable for its content and applicable consequences.

Differentiation and learning. Identify whether the layer embodies a proprietary process, scarce domain knowledge, compounding data, unique customer experience or strategic experimentation. Building commodity serving does not become strategic because it is technically demanding. Buying a component need not surrender differentiation if the valuable learning remains in domain policy, workflow and outcome feedback.

Asset specificity and integration. Estimate how much code, data, configuration, skill and process has value only with this supplier or design. Deep coupling can improve performance and experience; it also raises transition cost. Classify configuration, integration, extension, fine-tuning and proprietary capability separately so the ledger shows what has actually been created.

Change and option value. Model capability, provider terms, regulation, demand and internal competence can move at different rates. Use shorter contracts and modular seams where uncertainty is material. Accept more integration where requirements are stable or native value is demonstrated. The review date follows the fastest consequential assumption rather than an annual architecture calendar.

Boundary needs and capability. Record security, privacy, jurisdiction, data and evidence requirements, then assess talent, operating capacity, on-call, evaluation and support. A build decision without the people to run it is a deferred incident. A buy decision without internal competence to challenge the supplier is not managed delegation.

Economics, health and exit. Model build, licence, usage, infrastructure, integration, review, incident, change and transition across plausible volume. Examine supplier or community governance, concentration, licence, vulnerability response and roadmap influence. Name interfaces, exportable artefacts, substitute, tested transition and retirement. A portability clause is evidence only after a practical export and reconstruction exercise.

Five responsibility modesChoose an operating arrangement rather than a price label

Modes can change over a layer’s life. Managed service can accelerate initial learning, then sustained volume or control requirements can support internal operation. A proprietary component can lose distinctiveness and move to a standard service. An open project can gain commercial support. The ledger preserves why the current mode was chosen and which evidence will reopen it.

Layer Sourcing ContractMake the hand-off executable

The contract defines the outcome and exclusions for one layer. It names consumers, interface, versions, extensions and service levels. It identifies enterprise responsibilities, provider or community duties, evidence produced, access and retention. Costs include usage and the surrounding integration, review, support and incident work. Dependency and concentration are linked to the composed stack.

For managed serving, the supplier may own accelerator scheduling, scaling and infrastructure recovery. The enterprise still chooses data destinations, tenant isolation requirements, task evaluation, capacity priority and incident escalation. For open-source evaluation, the enterprise may gain code inspection and extension while assuming dependency scanning, test maintenance, judge validation, hosting and upgrades. Similar capabilities can therefore have very different responsibility profiles.

Change terms specify notice, compatibility, model or component versioning, security updates, policy changes and price response. The contract states who can approve an extension and when customisation breaks normal upgrade support. An integrated suite may allow deep native coupling for a measured use, while the enterprise preserves export of data, policies, evaluations, receipts and necessary configuration.

Exit defines the substitute or degraded process, export form, dependency inventory, regression evidence, transition owner, customer or regulatory obligations, support period and final removal. Review triggers include material volume, price, regulation, capability, licence, community, incident, supplier, skills or concentration change. The contract is renewed against current alternatives, not the market that existed at purchase.

Composition disciplineExpose cross-layer consequences before signing

A layer can look portable in isolation while depending on an adjacent proprietary object. A gateway may export configuration but rely on a suite-specific identity model. A retrieval service may expose documents but not ranking features or provenance. An agent runtime may use open tool schemas while storing recovery state in a vendor database. Composition review follows data, policy, evidence, state and skills across layers.

Modular seams need semantic contracts, conformance tests and owners. They reduce some switching cost and allow independent change, but they add latency, translation, version coordination and support. Native coupling can remove these costs or expose differentiated capability. Record the value it creates and the products it strands if the supplier changes. Avoid claiming portability because two components exchange compatible JSON.

Concentration also composes. Separate purchases may depend on one cloud, base model, identity tenant, telemetry backend or systems integrator. Bundled discounts can hide the marginal cost of exit and the loss of negotiation leverage. The cross-layer dependency graph records shared foundations and critical workloads, then links them to tested alternatives and recovery time.

Responsibility can duplicate across a seam. A vendor and an internal team may both monitor, review incidents or operate policy configuration indefinitely because transition was never completed. Temporary double staffing can reduce migration risk, but the contract has an end state, evidence and date. Otherwise the suite delivers neither lower operating burden nor stronger enterprise control.

Negative controlsTest ten sourcing decisions

Lifecycle economicsFollow the cost river as volume and responsibility move

Managed service often has the fastest time to value and converts infrastructure into usage cost. Its curve includes integration, provider management, evaluation, review, support, retry, egress, committed spend and exit. At higher sustained volume, internal serving can become competitive, but only when utilisation, hardware acquisition, orchestration, security, model operations, energy, skills and recovery are included. The crossover is evidence, not a generic threshold.

Open-source adoption removes or changes the licence fee, not the operating organisation. Community governance, component provenance, vulnerabilities, testing, hosting, upgrades and support become enterprise or partner duties. A commercially supported distribution may alter that allocation. Compare the chosen responsibility arrangement with realistic alternatives instead of equating source access with zero total cost.

Partnership economics include coordination, joint decision latency, duplicated teams, IP constraints, revenue share, dependency and transition. They can be attractive where neither party can create the capability alone and learning is shared by contract. Proprietary build includes opportunity cost of scarce engineers and the risk that a once-distinctive layer becomes commodity before the estate matures.

Cost is segmented by layer and workload. A suite discount may lower nominal prices while increasing switching cost or unused commitment. An internal platform subsidy can make product adoption look cheap while central capacity remains idle. The ledger exposes fixed, variable, attributed and shared burden, plausible volume bands and the trigger for re-sourcing. It never compresses control and strategic value into a single financial score.

Dependency compositionFind the supplier beneath apparently separate layers

Map every layer to provider, cloud, region, base model, identity, data store, open-source component, licence, hardware, integrator and scarce skill. Attach critical products and recovery requirements. This reveals that separately contracted model, gateway and evaluation tools may depend on one underlying service, or that several open components depend on one fragile maintainer and build chain.

Concentration is not automatically unacceptable. A coherent supplier can reduce operational seams and deliver better service. The enterprise decides whether the benefit exceeds the correlated failure, commercial leverage and exit exposure for the affected workload. The map allows selective mitigation: alternate region, export rehearsal, capacity reservation, replacement interface, escrow, additional internal skill or deliberate acceptance.

Supply-chain evidence follows code and model artefacts. Provenance records where and how artefacts were produced. Bills of materials describe packages, licences and relationships. These records support vulnerability and dependency response without proving that an artefact is safe, legally usable or fit for the task. Owners still interpret them within the Layer Sourcing Contract.

Review the map when bundles change. A suite acquisition, partner subcontractor, new hosted model or community handover can alter concentration even if application interfaces do not move. Procurement, security, platform and domain owners need a shared dependency view. Supplier dashboards alone cannot be the evidence source for a risk that includes the supplier itself.

Revisit deliberatelyUse events, not habit, to reopen sourcing

Demand and economics. Sustained volume, utilisation, latency or capacity can move the managed-versus-operated curve. Falling use can make an internal service uneconomic. Material price, discount, egress or support changes alter the comparison. The trigger opens a fresh estimate with transition cost and current alternatives, not an automatic reversal.

Control and regulation. New jurisdiction, data class, intended use, audit requirement or applicable rule may require stronger enterprise control or different evidence. The response can be a contract change, added enforcement, alternate service or build. Regulation does not automatically mandate in-house operation; it changes the responsibility and evidence conditions the layer must satisfy.

Capability and supply chain. A supplier can add or remove native capability, change a model alias, alter terms or experience an incident. An open project can lose maintainers, change licence or disclose a vulnerability. A partner can be acquired. These events update health, concentration, switching and option evidence. The ledger’s review trigger prevents a five-year sourcing label from outliving its assumptions.

Exit evidence. Failed export, regression or recovery exercises are themselves triggers. A theoretical substitute may not reproduce policy, state, model behaviour or workflow. The owner funds remediation, accepts exposure within authority or changes the sourcing mode. Retirement is triggered when a proprietary layer no longer differentiates and consumes scarce skills that could support more valuable capability.

Worked compositionSource one enterprise decision journey layer by layer

Define the outcome and retained decisions first

Consider a document-assisted case workflow that retrieves protected evidence, drafts a recommendation and prepares an action for authorised human approval. The product owner defines the affected decision, service outcome, data purpose, user authority and rollback. Before a supplier shortlist exists, architecture traces the journey through all nine layers. Security, privacy, risk, finance and operations identify non-delegable decisions and required receipts. This starting point prevents a suite demonstration from redefining the problem around its strongest features. It also provides the same outcome boundary for comparing an integrated option with a composed stack.

Buy elastic serving while preserving workload priority

The workload is initially uncertain and the enterprise lacks a high-utilisation accelerator estate, so a managed serving layer has the better time-to-value and capacity curve. Its Sourcing Contract covers tenant isolation, region, scaling, quota evidence, recovery, performance telemetry and export. The provider operates infrastructure; the platform owner decides which workloads receive reserved capacity, how sensitive traffic is isolated and what degraded mode applies. The ledger schedules a crossover review after sustained demand evidence, rather than promising either permanent outsourcing or a future private cluster without a measured utilisation case.

Buy model access but own the eligible role

The model layer uses an approved managed model portfolio. The provider supplies versions and service, while the enterprise owns task admission, data conditions, evaluation thresholds, change detection and replacement. A provider-specific structured-output feature creates useful value, so the gateway exposes it through a typed extension and records the dependency. The Sourcing Contract requires actual version evidence, incident notification, applicable reuse restrictions and route receipts. Procurement negotiates terms but does not decide that a discounted model is fit for this workflow. The model owner renews the role against current alternatives.

Build policy seams around a managed gateway

A commercial gateway can supply high-availability proxying, adapters and quota enforcement. Enterprise identity, purpose, data and routing policy remain canonical outside its dashboard. The internal team builds the policy compiler, reference tests and receipt mapping that embody control-critical design, while integrating the managed request path. This is neither a pure buy nor a proprietary gateway build. The ledger identifies the bought service, enterprise control asset and integration burden separately. Exit tests prove that policy definitions, test cases and historical receipts can move, while native gateway optimisations are listed as deliberate switching exposure.

Build domain context and buy commodity storage

Managed search and storage satisfy commodity scale and availability needs, but source authority, semantics, entitlement, temporal truth and provenance reflect enterprise data and workflow. The organisation builds those contracts and transformation rules, using vendor services underneath. Retrieval evaluation and correction propagation remain enterprise capabilities. Export testing covers documents, metadata, permissions, lineage and index reconstruction, not only raw object download. This boundary preserves proprietary knowledge operations without committing scarce engineers to undifferentiated storage infrastructure. If a vendor ranking feature creates measured value, its dependency is visible and renewed.

Adopt a runtime only behind transaction controls

An open-source agent runtime accelerates planning, state handling and tool coordination. Adoption transfers hosting, upgrades, vulnerability response, compatibility and on-call work to the platform team. Domain workflows still define tool permission, transaction boundary, human approval and recovery. The component’s community, release cadence, licence and dependency bill are reviewed. System-of-record writes pass through enterprise tool contracts rather than native runtime shortcuts. If the community weakens, the alternate runtime is tested against saved trajectories and state export. Source access helps transition, but the operational contract creates the real option.

Partner for a specialised connector with clear ownership

A systems partner has technical access to a regulated legacy platform while the enterprise holds domain rules and test data. Co-development can reduce discovery time, provided the contract assigns connector schema, generated code, credentials, test artefacts, defects, support and intellectual property. Production write authority stays with the domain service. The partner supplies evidence and knowledge transfer, and the enterprise can operate or re-source the connector after exit. Milestones reward working transactions and recovery tests instead of document delivery. The arrangement is revisited when the legacy platform or integration interface changes.

Keep evaluation ownership separate from the tool

A commercial evaluation service may run suites, manage examples and visualise results. The enterprise owns scenario meaning, affected cohorts, disqualifying failures, adjudication and release decisions. Provider-generated judges are treated as components with their own validation. Evidence export includes cases, configurations, raw results, review decisions and version lineage. Independent validation can access the necessary records without relying on a vendor summary. Buying the tool reduces operational work; it does not transfer the claim that the system is fit for the intended use or that residual risk is acceptable.

Accept suite observability where evidence remains portable

The integrated supplier’s telemetry has lower integration burden and better native correlation with serving and gateway events. Architecture accepts this coupling after comparing it with a modular alternative. Enterprise trace identifiers and outcome links remain stable, sensitive content is redacted before broad export, and finance can reconcile usage independently. Incident responders can retrieve evidence during provider disruption. A scheduled export rehearsal reconstructs the critical route in an alternate store. The contract documents native investigations that would degrade after exit so management can judge the exposure rather than claiming perfect portability.

Build the domain product and measure captured outcome

The experience and workflow layer contains the organisation’s differentiated process: how staff review evidence, apply policy, communicate the decision and learn from corrections. The enterprise builds and owns it while purchasing lower layers. Product telemetry measures adoption, review, errors, cycle time and captured outcome without attributing all value to the model or suite. Change management and operating policy remain with accountable domain leadership. This investment also protects sourcing options because the supplier does not own the only usable workflow or outcome history. The stack is composed around the product, not the other way round.

Review the composition at its coupled seams

The final architecture record shows each layer’s mode, interface, retained duty, evidence, cost, dependency, owner and trigger. Cross-layer review identifies that serving, model and observability share one provider, while the agent runtime and connector add separate supply-chain obligations. Management accepts the concentration for the initial volume with tested exports and a bounded recovery plan. When demand, regulation, supplier terms, incidents or capabilities change, only affected ledger rows reopen, followed by a new composition check. This preserves coherence without turning every sourcing event into a wholesale platform replacement.

Interactive instrumentAI Stack Sourcing Resolver

Select the layer’s control, differentiation, capacity, cost, supply-chain, coupling and exit conditions. The Resolver returns one of exactly five routes with a Sourcing Contract, retained responsibility, total-cost boundary and review trigger. It never produces a sourcing or maturity score.

Exactly five outcomesChoose a sourcing responsibility, not a score

Evidence boundarySourcing theory guides responsibility without dictating one stack

Transaction-cost research informs asset specificity, uncertainty and governance burden. Resource-based strategy informs build where valuable, scarce and difficult-to-reproduce organisational capability matters. Neither implies that technical difficulty alone creates strategic differentiation. Product-architecture and modularity research informs interface options and integral trade-offs without making modularity universally superior.

Open-source economics informs incentives and governance beyond licence price. Production-ML research supports attention to glue code, entanglement, undeclared consumers, testing and maintenance. NIST secure-development guidance, SLSA, SPDX and CycloneDX support development, provenance and component-dependency evidence. Those records do not by themselves establish task fitness, safety or licence permission.

FinOps supports collaborative lifecycle economics and allocation. ISO and NIST inform supplier, governance, measurement, change and monitoring boundaries. DORA and the EU AI Act record apply only to relevant entities, systems, actors, provisions, jurisdictions and timing. They do not transfer enterprise accountability to a vendor.

The nine-layer Layer Control Ledger, Layer Sourcing Contract, composed concentration graph, lifecycle-cost river and AI Stack Sourcing Resolver are this article’s synthesis. The final test is whether each layer’s operating arrangement creates required capability while keeping control, responsibility, evidence and change options explicit enough to revisit.