Context Is King: How to Serve It With Context Engineering

Introduction

Context engineering is the work of deciding what an AI agent sees before it answers, and I think it has become the main job of anyone who builds software with AI. Context is king, and you have to serve it properly. A model can only reason about what is in front of it, so whatever you put into its context window becomes its whole world.

This article is for tech leads and engineers who use an AI agent every day and feel that results get worse as projects grow. We show how context engineering works in our own AI systems: with Claude Code, in a shared skills repo, in a project management tool with its own memory, and in MDMA. You will get a definition, the reason vibe coding stops working, five layers of context we manage, and a short list of practices for production AI systems.

What Is Context Engineering (and Is It Replacing Prompt Engineering?)

Context engineering is the practice of choosing, structuring and limiting the information that goes into a model at each step. That covers instructions, tools, memory, documents and the results of earlier steps. The goal is simple: give the model exactly what it needs for the task, and nothing that pulls it in the wrong direction.

A Context Engineer Is a Software Developer With a New Job

People ask what a context engineer is and how much one earns. We do not think it is a new profession. Yesterday's software developers are today's context engineers (see our take on why AI does not replace software engineers), because the hard part of building with AI is the same as the hard part of software engineering: knowing what belongs in the system, where it lives and who can change it.

We will not quote a salary, because we have no reliable data for a role that mostly does not exist as a job title yet. What we can say is that the skills are familiar: naming things clearly, keeping one source of truth and cutting what is not needed.

Prompt Engineering vs Context Engineering

Prompt engineering is about how you word a single request. Context engineering is about everything around that request: which files, decisions, tools and history the models can reach when they read it. The first is a sentence, the second is a system.

So is one replacing the other? No. A good prompt is still one of the components of the context, but a perfect prompt cannot save an agent that sees the wrong data or too much of it.

Why Vibe Coding Breaks Down as the Context Window Fills

Vibe coding works well at the start of a project. The codebase is small, the whole conversation fits in the window, and the model can hold the entire application in view. You describe what you want, and it appears.

Then the project grows, and so does its complexity. Long contexts dilute attention, because the model has to spread it over more and more information. Old instructions get buried, contradicting facts sit side by side, and the agent starts to reason from whatever is closest or loudest. This is often called context rot, and it is why the same model that felt brilliant on Monday can feel careless on Friday.

A bigger window does not remove the problem. More room lets you add more, and adding more without a plan only makes the mess larger. The approach that works is context management: deciding what enters the window, when, and in what form.

The Five Layers of Context We Manage Every Day

There is no industry standard for context engineering layers, so the split below is our own. It is how we divide the problem in daily work, and each layer maps to real files and tools.

Instructions: CLAUDE.md and Skills

The first layer is what the agent is always told. In each repo, a CLAUDE.md file holds the rules for that project, and it stays short on purpose to protect the agent's attention.

Everything shared across projects lives in a private skills repo with around a hundred skills, grouped by role. A project links only the roles it needs, so a backend service never loads frontend conventions. A skill's description is the only thing the agent sees when it decides whether to load that skill, so we write descriptions as triggers, not summaries. The result is relevant context instead of all context.

Memory and the Project Brain

The second layer is what the agent should remember between sessions. In Claude Code that means memory files with one small fact each and the reason behind it.

In our project management tool, pm-helper, we built a project brain: a store of glossary terms, conventions, decisions and facts for each project. Only a small, fixed budget of it goes into the prompt on each turn, and the facts used most often rank first. It is dynamic context assembly in practice.

The agent can also search the whole brain when the answer is missing, and it can propose a new fact, but a person has to review and save it. Nothing is recorded silently.

Task State: Background Agents and Run Folders

The third layer is the state of the job in progress. For big tasks we hand work to background agents, each in its own git worktree, with a brief that is deliberately short. Our own rule says a brief over about 40 lines is a symptom, because everything in it competes with the real task for the agent's attention.

Long runs keep their state on disk instead of in the conversation. A run folder holds the plan, a handoff note and the reasons behind decisions, so the work survives compaction, a new session or a crash. We also use Lantern, our desktop app, to see what the agents changed as maps and explainers, so a person can review the work without reading all the source code.

External Data: The Information the Model Never Sees

The fourth layer is data that should not pass through the model at all. In MDMA, a document does not carry table rows or chart values written by the model. It names a data source and its parameters, and the host application returns the data. The model decides what to show, and our own system decides what is in it.

We wrote about the model side in structured LLM output without JSON schemas.

A catalog entry can describe the columns of a source, including whether a column is sensitive, so the agent knows what exists without seeing the values. Heavy processing stays in your infrastructure, next to the data. This is the cleanest form of context management we have: what the model does not see cannot be leaked, made up or misread.

