SecondBrain
Ask the Brain
Index/Conceptupdated Wed Jun 24 2026 08:00:00 GMT+0800 (Philippine Standard Time)

Context Engineering

context-engineeringretrievalgovernanceagentslifecycletacit-knowledge

Context Engineering

The discipline of getting the right data to the model at the right time, with the right permissions, in the right shape — at runtime.

"A model is only as good as the context it can access." — Context Engineering and GraphRAG (IBM Technology)

Per Martin Keen, model intelligence is no longer the bottleneck for most use cases. Context is. Context engineering is the infrastructure problem of fixing that.

Four pillars (per IBM video)

  1. Connected access — visibility across the data estate; zero-copy federation (query data where it lives; preserve original ACLs); always fresh
  2. Knowledge layer — entity resolution, relationships, hierarchies, decision traces, institutional knowledge
  3. Precision retrieval — filter by intent, role, time, policy. "Better context is not more context — it's more precise context."
  4. Runtime governance — enforced live at retrieval time AND response time. Can the agent query this? Should this result be included given who's asking?

Worked example

"Prep me for the client meeting tomorrow."

  • Bad: model returns a beautifully formatted but generic meeting template
  • Good: pulls open support tickets (relevant — known issue), pulls deal history (relevant — renewal coming), excludes internal pricing (governance — your role doesn't have access)

The difference isn't model intelligence. It's the system around the model.

How this maps to the LLM Wiki Pattern

The Second Brain itself is a context-engineering system:

Pillar Realization in this wiki
Connected access raw/ collection + index.md
Knowledge layer Entity / concept pages + <span class="deadlink" title="Not published">wikilinks</span> graph
Precision retrieval Index-first lookup, frontmatter filtering, source-type categorization
Runtime governance CLAUDE.md schema + page-level sources: provenance

This is not coincidence — Karpathy's wiki pattern is one realization of context engineering, optimized for human curation in the loop.

Adjacent concepts

  • RAG — the simplest precision-retrieval mechanism (vector similarity)
  • Agentic RAG — iterative retrieval inside the loop
  • GraphRAG — graph-navigation retrieval
  • Context compression — summarize/rank to maximize signal in the window
  • Context Development Lifecycle — Patrick Debois's Generate → Evaluate → Distribute → Observe loop. Process counterpart to Keen's architectural four-pillars view.
  • What an Enterprise Context Layer Is (Prukalpa) — enterprise-scope view: substrate (data + semantics + skills) plus five capabilities (mining, lifecycle, learning, activation, governance). Extends the discipline past prompts/skills into business artefacts (glossaries, ontologies, sales playbooks).

Four lenses worth holding together

  • Architecture (IBM, Martin Keen) — the four pillars above. What contextual systems must be made of, at runtime.
  • Lifecycle (Tessl, Patrick Debois) — the Context Development Lifecycle. How you maintain context as a discipline over time, with evals, packaging, and observability. Patrick's coda: "LLMs are just the engine. If you give the engine the wrong fuel, which is context, they're not going to perform."
  • Enterprise scope (Prukalpa) — the context layer decomposed into substrate + capabilities across the whole organisation's tools and artefacts. Scopes the discipline past code-context into business-context (metrics, ontology, playbooks).
  • Tacit Knowledge (Economist, 2026-06-27) — Teaching AI How People Work Is Fraught with Problems (Economist) adds the epistemic floor: the substrate the other three lenses assume may not exist in codified form yet and may be actively withheld by the workers who own it. The Polanyi frame: "We can know more than we can tell." The three-route capture taxonomy (corpus → video → keystroke tracking → expert rating) is where extraction happens, each with its own political and technical failure mode.

The four views compose: pillars describe what the runtime system needs; the lifecycle describes how you keep building it; the enterprise-scope view describes what the substrate has to include to serve the whole firm; the tacit-knowledge lens describes what has to be extracted from unwilling humans before the substrate exists at all.

Sources