Research Brief: Context Engineering Is Just Data Modeling With Better PR

Recommended Angle: The Convergent Evolution Play

Mode: Contrarian Hook: Andrej Karpathy calls it “the delicate art and science of filling the context window with just the right information for the next step.” A dimensional modeler in 2003 called it Tuesday. The hottest term in AI right now is a rebrand of work data professionals have done for decades — and recognizing that isn’t dismissive, it’s the key to actually being good at it. Key argument: Context engineering is convergent evolution — the same underlying pattern (decide what information to include, how to structure it, and what relationships matter so a consumer can make good decisions) surfacing under new terminology for a new consumer (LLMs instead of analysts). Why this angle: It directly activates the founder’s strongest intellectual territory — convergent evolution (DEDP), analytics-as-craft, and the Lindy Effect. It’s contrarian without being reductive. The payoff isn’t “context engineering is fake” — it’s “data modelers are already context engineers, and they should own that.” This reframes the audience’s existing skills as newly valuable rather than obsolete, which drives shares and replies.

Angle 1: The Convergent Evolution Play (Recommended)

Mode: Contrarian Hook: Andrej Karpathy calls it “the delicate art and science of filling the context window with just the right information for the next step.” A dimensional modeler in 2003 called it Tuesday. Key argument: Context engineering is convergent evolution of data modeling — same pressures, same solutions, new name. The DEDP framework predicted this: every generation reinvents terminology for existing patterns. Semantic context = conformed dimensions. Temporal context = slowly changing dimensions. Provenance = data lineage. “Context window management” = query optimization under constraint. The work is the same; the consumer changed from a human analyst to an LLM. Supporting evidence:

• 06-reference/2026-04-04-dedp-convergent-evolution — The theoretical backbone: “when you see a ‘new’ technology, ask what older technology solved the same problem.”
• 06-reference/2026-04-04-dedp-semantic-layer-bi-olap-virtualization — The semantic layer is literally a context engineering layer from 1991. BusinessObjects Universe was doing “context engineering” 35 years ago.
• 06-reference/2026-04-05-dew-data-engineering-after-ai — Ananth’s ECL framework (Extract, Contextualize, Link) explicitly names “contextualize” as the new core skill — but it’s the same work data modelers did in the “Transform” step, just with more explicit attention to meaning. Connected Sanity Check issues:
• SC E05 (Analytics Crafting) — The craft framing: context engineering is analytical craft applied to a new medium. The “irreducibly hard” interrelated skills are the same.
• SC E07 (Data’s Secret Sauce) — “The value isn’t in the recipe — it’s in knowing which recipe to use, when, and why.” That’s context engineering in one sentence.

Angle 2: Your Data Model Was Always a Context Window

Mode: Analysis Hook: Every star schema you’ve ever built was an answer to the same question context engineers ask today: what does the consumer need to know, in what structure, to make a good decision? The consumer used to be a VP staring at a dashboard. Now it’s a language model with 200K tokens of attention budget. The engineering problem is identical. Key argument: Map the 1:1 parallels between dimensional modeling decisions and context engineering decisions. Grain = token-level relevance. Conformed dimensions = shared ontology. Slowly changing dimensions = temporal context. Fact table design = deciding which events matter. The data modeler’s judgment about “what belongs in this mart” is exactly the context engineer’s judgment about “what belongs in this context window.” Supporting evidence:

• 06-reference/2026-04-04-ontology-taxonomy-knowledge-graphs — Milan Mosny’s piece explicitly maps ontology, taxonomy, and knowledge graphs as the structural family that context engineering draws from. “Context Engineering designs the pipeline that selects relevant subgraphs for specific AI decisions.”
• 06-reference/2026-04-04-dedp-data-contracts-schema-evolution — Schema evolution and data contracts are context engineering’s predecessors: formal agreements about what structure and meaning to provide to downstream consumers.
• 06-reference/2026-04-05-dew-missing-layer-ai-stack — “Metadata is the model.” OpenAI discovered that standard metadata was insufficient — they needed human-curated descriptions and semantic ontologies. Data modelers have been curating metadata for decades. Connected Sanity Check issues:
• SC E08 (DPIM Framework) — The four-dimension framework (Data, People, Infrastructure, Models) maps cleanly to context engineering concerns: what data to include, who defines meaning, what infrastructure serves it, what model consumes it.

Angle 3: The Context Architect Was Always a Data Engineer

