Context is infrastructure, not a prompt

Andrej Karpathy helped give the industry a better phrase for the work: context engineering. The useful shift is not that prompts stopped mattering. It is that the prompt is too small a unit of analysis. Agents do not succeed because a human found a clever sentence. They succeed when the right instructions, files, tools, history, examples, constraints, and proof requirements arrive at the right moment.

The prompt is not the system

Most teams still interact with agents as if the chat box is the system boundary. They paste a task, maybe paste a file, maybe add a paragraph about the codebase, then expect the model to infer the rest. That works for demos because demos are small. It fails in real repositories because engineering work is mostly hidden context: architecture decisions, naming conventions, test strategy, design tokens, release rules, security assumptions, and the difference between what is technically possible and what this team would actually ship.

A prompt can request behavior. Infrastructure makes behavior repeatable. That is the line. If an agent has to rediscover your repository, your standards, your workflow, and your definition of done every time a session starts, the team is paying a context tax on every task.

• The same setup work gets repeated in every session.
• Different agents read different files and make different assumptions.
• Old decisions disappear unless a human remembers to restate them.
• Review catches preventable drift instead of evaluating real trade-offs.
• Token spend rises because the agent loads too much or the wrong material.

Folder structure is becoming architecture

The folder-first movement is right about the substrate. Lyceum's Interpretable Context Methodology frames folder architecture as agent architecture: identity, routing, stage contracts, reference material, and working artifacts. Karpathy's LLM wiki idea points in the same direction from a knowledge-management angle: let the model maintain durable, interlinked Markdown so knowledge compounds instead of being re-derived from raw documents on every question.

The common idea is simple and important. The file system is not just storage. For agents, it is an interface. A folder tells the agent where it is. A Markdown file tells it what matters. A stage folder tells it what kind of work is happening. An output file preserves state between sessions. A version-control diff turns the context system into something a human can inspect and improve.

The folder is the control plane. The agent is the runtime.

Geist Labs agrees with the folder-first thesis, but our focus is narrower: engineering organizations. A writing workspace can tolerate some looseness. A production engineering workflow needs routing, ownership, verification, auditability, and cost control. That is why our context architecture centers on CONTEXT.md files.

CONTEXT.md is the routing layer

AGENTS.md is useful, but it should not become a dumping ground for every instruction anyone has ever wanted an agent to follow. The more global instructions you load on every task, the more you spend attention on irrelevant rules. The root instruction file should define the durable posture: what the repository is, how agents should behave, and what the non-negotiables are.

CONTEXT.md does the next job. It routes. It tells the agent which documents are relevant for a directory, which files must be read first, which files should be skipped, which workflow stage applies, and what evidence proves completion. In a small repo that may be one routing file. In a real organization it becomes recursive: every important workspace has its own local map.

Good context has layers

The reason this works is not mystical. It is ordinary systems engineering. Separate stable context from working context. Separate routing from execution. Separate references from outputs. Separate proof from claims. Once those boundaries exist, the agent does not need to guess which material is instruction, which material is source, which material is old, and which material is the current task.

• Identity defines the mission, standards, audience, and operating posture.
• Routing tells the agent where to go, what to read, and what to ignore.
• Stage contracts define what good work looks like in planning, implementation, review, verification, and release.
• Reference material holds stable knowledge: architecture, design systems, coding standards, examples, and runbooks.
• Working artifacts hold the current task: briefs, specs, diffs, review notes, screenshots, logs, and release notes.

This is the practical difference between context engineering and context dumping. Dumping says, "Here is everything, figure it out." Architecture says, "For this stage, load these inputs, follow this process, write this output, then prove it."

The business value is reliability, not neat files

Folder structure by itself is not the point. The point is that structured context changes the economics of agent work. Less irrelevant context goes into the model. Less session time is spent rebuilding state. Fewer outputs drift away from team standards. More of the workflow becomes inspectable by humans. Failures become diagnosable because you can trace an output back to the instruction, reference, artifact, or verification gate that shaped it.

That is where Geist Labs draws the category line. We are not selling prompt tricks. We are building Agent Context Architecture: repository-native context systems for workflow routing, review gates, eval loops, operational memory, and team adoption. The goal is not to make one engineer feel faster for an afternoon. The goal is to help an engineering organization turn AI coding into a repeatable capability.

A context system has a definition of done

The most important part of the system is the verification layer. Agents are fluent enough to sound finished before the work is actually finished. A real context system refuses to accept that. Each workflow stage should say what proof is required: tests, screenshots, logs, eval results, review findings, cost numbers, or human approval.

This is how teams move from individual prompting to an operating model. The context system tells agents how the organization works. The artifacts preserve what happened. The gates force evidence. The humans improve the source files when they see repeated failure patterns. Over time, the workflow compounds.

The best AI coding teams will not share prompts. They will share operating systems.

Context is infrastructure because it has all the properties infrastructure has: it is versioned, reviewed, maintained, reused, and relied on by everything above it. Models will keep changing. Agent tools will keep changing. The durable advantage is the system that tells those tools what to read, what to ignore, how to work, and how to prove they are done.