When Conflicting Context Made Our Model Take Shortcuts

The fifth layer is the hardest, and the one where we learned the most: decisions. In project management, the same fact often lives in several places, and over time those places start to disagree. A decision gets changed in one document and stays old in another.

Without a settled truth, the model did not stop and ask. It picked something that looked reasonable and moved on. We only noticed when someone checked the result by hand, or pushed the model until it admitted it was not sure.

The reasoning was fine. The information underneath it was not.

LLMs like to take shortcuts, and conflicting context is an invitation to take one. That is why we built the brain.

Facts in it are attributed to the person who stated them, and they outrank the model's own assumptions. When new information contradicts a stored fact, the model has to flag it instead of choosing silently. Old facts are superseded, not deleted, so the history stays.

The decision process now happens first, with the agent and the team together, and the result is recorded once. Models make fewer wrong assumptions when there is one written answer and its source is named.

Context Engineering Practices for Production AI Systems

You do not need our setup to apply context engineering. These practices work with any of the AI tools you build or buy on top of large language models, from a coding agent to a chat feature in production.

• Keep instructions short and put them where they apply: one file per project, shared rules in one shared place.
• Load by relevance. If a rule matters for one kind of task, do not put it in every prompt.
• Store decisions, not conversations. A single sentence with a reason beats a long history.
• Set a budget for memory and let the most used facts win.
• Keep state outside the conversation, so a long task can survive a restart.
• Connect only the tools a task needs. Tools attached through the Model Context Protocol add their descriptions to the context too.
• Keep sensitive or large data out of the model and pass it through your own systems.

Evaluating generative UI frameworks for production?

We build AI agents and generative UI systems for fintech and proptech teams, and MDMA is the open-source format we ship for portable, model-authored interfaces with audit trails, PII redaction, and approval gates built in. If you are choosing a generative UI stack, contact us.

Matt Sadowski

CEO

Business email*

Full name

By sending this form I accept the terms of Privacy Policy *

Success!

Your message has been sent.

Our sales representative will contact you shortly.

Ok

Conclusion

I started with a simple claim: context is king, and your job is to serve it properly. In our experience, the biggest gains did not come from a better model or a cleverer prompt. They came from the plain work of deciding what the model sees.

The main takeaways:

• Context engineering means choosing and limiting what an AI agent sees, and software developers already have the skills for it.
• A prompt is one component of the context, so context engineering builds on prompt engineering instead of replacing it.
• Vibe coding stops working when the window fills with old, conflicting information, because models take shortcuts.
• Split your context into layers: instructions, memory, task state, external data and decisions.
• Keep data the model does not need out of its sight.

As a next step, pick one agent you use every week and write down everything it can see. Removing the first thing on that list is the fastest way to start.

Frequently Asked Questions

What is context engineering and how does it differ from prompt engineering?

Context engineering is the practice of selecting, structuring, and limiting the information (instructions, tools, memory, and data) - fed to an AI model at each step. While prompt engineering focuses on phrasing a single request, context engineering manages the entire system surrounding that request. Even a perfectly worded prompt will fail if an agent is overloaded with irrelevant or conflicting context.

Why does vibe coding stop working as projects grow?

Vibe coding works well at the start because a small codebase fits neatly into a model's context window. As the project expands, long contexts dilute model attention and create context rot, burying critical instructions alongside obsolete information. Simply expanding context window size does not fix this, as models tend to take shortcuts or hallucinate when forced to sift through unmanaged, noisy history.

What are the five layers of context engineering?

The five layers we manage in production are instructions, memory, task state, external data, and decisions. Instructions provide short, scoped rules and modular skills, while memory stores durable facts within a fixed token budget. Task state tracks in-progress execution outside the conversation history, external data bypasses the model to prevent leaks, and decisions establish an attributed, single source of truth.

Is context engineering a new job role or skill set?

Context engineering is an evolving discipline within software development rather than a completely new job title. The primary challenges in building reliable AI agents - establishing a single source of truth, structuring system inputs, and eliminating unnecessary complexity - are the foundational skills software engineers use every day. Developers who master context boundaries and dynamic data retrieval are already doing context engineering.

How do you get started with context engineering?

The fastest way to start is to select an AI agent you use regularly, list everything currently visible in its context window, and strip away the least necessary item. Moving forward, keep system instructions concise, load operational skills dynamically based on task relevance, and store discrete decisions rather than long conversational histories. Keeping heavy or sensitive data in your own backend infrastructure rather than feeding raw values into the prompt immediately improves agent accuracy.