Mode: Story (PAIPS) Hook: When Ananth Packkildurai described the “Context Architect” — someone who designs contractual foundations, builds lineage infrastructure, and governs a context store — he was describing every senior data engineer I’ve worked with for the last decade. The job title is new. The job isn’t. Key argument: The emerging “Context Architect” role (designing what context to capture, how to structure it, how to govern it) is a rebrand of the senior data engineer / analytics engineer. The skills are identical: schema design, lineage thinking, stakeholder translation, governance. Data engineers who recognize this can claim the new title and the new salary band. Those who don’t will watch prompt engineers with no data background struggle to reinvent dimensional modeling from scratch. Supporting evidence:

• 06-reference/2026-04-05-dew-data-engineering-after-ai — Ananth’s “Context Architect” role description is a data engineer job spec with AI vocabulary.
• 06-reference/2026-04-04-context-graphs-trillion-dollar-opportunity — Context graphs need the same skills as data warehouse design: entity modeling, temporal relationships, governance. “What’s the right data model for a context graph?” is literally the open question.
• 06-reference/concepts/analytics-as-craft — The craft thesis: context engineering is irreducibly hard for the same reasons analytics is. You can’t automate the judgment about what context matters. Connected Sanity Check issues:
• SC 014 (Good Bad Ugly dbt) — State management in dbt (manifests, —state flag) is context engineering for build systems. Same pattern, smaller scale.
• SC E05 (Analytics Crafting) — “Multiple interrelated skills functioning as a distinguishable whole” describes the context engineer perfectly.

Supporting Material from Vault

• 06-reference/2026-04-04-dedp-convergent-evolution — The core theoretical framework: new terminology for old patterns is the rule, not the exception. Context engineering fits perfectly.
• 06-reference/2026-04-04-dedp-semantic-layer-bi-olap-virtualization — The semantic layer (1991) is the original context engineering layer. BusinessObjects Universe predates Karpathy’s tweet by 34 years.
• 06-reference/2026-04-05-dew-data-engineering-after-ai — ECL framework and the “Context Architect” role. The strongest external validation that context engineering is data engineering’s next form.
• 06-reference/2026-04-05-dew-missing-layer-ai-stack — Context graphs as reasoning layers. “Metadata is the model” validates the data modeling parallel.
• 06-reference/2026-04-04-ontology-taxonomy-knowledge-graphs — Maps the knowledge representation family and explicitly positions context engineering as subgraph selection from knowledge graphs.
• 06-reference/2026-04-04-context-graphs-trillion-dollar-opportunity — Context graphs need data modeling skills. The open question “what’s the right data model for a context graph?” proves the connection.
• 06-reference/2026-04-04-dedp-data-contracts-schema-evolution — Data contracts as proto-context-engineering: formal agreements about structure, semantics, and validation between producers and consumers.
• 06-reference/concepts/analytics-as-craft — The craft framing that makes this piece land: context engineering is craft, not commodity, for the same reasons analytics always was.

External References

• Andrej Karpathy on X — The origin tweet: “+1 for ‘context engineering’ over ‘prompt engineering’… the delicate art and science of filling the context window with just the right information for the next step.”
• State of Context Engineering in 2026 (SwirlAI) — Five patterns (progressive disclosure, compression, routing, retrieval evolution, tool management) that map to existing data engineering patterns.
• Context Engineering: Improving AI by Moving Beyond the Prompt (CIO) — Anthropic’s definition: “considering the holistic state available to the LLM at any given time.” Notably makes zero reference to data modeling as a precursor — the gap this piece fills.
• From Vibe Coding to Context Engineering (MIT Technology Review) — The mainstream arrival of the term in late 2025.
• 2026 Data Predictions: Scaling AI Agents via Contextual Intelligence (SiliconANGLE) — 89% of organizations report pain points around data modeling; only 5% use semantic models. The infrastructure gap context engineering claims to fill already has a name.

Connected Past Issues

• SC E05 — Analytics Crafting a Way Forward — The craft thesis is the foundation. Context engineering is craft, not engineering-by-numbers.
• SC E07 — Data’s Secret Sauce — “The value isn’t in the recipe — it’s in knowing which recipe to use, when, and why.” This is the one-sentence version of the context engineering argument.
• SC E08 — DPIM Framework — The four-dimension model maps directly to context engineering concerns.
• SC 014 — The Good, The Bad, and The Ugly (dbt) — State management and manifest-based context is context engineering at build time.
• SC 016 — Data Repair Work — (if applicable) The repair/maintenance mindset applies to context maintenance.