Requirement
Stated as a capability with no product in it. If you cannot write this line, you are not ready to choose software.
Reference architecture
Every building block, and what to build it from.
Twelve building blocks across four planes, plus a six-capability data spine underneath. This page names, for each one, the capability it must deliver, the credible open-source candidates, whether to adopt, assemble or build, the seam that connects it to everything else, and the test that proves it works.
Almost all of it can be built from open source. That is the point, and it is the argument against buying an agent platform: the components are commodity, the assembly is straightforward, and the three or four pieces that are genuinely hard are the ones no product ships — because they encode your estate rather than anyone’s.
How to read this
The method matters more than the list
Every block below follows the same shape, because the shape is the transferable part. Tool names change; the requirement, the seam and the acceptance test do not.
Candidates
Open-source projects that actually deliver the capability, with the caveat that matters — maintainership, licence, or what it does not cover.
Verdict
Adopt, assemble, or build. Most blocks are assembly. Three are build, and those three are where the value concentrates.
Acceptance
The test that proves the block is real. If it cannot fail, it is not a test and the block is not done.
Verdict key
Adopt — commodity, pick one, move on
Assemble — the parts exist, the glue is the work
Build — no product does this for you
Candidates reflect the landscape at the time of writing and are named because we have used or evaluated them, not because anyone pays us — we take no fees, referrals or commissions from any project or vendor on this page. Two standing caveats. Licences move: several well-known projects have left OSI-approved licensing in the last three years, so verify the licence of the specific component and version you will depend on. And maintainership moves faster than licensing: a project with one maintainer and a corporate acquisition in its history is a different risk from a project under a foundation, regardless of what the LICENSE file says. See the licence section for how we handle this in practice.
Start here
The minimum viable stack
If you want one agentic workflow running under real control — not a demo — this is the shortest credible list. Ten components, all open source, assembled in a matter of weeks rather than quarters. Everything else on this page is depth you add once this is running.
| Capability | Start with | Why this one first |
|---|---|---|
| Model access boundary | LiteLLM, or Envoy AI Gateway if you already run Envoy | One egress path, one log, model identifiers in configuration. Everything else on this list becomes enforceable once this exists. |
| Tool interface | MCP servers you write, behind a gateway you operate | A converged, boring standard. Write task-shaped tools; do not expose raw APIs. |
| Per-action policy | Open Policy Agent, or Cedar | Authorisation evaluated per call rather than per session. The single control that separates a demo from a system. |
| Workload identity | SPIFFE/SPIRE, plus OIDC federation to your cloud | Agents get their own short-lived identity. No shared service principals, no human’s personal token. |
| Sandboxed execution | Kubernetes with gVisor or Kata, or Firecracker microVMs | Agent-authored code runs somewhere it cannot reach anything interesting. |
| Durable task state | Temporal, or LangGraph checkpointing for lighter runs | Retries, idempotency and resumption become properties of the runtime instead of prompt instructions. |
| Evaluation harness | promptfoo, or Inspect AI | Somewhere to put the golden task suite so a prompt or model change is a test run rather than a debate. |
| Tracing | OpenTelemetry with the GenAI semantic conventions, into whatever backend you already run | Do not adopt a separate AI observability stack. Agent traces belong beside your service traces. |
| Flow metrics | Apache DevLake, or Four Keys | The baseline you will be asked to prove improvement against. Instrument before you start, not after. |
| Feature flag / kill switch | OpenFeature with flagd | A disable that is checked as a precondition inside the tool plane, not a button in a console. |
What is deliberately missing from that list. A vector database, an agent framework, and a portal. None of the three is load-bearing at the start, all three are easy to add later, and each one is a common way to spend a quarter on plumbing before anything has run end to end.
Plane 1
Context & State
What the agent knows about your estate, and what it remembers between runs. The cheapest plane to underestimate, and the one that determines whether everything above it works.
BB-1 · Context & State
System context graph
Requirement: a generated, continuously refreshed, machine-readable map of services, repos, pipelines, datasets, environments, dependencies, owners, SLOs and on-call — built from what already exists, not from a wiki someone maintains.
The trap here is spending six months building a developer portal. You almost certainly have the raw material already: infrastructure state, CI configuration, the cloud resource graph, catalogue metadata, git history, incident records. The work is ingestion, joining, and exposing an agent-facing projection — a context pack scoped to a task, not a browsable UI.
| Candidate | What it gives you, and the caveat |
|---|---|
| Backstage | The catalogue schema and entity model, which is worth adopting even if you never show the UI. Caveat: substantial operational weight, and its value to agents is the YAML underneath, not the portal. |
| Steampipe | SQL over live cloud and SaaS APIs — the fastest way to answer “what actually exists” without building an inventory pipeline. Caveat: query-time, so it is a source rather than a store. |
| OpenTofu / Terraform state | The authoritative record of what was provisioned deliberately. The delta against Steampipe’s live view is itself a valuable signal. |
| Apache AGE, or Neo4j Community | Graph storage for the joined result. AGE keeps it inside Postgres, which is usually the right call — a graph database is rarely the interesting part. |
| DataHub or OpenMetadata | If datasets are in scope, these already model ownership, lineage and classification. Reuse rather than duplicate. |
| tree-sitter, SCIP indexers | Code-level structure — symbols, call graphs, ownership by path — when the agent needs to reason about a codebase rather than an estate. |
Assemble Verdict. Ingest from what the client already runs, store the join, and own the projection. Never rebuild the portal. The seam that matters is the context pack: given a task, return the subgraph the agent needs, with freshness and provenance attached to every fact.
Acceptance: pick ten real tasks; for each, the pack contains everything a competent engineer would have looked up, and nothing older than its stated freshness.BB-2 · Context & State
Contract and schema registry
Requirement: versioned, machine-readable contracts for the three things agents touch — APIs, data, and infrastructure module interfaces — with breaking-change detection in CI.
This is the block with the best open-source coverage on the page and the worst adoption rate, because the software is not the hard part: agreeing on ownership is. Every component below exists, is mature, and takes an afternoon to wire into CI.
| Candidate | What it gives you, and the caveat |
|---|---|
| OpenAPI + Spectral + oasdiff | Description, linting and machine-checked breaking-change detection for HTTP APIs. The same OpenAPI document generates your tool schemas, which is a seam worth exploiting. |
| Buf | Protobuf schema management with breaking-change checks that work well enough to gate merges. The reference standard if you are gRPC-first. |
| Apicurio Registry | Apache-2.0 schema registry for Avro, Protobuf and JSON Schema, with compatibility rules. Preferable to registries under restrictive community licences if licence purity matters to you. |
| Open Data Contract Standard + datacontract-cli | A vendor-neutral shape for data contracts — types, semantics, freshness, ownership, classification — plus a linter and test generator. The fastest way to stop arguing about format. |
| dbt model contracts | Enforced column types and constraints at build time where dbt is already in use. Cheap, and it puts the contract next to the model. |
| Conftest / OPA, terraform-docs | Module interface rules and documented inputs for infrastructure, checked in CI like anything else. |
Adopt Verdict. Pure assembly, no invention required. Spend the effort on the drift report — the list of contracts that exist versus the surfaces agents actually touch — because that gap is the real finding and no tool produces it for you.
Acceptance: a deliberately breaking change to a contracted API, table and module is caught in CI, on all three, without a human noticing first.BB-3 · Context & State
Execution memory
Requirement: plans, decision logs, progress and structured handoffs, durable enough that a fresh session resumes a long task correctly instead of restarting it.
The worst-served block on this page. There are dozens of “agent memory” projects and almost all of them solve a different problem — remembering facts about a user — while the thing that breaks long agentic runs is losing the state of the work: what was tried, what was rejected and why, which step is next, what the completion criteria were.
Two design notes that matter more than the tool choice. Prefer a compact current-state map that points at live artifacts over a large static rulebook, because the rulebook goes stale and nothing tells you. And separate execution memory from user memory: different lifetimes, different owners, different blast radius, and merging them is a decision you regret at the first audit.
| Candidate | What it gives you, and the caveat |
|---|---|
| Temporal | Durable execution: state, retries and resumption as runtime properties rather than prompt instructions. Heavier than teams expect, and worth it the first time a run survives a deploy mid-task. |
| LangGraph checkpointers | Lighter durable state for graph-shaped agent runs, with pluggable Postgres persistence. Good for a first implementation; less good as the coordination surface grows. |
| Restate, DBOS | Newer durable-execution runtimes with lower operational weight than Temporal. Smaller ecosystems — evaluate on your own workload rather than on the marketing. |
| In-repo conventions plus ADRs | A plan file, a decision log, a progress file, dated architecture decision records. Unfashionable, version-controlled, reviewable, and it survives every framework change. Start here. |
| Letta, Mem0, Zep | Memory extraction and retrieval as a service. Useful, but check what happens to provenance and classification at write time — most implementations drop both, and that is where the leak is. |
Build Verdict. The schema is yours and no product supplies it. Borrow durability from Temporal or a checkpointer, keep the human-readable artifacts in the repository, and measure the thing nobody measures: resumption success rate, the share of interrupted tasks a fresh session continues correctly without a human re-briefing it.
Acceptance: kill a session deliberately at the midpoint of a real multi-step task. A fresh one resumes and finishes correctly, with no human explaining what happened.Plane 2
Execution
Where the agent does work: somewhere isolated enough to break, with realistic data, through actions that are typed, bounded and audited.
BB-4 · Execution
Reproducible environment fabric
Requirement: ephemeral, isolated, fast-to-provision environments an agent can create, break and destroy — with realistic data that is not production data. Provisioning time is a first-class metric.
Two separable problems get conflated here. The compute side is a solved problem with good open-source coverage. The data side is where agent programmes quietly stall: no safe path to realistic test data means nothing can be built, and the diagnosis is usually made months late. Budget accordingly — the masking and subsetting work is typically the larger half.
| Candidate | What it gives you, and the caveat |
|---|---|
| vcluster | Virtual Kubernetes clusters per task or branch, in seconds rather than minutes. The pragmatic answer if you are already Kubernetes-first. |
| gVisor, Kata Containers, Firecracker | Real isolation boundaries for agent-authored code. Container isolation alone is not a security boundary against code you did not write. |
| Dev containers, Nix / devenv | Deterministic toolchains, so “works in my session” stops being a class of failure. Nix has the steeper curve and the better guarantee. |
| Argo CD ApplicationSets, Crossplane | Preview environments and dependency provisioning driven from the same declarative path as production. |
| Testcontainers | Real dependencies inside the test run. Often removes the need for a full environment entirely, which is the cheapest possible answer. |
| Greenmask, Neosync, PostgreSQL Anonymizer | Masking and referentially-consistent subsetting — the hard part. Subsetting that preserves referential integrity is what makes a small, safe, useful dataset rather than a broken one. |
Assemble Verdict. Adopt the compute stack; do the data work properly. The seam is a masked, subset, referentially-intact seed that provisions in the same step as the environment — and it is a data engineering deliverable, not a platform one, which is why it falls between two teams and does not get done.
Acceptance: provisioning time under the SLO you published, and a documented test showing no production identifier survives the masking — run as a job, not as a claim.BB-5 · Execution
Tool and action plane
Requirement: a permissioned catalogue of actions agents may take, each a versioned contract with typed input and output, idempotency semantics, scoped identity, prohibited operations, a dry-run mode and trace correlation.
The interface question is settled enough to stop debating: write tools as MCP servers and put a gateway in front of them. The engineering that matters is in the contract, not the protocol — task-shaped operations with narrow types beat general-purpose access every time, for reliability as much as for safety. A tool the model can use correctly on the first attempt is a tool you designed for the caller you actually have.
| Candidate | What it gives you, and the caveat |
|---|---|
| MCP SDKs | The converged tool interface, with server SDKs in the languages you already use. Boring, which is the compliment. |
| An MCP gateway you operate | One place to enforce identity, policy, rate limits and audit across every tool. Several open implementations exist; the requirement is that it is yours, not which one. |
| Open Policy Agent, Cedar | Per-action authorisation as code, evaluated on every call with the real caller’s identity — never the model’s claim about who it is acting for. |
| Temporal | Idempotency keys and retry semantics for write tools. Agent loops retry constantly; a write tool without an idempotency story eventually does the same thing four times. |
Terraform plan, kubectl --dry-run=server, Atlas | Dry-run that already exists in the systems you operate. Expose it as a first-class tool mode rather than building a simulator. |
| OpenTelemetry | Trace correlation from the request through the tool call to the effect. Audit the call and its arguments, not just the answer. |
Assemble Verdict. The protocol is free; the contracts are the work. Every tool needs a schema, an owner, an authorisation check, an idempotency story, limits, an audit record, and a reviewed description — remembering that tool descriptions are prompt content executed in your context, so a third-party server’s text is untrusted input. Pin versions and review diffs.
Acceptance: every write tool has a dry-run that has been exercised, an immutable audit record, and a documented prohibited-operation list — and a call that violates it is refused, demonstrably.Plane 3
Verification
The plane that converts agent output from a suggestion into something mergeable — and the one that decides whether the whole investment pays, because throughput is capped by time to verdict.
BB-6 · Verification
Evidence and evaluation plane
Requirement: five layers of checks, starting at layer 0 — postconditions and input provenance — because everything above layer 0 can be satisfied by a plausible artifact built from the wrong source.
Layer 0 is the one with no product behind it, and it is the one that catches false completion: the failure where an agent produces something that looks entirely correct, reports success, and is wrong because it came from the wrong place. Deterministic tests pass. A reviewer reads it and approves. Only an independent assertion that the required end state holds, that inputs came from the authorised source at the expected version, and that prohibited side effects did not occur, catches this class.
| Layer | Candidates | Note |
|---|---|---|
| 0 — Provenance and postconditions | OpenLineage + Marquez, in-toto and SLSA attestations, Sigstore/cosign, Conftest/OPA assertions | Assembled from parts, never bought. Lineage is a hard prerequisite for any data-touching workflow: without it, layer 0 cannot be implemented at all. |
| 1 — Deterministic | Your existing CI, plus Trivy, Semgrep, SBOM tooling | You already have this. It is necessary and it is the layer that gives false confidence. |
| 2 — Semantic | promptfoo, Inspect AI, DeepEval, Ragas for retrieval-shaped work | Where the golden task suite lives. Pick the harness that fits your CI, not the one with the best README. |
| 3 — Data | Great Expectations, Soda Core, dbt tests, Elementary, Deequ | Freshness, volume, distribution, null rate, referential integrity, reconciliation — as merge gates, not dashboards. |
| 4 — Policy | OPA, Kyverno, Cedar | Regulated-data movement, retention, residency, prohibited actions. Same engine as BB-5 and BB-8; one policy language across all three is worth the constraint. |
Build Verdict. The harnesses are free. The two assets are yours and cannot be bought: the golden task suite — a corpus of representative tasks from your estate with known-good outcomes — and the false-completion test set, tasks deliberately constructed so the lazy path produces a plausible but wrong artifact. Have the operators who own the workflow author part of the suite. It is the cheapest way to get a good one and the fastest way to build internal advocacy.
Acceptance: the false-completion set is run and the catch rate is published — including the ones that got through, which is the number that tells you where you actually are.BB-7 · Verification
Verification speed
Requirement: time-to-verdict below the time an agent takes to produce the next change. A discipline applied to BB-6, not a separate system.
This block gets skipped and then silently caps the entire programme. If verification takes forty minutes, agent throughput is forty minutes per iteration no matter how good the model is, and the return on everything else on this page is bounded by a number nobody is looking at. Measure it first; it is usually worse than anyone believes and cheaper to fix than expected.
| Candidate | What it gives you, and the caveat |
|---|---|
| Bazel, Pants, Nx, Turborepo | Dependency-aware test selection and caching, so a change runs the tests it can affect and nothing else. The largest single lever, and the largest migration. |
| Remote caching and execution | Shared build and test caches across CI and developer machines. The second-largest lever, and far cheaper than adopting a new build system. |
| Zuul | Genuinely open-source gating and merge queues — speculative merges tested together, so a green queue means a green trunk. |
| Flake quarantine | Mostly policy rather than software: detect, quarantine, budget, and fix on a clock. An agent programme on a flaky suite produces distrust faster than it produces value. |
Assemble Verdict. No new system — a baseline, a target, and a flake budget. Publish time-to-verdict next to the agent metrics so the trade-off is visible when someone proposes adding another check.
Acceptance: p50 and p95 time-to-verdict measured before and after, with the flake rate alongside — improving one by degrading the other is not a result.Plane 4
Control
Who the agent is, what it may do right now, and whether stopping it actually stops it. The plane where “we will add that later” becomes an incident.
BB-8 · Control
Identity, continuous authorization, and approval
Requirement: per-agent, per-task scoped workload identity with short-lived credentials, operation-level authorization re-evaluated per action, and mandatory human approval for money, access, data egress, regulated decisions and destructive actions.
The design premise is uncomfortable and load-bearing: treat a tool-using agent as a potentially adversarial process, not as a trusted coworker. Not because it has intent, but because it explores paths, it is steerable by content it reads, and it operates at machine speed. That premise makes authorization continuous rather than an onboarding gate — the same conclusion fraud practice reached about human sessions years ago.
| Candidate | What it gives you, and the caveat |
|---|---|
| SPIFFE / SPIRE | Cryptographic workload identity with short-lived, automatically rotated credentials. The correct primitive for “this agent, this task, this scope”. |
| OIDC federation to your cloud | No long-lived cloud keys anywhere in the pipeline. Free, well supported, and skipped constantly. |
| OpenBao, or Vault where licensing permits | Secret issuance with leases and revocation. Note the licence change that produced the fork; pick with your legal position in mind. |
| Open Policy Agent, Cedar, Casbin | The approval matrix and prohibited-action register expressed as code that runs on every call rather than as a page in a policy document. |
| Workflow-level approval gates | Temporal signals, Argo Workflows suspend, or a CI approval step. Approval must be a state transition in the system of record — never a confirmation the agent asked for and interpreted. |
Assemble Verdict. Every primitive exists and is mature. The work is the model: which identity, which scopes, which actions require a human, and what the register of prohibited operations contains. Keep one policy engine across BB-5, BB-6 layer 4 and BB-8 — three policy languages is how exceptions get written in the easy one.
Acceptance: evidence that an unsafe action was correctly refused. Not a policy document — a log line, from a real attempt, in a drill you ran.BB-9 · Control
Lifecycle control, reversibility, and containment
Requirement: an agent registry, process-level supervision with an explicit restart policy, a disable path that survives restart and redeploy, expiry by default, blast-radius limits, tested rollback, and a drill proving disablement holds for a full cycle.
The upgrade from “kill switch” to “lifecycle control” comes from a specific failure mode that is easy to reproduce and widely under-modelled: an operator stops an agent, and its supervisor restarts it. Safety language in a prompt is not a lifecycle control. A button in a console that a restart policy overrides is not one either.
| Candidate | What it gives you, and the caveat |
|---|---|
| OpenFeature + flagd | A disable flag checked as a precondition inside the tool plane on every action — so “disabled” survives a restart, because the restarted process checks it too. |
| Kubernetes admission policy — Kyverno, Gatekeeper | The enforcement half: a disabled agent’s workload cannot be admitted, whatever its supervisor wants. |
| Argo Rollouts, Flagger | Progressive delivery and automated rollback for changes agents ship, with the same mechanics you already trust for humans. |
| Cilium NetworkPolicy, resource quotas, budget caps | Blast-radius limits that are structural rather than advisory. An agent that cannot reach a network is not relying on being told not to. |
| Your service catalogue | The agent registry is a catalogue entity type — every running agent, its owner, scope, supervisor and expiry. There is no product for this, and there does not need to be. |
Build Verdict. Assembled from parts you have, but nobody ships it, and the registry plus the disable semantics are yours. Design the kill switch as a precondition evaluated inside the action path, not as a control-plane button — a button stops a process, a precondition stops the behaviour.
Acceptance: a live drill. Disable an agent, then attempt to restart it — by supervisor, by redeploy, and by scheduler. It stays disabled through all three, and you have the log.Cross-cutting
Measurement, portability, and the block with no software
BB-10 · Cross-cutting
Outcome ledger
Requirement: four tiers of measurement — flow, agent, adoption, business — instrumented before rollout rather than reconstructed afterwards.
| Tier | Instrument with | Reality |
|---|---|---|
| Flow | Apache DevLake, Four Keys, or your existing CI and git data | Well served, and the baseline you will be judged against. Instrument before you start; a baseline reconstructed after the fact convinces nobody. |
| Agent | OpenTelemetry GenAI semantic conventions, Langfuse or OpenLLMetry, into your existing backend | Acceptance rate, intervention rate, rework, eval pass rate, resumption rate, false-completion catch rate, and cost per successfully completed task. |
| Adoption | Your own tables — override rate, sustained use after week four, workflows abandoned back to manual | Not instrumentable off the shelf, and the tier buyers most often get wrong. |
| Business | Your own tables, agreed with finance before the engagement starts | Hours redirected, incident cost avoided, data-defect rate, cycle time on a named workflow. |
Explicitly not success metrics: licence activation, seat count, token consumption, or “AI usage”. The predictable trap is encouraging maximum adoption, then restricting use when the token bill arrives. Set the budget rule and the unit-economics target before rollout, and measure completed work rather than activity.
BB-11 · Cross-cutting
Model portability and routing policy
Requirement: separate the workload contract from the provider, so model choice is configuration and provider exit is a tested path rather than a hypothetical.
Build the abstraction boundary, which is cheap. Defer the sophisticated routing layer, which is not — the quality-adjusted saving has to survive gateway fees and the operational complexity you just added, and frequently does not. The differentiator is never “we support many models”; it is auditable placement logic, repeatable evaluation per route, and a fallback path someone has actually exercised.
| Candidate | What it gives you, and the caveat |
|---|---|
| LiteLLM | A provider-agnostic boundary plus a proxy with keys, budgets and logging. The pragmatic default, and enough on its own for most estates. |
| Envoy AI Gateway | The same boundary expressed in infrastructure you may already operate, with your existing policy and observability path. |
| vLLM, SGLang, Ollama | Self-hosting when data placement requires it. Cost per token looks attractive and utilisation is what actually decides the economics. |
| promptfoo, Inspect AI | A per-route evaluation set, so a routing change is a test rather than an opinion. |
| Outlines, instructor, JSON-schema modes | Structured output that holds across providers — the property that actually breaks when you switch, far more often than answer quality. |
Adopt Verdict. One boundary, model identifiers in configuration, an eval set per route, and an exit test you run on a schedule. That is the whole block until evidence justifies more.
Acceptance: switch the primary provider in a staging path and pass the evaluation suite without a code change.BB-12 · Cross-cutting
Operator adoption and trust
Requirement: the people who own the workflow trust the objective, understand what is not being automated, and see where their judgment still governs.
There is no open-source project in this row, and buying software here is the mistake. The block a technical team is most likely to skip and most likely to be hurt by: adoption is not secured by licences, and a workflow delivered into an unwilling team is quietly abandoned back to manual while the dashboard still shows green.
- Name the outcome, and name what is not being automated. The unstated version is heard as a headcount plan, and that reading is not irrational.
- Operators author part of the golden task suite. Cheapest way to get a good suite, fastest way to build internal advocacy, and it makes the evaluation theirs.
- Human judgment stays authoritative at named decision points — named, so the boundary is inspectable rather than reassuring.
- Publish escalation and incident paths before go-live, not after the first incident demonstrates the need.
- Act on override rate. A high override rate is information about the workflow, not about the operators.
Build Verdict. A delivery track, not a component. If your programme plan has no line for this, the plan has a gap that software will not close.
The spine underneath
Data: six capabilities running under all four planes
Data is not a fifth plane, it is the fuel. Ingestion and storage are commodity — buy them, pick by team familiarity, stop optimising. The differentiator is the contract, semantic and evidence layer that makes data trustworthy to a consumer that cannot sanity-check a number the way a human analyst does.
| Capability | Open-source candidates | Where to spend |
|---|---|---|
| D-1 · Ingestion and CDC Adopt | Debezium, dlt, Meltano/Singer, Kafka or Redpanda, Airbyte connectors | Commodity. Land data reliably, incrementally and replayably, then stop thinking about it. |
| D-2 · Storage and table format Adopt | Apache Iceberg, Delta Lake, Hudi; catalogs: Polaris, Nessie, Unity Catalog OSS; engines: Trino, DuckDB, ClickHouse, Spark | Commodity, with one real decision: pick the table format and catalog deliberately, because that choice is expensive to revisit. |
| D-3 · Transformation and modeling Adopt | dbt Core, SQLMesh, Dagster, Airflow, Kestra | Commodity tooling, non-commodity discipline: grain, layering and tested logic are what make the models usable by anything else on this page. |
| D-4 · Semantic and contract layer Build | Cube, MetricFlow, Malloy; Open Data Contract Standard, datacontract-cli, dbt model contracts | The agent’s data API, and the highest-leverage item in the spine. Governed metrics and dimensions, machine-readable contracts, CI enforcement. This is where the effort belongs. |
| D-5 · Quality, lineage, observability Assemble | OpenLineage + Marquez, Great Expectations, Soda Core, Elementary, DataHub, OpenMetadata | Freshness and volume SLAs, anomaly detection, and the lineage that BB-6 layer 0 depends on. Without lineage there is no provenance, and without provenance there is no layer 0. |
| D-6 · Governance and access Assemble | Apache Ranger, OPA, Unity Catalog OSS; masking and subsetting: Greenmask, Neosync, PostgreSQL Anonymizer | Classification, masking, workload identity, cost attribution — and the masked environment provisioning that BB-4 cannot ship without. |
The benchmark worth running before you commit to any of this. Take twenty real business questions your organisation actually asks. Run them against the warehouse directly, then against a modelled semantic layer, and measure answer accuracy both ways with no model change. Published 2026 vendor benchmarks report large gains from this change alone — we grade those figures C, because they come from parties selling the layer. Which is exactly why you should run it on your own twenty questions, where the number is yours and arguable.
Two dependencies from this spine are hard, and they are the ones that surprise platform teams: BB-6 layer 0 cannot be implemented for any data-touching workflow without lineage, and BB-4’s masked seeded environments are a data engineering deliverable rather than a platform one. Both fall between two teams, which is why both are usually late.
The uncomfortable part
“Open source” is now a question, not a label
Several of the most widely deployed projects in this space have left OSI-approved licensing in the last few years — moves to BUSL, SSPL and various source-available licences, each of which produced a fork, a fragmented ecosystem, and a procurement conversation somebody had to have. This is not a reason to avoid open source. It is a reason to select differently.
Check the component, not the project
Projects increasingly ship an open core with source-available add-ons. The relevant licence is the one on the specific component and version you will depend on in production, which is frequently not the one on the front page.
Prefer foundation governance
A project under a foundation — CNCF, ASF, Linux Foundation — has a licence change process that is slow and public. A single-vendor project has one that is neither. Weight this above feature comparisons for anything load-bearing.
Price the exit before you adopt
For each component: what is the migration if the licence changes, and how much of your design leaks into it? Components behind a boundary you own are cheap to replace. Components that shape your data model are not.
The practical rule we apply. Load-bearing and hard to replace — favour foundation-governed projects and accept fewer features. Peripheral and behind an interface you own — take the best tool and keep the boundary clean. And write down which category each component is in, because the answer changes as your architecture settles, and nobody re-examines a decision that was never recorded.
The honest summary
What not to build, and what nobody sells you
The strategic point of this page. If almost everything is assembly from open source, then the question worth asking is not “what should we buy” — it is “where is the work that is actually ours”.
Do not build these
- A developer portal. Ingest from and write to what exists. Own the agent-facing projection, not the UI.
- An observability backend. Agent traces belong in the backend you already run, under OpenTelemetry conventions.
- A model. Not close to the value, and the decision reverses every six months anyway.
- A general-purpose agent framework. Your harness should be small, specific, and yours. Frameworks are where estates go to accumulate abstractions nobody chose.
- A data warehouse. Ingestion and storage are commodity. Spending here is spending in the wrong row of the table above.
Nobody sells you these
- The execution memory schema and a measured resumption success rate. Every memory product solves a different problem.
- The golden task suite, with false-completion traps, authored partly by the operators who own the workflow.
- The agent registry and a disable that survives restart, drilled rather than documented.
- The system context graph of your estate — the join, the freshness, the provenance, the projection. This is the account-specific asset.
- The adoption and business tiers of the ledger, agreed with finance before the work starts rather than argued afterwards.
// where the money and the risk actually are
commodity = ingestion · storage · CI · tracing · model access · policy engines
assembly = tool contracts · environments · identity · routing · lineage
yours = context graph · execution memory · golden suite · agent registry
// the last line is the one that cannot be bought, and the one
// that makes the first two worth anything
commodity = ingestion · storage · CI · tracing · model access · policy engines
assembly = tool contracts · environments · identity · routing · lineage
yours = context graph · execution memory · golden suite · agent registry
// the last line is the one that cannot be bought, and the one
// that makes the first two worth anything
Which is also our position on this page. We just published the stack we would build for you, including the parts that make an implementation partner unnecessary. We are comfortable with that, because the list is not the difficulty. The difficulty is the last line of that block — and the sequencing, the acceptance tests, and the failure modes you only learn by hitting them across many estates.
Take the list. If the assembly is the slow part, that is where we come in.
Everything above is buildable in-house, and for some of you it should be. The engagements we sell are the sequencing and the evidence: which blocks in which order for your estate, the acceptance tests that prove each one, and the two or three assets that end up being yours permanently.