Context Data

Context Data is best understood by the layer diagram on its own homepage. Layer one is the tool envelope — which agents can reach which tools and whether a call is safe; that layer is served by identity and tool-governance platforms. Layer two is the data plane — the actual databases, documents, and APIs those tools read and write — where cost, governance, and safety are enforced on the data itself. Onyx lives at layer two, and that distinction is the whole product strategy. The runtime intercepts real queries and results using protocols your stack already speaks (Model Context Protocol, Postgres wire, HTTP), then applies six in-line stages: identity resolution, policy evaluation, deterministic and semantic caching, routing to the origin store on a miss, PII redaction row by row in the result stream, and an immutable audit entry for every request and response. The strengths are concrete. The adaptive cache recognizes repeated access even when the same question is phrased as a different query, which is exactly the failure mode that makes agent fleets expensive — the same record pulled hundreds of times a day by different sessions. The content-aware index reads PDFs, scans, spreadsheets, and decks in the background so an agent finds a file by content, category, and related entities rather than by path. The write gate is the most operationally valuable piece: role permissions decide whether an agent may write, not whether a specific write is safe, so Onyx inspects each write and holds dropped tables, unbounded deletes, and production schema changes for human approval. That is the difference between a demo and something you leave running overnight. The weaknesses are equally clear. This is infrastructure, not an application — there is no chat UI, no answer-generation layer, and no prompt tooling. Someone on your team has to own deployment, policy definitions, and the approval queue; if nobody does, the write gate becomes a bottleneck rather than a safety net. The platform assumes you already have agents worth governing. Cleanroom and Chronicle are narrower: one is for teams actively training or evaluating models, the other for teams debugging agent runs in production, and a team that has neither problem is paying for surface area it won't use. Where it fits: regulated or cost-sensitive organizations running agent fleets against internal systems, particularly where an auditor will eventually ask who accessed what and why. Where it doesn't: solo builders, marketing teams wanting a no-code assistant, and anyone whose real blocker is still getting retrieval to work at all — that's a layer above this one.