Context as Code

Intro to Context as Code

William Warne

Software Engineer | Fractional CTO | Founder

The missing layer

Infrastructure as Code standardised deployment. Data Contracts standardised pipelines. There is no equivalent yet for how we work and think—the knowledge, rules, and process that both people and AI need to do their jobs. That layer is largely missing. So you model your knowledge once in your head or in docs, then re-spec it for Claude, for Cursor, for your RAG stack, for your runbooks. Every ecosystem wants context in its own shape. And when AI fails, it’s often not the model. Industry data pins roughly 40% of AI project failures on poor or irrelevant context, not on model quality. Context as Code is the name for treating that layer as a first-class, portable asset—the same way we treat infra and data.

What Context as Code is (and isn’t)

It is: A portable, versioned, testable representation of organisational knowledge and process that can be executed by multiple AI ecosystems. One body of context—docs, runbooks, standards, decision rules—that Cursor, Claude, a pipeline, or a human can consume. It sits between raw knowledge (scattered docs, tribal knowledge, workflows) and execution environments (IDEs, agents, APIs). You own it in your repo; you don’t re-author it per tool.

It is not: Just RAG (RAG retrieves blobs; it doesn’t encode when a rule applies or who owns it). Not just prompt engineering (that’s tactical—one prompt; context engineering is the whole information environment). Not just “upload your docs” (that’s ingestion, not structure or portability). Not just agent frameworks (they run the agent; they don’t define the canonical context the agent should ground in). All of those matter. None of them are the missing layer.

One cut that helps: Canonical context is “what we decided”—docs, runbooks, packs, standards. Agents ground in or retrieve it. Memory is “what we learned”—session state, user preferences, episodic recall. Memory layers (e.g. Mem0, Anthropic Memory) complement canonical context; they don’t replace it. Context as Code is about the first. You build and own the canonical context; you plug in memory where you need it.

Five gaps: what goes wrong without it

When the context layer is missing or ad hoc, these are what you actually run into.

  1. Vendor gravity. Claude has MCP and plugins; OpenAI has Agents SDK and tools; Cursor has rules and skills. None answer: How do I model my knowledge once and reuse it everywhere? You rewrite per ecosystem.

  2. Descriptive, not operational. Most orgs rely on PDFs, Notion, Confluence, tribal Slack. Even when you add RAG, it retrieves blobs of text. It does not encode decision rules, exceptions, escalation logic, confidence levels, or ownership. Knowledge stays descriptive. The model can’t reliably “do the right thing when Y breaks” because that’s not in the context as something executable.

  3. No exchange format. Claude Skills ≠ OpenAI Agents ≠ Gemini tools. Prompts are brittle and non-portable. There is no Terraform for infra or OpenAPI for APIs equivalent for “how we do X” or “what to do when Y breaks.” So you can’t share or import context across environments in a standard way.

  4. The wrong question. Many companies fail not from lack of data but from inability to answer: What context matters right now? Who owns this knowledge? How confident is it? When does it apply—and when does it not? Tools often retrieve everything and hope the model figures it out. That’s not context engineering; that’s hope.

  5. Trust and sovereignty. Enterprises and boutique firms fear context leakage and IP dilution. They want company-specific context in a vault or private registry—rules, skills, runbooks—so new hires point their tools at the company context without that data touching vendor clouds. A public marketplace of prompts doesn’t solve that.

Context engineering in 60 seconds

Context engineering is the discipline of designing and managing everything the model sees at inference time: system instructions, user prompt, conversation history, retrieved knowledge, tool schemas and outputs, guardrails. Not just the prompt—the whole information environment. Two consequences matter. First: the context window is a scarce resource. “Lost in the middle” is real; stuffing everything in degrades performance. So precision over volume. Second: design for minimal always-on context—a short core that’s always included—and put the rest behind reference or retrieval. Same idea as Context as Code: one source of truth, consumed on demand; not one giant blob in every request.

What good looks like: the progression

You can place yourself on this ladder. Context as Code sits at the top.

  1. No engineered context — Single prompt, no retrieval or memory.
  2. Static RAG — Embed → retrieve → generate. Good for simple Q&A.
  3. RAG + tools — Model can call tools; tool schemas and results are part of context.
  4. Agentic RAG — Model orchestrates retrieval (sub-queries, iteration). Better for complex questions; higher cost.
  5. Memory-augmented agents — Persistent memory across sessions; context assembly includes “what we know about this user/task.”
  6. Multi-agent with shared context — Handoffs use structured briefings (decisions, evidence, reasoning) so the next agent doesn’t lose context.
  7. Production context engineering — Versioned, auditable context packs; one body of context for many consumers; independent of any single vendor or runtime. That’s Context as Code.

The key architectural idea: independent context. Context is curated and stored in a tool-agnostic way (repo, markdown, knowledge store, packs) and consumed by different runtimes (Cursor, Claude, MCP client, pipeline). One source of truth; humans and agents both read it. No separate “AI context” that drifts from the docs.

Takeaways

  • Treat context as an artefact. Put it in the repo. Version it. Same files for humans and AI. When the process changes, update one place.
  • Separate “what to show” from “which client shows it.” Then you can add Cursor, Claude, or a pipeline without re-authoring. Open formats (markdown, JSON, MCP resources) and pack distribution make that possible.
  • Design for minimal always-on context. One-pager or short summary in every request; point to full docs or retrieval for the rest. Avoid stuffing the whole store into the context window.
  • Canonical context vs memory. Build and own the first (what we decided). Plug in the second (what we learned) where you need it. Don’t conflate them.
  • The missing layer is portability and methodology. Not “more RAG” or “better prompts.” A portable, versioned, testable representation of knowledge and process that multiple ecosystems can execute. That’s what Context as Code names.

The layer exists for infra and for data. It doesn’t yet for context. Context as Code is the practice of building it—so you stop rewriting per ecosystem and your AI fails less often for the right reason.

Context as Code — Structured context, packs, and methodology so your repo is the system of record. One source for humans and agents.