Context Engineering Is a Data Problem

Sun Aug 02 2026

Companies want your data and context because your context is their moat. Products that own your context can force you to use their agent… and, I’ve never seen a good hosted agent!

Organizations need to own their context, and the way to do so effectively already exists and is well understood.

Context as Data Infrastructure

Have you noticed the shape of the diagrams that every company is adding to their “intelligence” products? I see that and it seems like I’m looking at a Fivetran or dbt product page in 2018. That is because they’re the same thing!

Most organizations will need to build and maintain a model-agnostic knowledge base (aka ontology, company brain, …) for the same reasons they maintain a data warehouse. A curated and normalized layer helps both humans and agents make sense of all the structure that outlives any particular model, harness, tool, or product. Context engineering is that same work: extracting, filtering, curating, modeling, and publishing artifacts to help the organization make better decisions.

For now, it seems there isn’t a great set of tools (or modern context stack) built for this purpose. Something like Fivetran and dbt optimized for the new sources (Slack, Drive) and transformations (transcription, summarization, text extraction from a slide deck, …).

The Knowledge Build System

That said, I think there are a few patterns we can adapt and reuse.

Think of the knowledge base as a “compiler” for agents. It transforms raw source materials into representations that are optimized for LLMs. The shape of ETL/ELT fits here perfectly.

  1. Extract all the raw data into a filesystem or database, preserving whatever shape it comes in. For example, Slack channels as JSON or Google Slides decks as PDFs.
  2. Transform the raw sources into useful artifacts. Your organization doesn’t use Slack the same way as others, so model that in a way that gets reflected in the final text artifact. Summarize, extract, clean, and do anything else you need to capture what is useful there. There is no universally correct representation of company knowledge in the same way that there is no correct win rate waiting to be unearthed.
  3. Publish useful artifacts, usually a curated set of text files alongside embeddings for semantic retrieval. Embeddings merely index those files. Useful, expensive, disposable, and optional!

This means a company brain is built, tested, and released like any other data product rather than prompted into existence by giving your agent access to all the raw sources. After all, connecting Looker to every raw source or copying every table into a data lake never solved analytics, right?

Direct access can still be better than a poorly maintained knowledge base. But at some point, you need a process to derive meaning and codify what “truth” means in your context 1. Otherwise, agents will read the 3 differently defined OKRs and carry on.

In data, once someone figures out how a “key action” is defined, it gets encoded in a dbt model that downstream users consume and help evolve. A Knowledge Build System creates the same durable layer for context. Talking, rejecting PRs, and renaming fields are the ways the organization “thinks” and compacts knowledge. Each curated text file at the end is a cached materialized view optimized for something.

In practice, working on this context layer means:

Ingestion is not the product here. The processes of sense-making, modeling, and coordination are what allow organizational knowledge to compound.

Footnotes

  1. On top of that, context is finite (for now) and has diminishing returns! ↩

← Back to home