The field of AI collaboration is maturing fast enough that the vocabulary hasn't kept pace. Most practitioners conflate three distinct disciplines — 🏷️#context-engineering, memory engineering, and harness engineering — because they all live in the same general territory: shaping what an AI knows, how it behaves, and what it can do. But they operate at different layers of the stack, solve different problems, and require different skills. Conflating them produces muddled architectures and missed leverage.
What Context Engineering Is
Context engineering is the practice of shaping what an AI knows within a single session. It governs the active window — what's loaded, in what order, at what token weight, and how it frames the model's reasoning for this particular task.
Every message you send is a context engineering decision. So is your system prompt. So is the choice to retrieve a document before asking a question, or to summarize prior conversation before handing off to a subagent. Context engineers ask: What needs to be true in this window for the model to reason well right now?
The key constraints are:
- Recency bias — models weight later content more heavily
- Token budget — everything competes for a finite window
- Interference — conflicting instructions or noisy content degrades performance
- Priming effects — early framing shapes the entire response
Good context engineering is compositional. It pulls the right memos, formats, personas, and examples into coherent signal at the moment of inference.
What Memory Engineering Is
Memory engineering is the practice of persisting, organizing, and retrieving knowledge across sessions. It is the infrastructure layer beneath context — the system that decides what gets stored, how it's structured, and what gets surfaced when.
Where context engineering answers "what does the model know right now," memory engineering answers "what does the system know at all, and how does it become available?"
This includes:
- Storage architecture — flat files, vector databases, graph databases, structured memo systems like MythOS
- Write discipline — what gets captured, at what granularity, in what form
- Retrieval design — keyword search, semantic search, tag-based filtering, mention traversal
- Decay and maintenance — what gets updated, deprecated, or pruned over time
Memory engineering is where knowledge compounds. A well-engineered memory system turns a thousand conversations into a coherent external brain. A poorly engineered one turns them into noise.
The key failure modes are under-capture (things that should be stored aren't), over-capture (everything is stored and nothing is findable), and structure collapse (information exists but can't be retrieved in the right shape at the right time).
What Harness Engineering Is
Harness engineering is the practice of shaping the environment in which an AI operates — the tools it can call, the permissions it holds, the workflows it executes, the scaffolding that surrounds inference. If context engineering is about the window and memory engineering is about the store, harness engineering is about the execution environment.
This includes:
- Tool access — what MCP servers, APIs, and functions are available
- Permission models — what the agent can do autonomously vs. what requires human approval
- Workflow orchestration — how tasks are decomposed, delegated, sequenced, and reported
- Supervision architecture — how human oversight is structured across parallel or long-running agents
- Failure handling — what happens when a tool call fails, a permission is denied, or a subagent goes off-track
Harness engineers think in systems and failure modes. They design for the 95th percentile case, not just the happy path. The discipline borrows more from DevOps and software architecture than from prompt craft.
The key failure modes are over-autonomy (the agent acts where it shouldn't), under-capability (the agent can't do what the task requires), and brittleness (the workflow works until something unexpected happens, then fails catastrophically).
Why the Distinction Matters
These three disciplines compound on each other when done well — and they undermine each other when muddled.
A model with a brilliant context engineering strategy but poor memory architecture will give great answers in session and forget everything between them. A model with rich memory and no harness discipline will surface the right knowledge but be unable to act on it reliably. A model with powerful tool access but weak context engineering will have the capability to execute and the judgment to fail.
The practitioner who masters all three builds something that approximates genuine augmentation: a system that learns, reasons, and acts — compounding over time rather than resetting with every conversation.
Most current AI tooling bundles these disciplines together under the label "prompting" or "agent design," which obscures what's actually being optimized. Naming them separately creates room to diagnose failures precisely and allocate attention correctly.
The MythOS Model
MythOS was built as a memory engineering system first — a structured external brain where knowledge is captured, organized, and retrievable. The move into context engineering came second: the get_context protocol, augmentation memos, project context memos, and tag-based retrieval are all mechanisms for pulling the right memory into the active window at the right time.
Harness engineering is the current frontier: designing the agent workflows, permission models, and supervision architecture that let BrianBot act with appropriate autonomy across long-running tasks.
The three layers aren't sequential — they evolve together. But the architecture is cleaner for knowing which layer a problem lives in.