A year ago I spent my time choosing databases and drawing boundaries between services. I still do that. But the highest-leverage design work I did last quarter wasn't an architecture diagram. It was deciding what an agent gets to see before it starts a task.
That surprised me. It shouldn't have. When a language model does the work, the model's view of the world is the system. Get that view right and mediocre prompts produce good code. Get it wrong and the sharpest prompt in the world produces confident nonsense. People call the wrong-view failure "hallucination," which makes it sound like a model defect. Most of the time it's a design defect: we never showed the model the thing it needed, so it made one up.
That realization has a name now, context engineering, and it's quietly becoming the part of the job that decides whether an AI feature works.
Prompting is a sentence. Context is an architecture.
Prompt engineering is about phrasing one request well. Useful, but small, and increasingly automated away.
Context engineering is about designing the entire information environment a model operates in: what it knows, what it can look up, what it remembers from three steps ago, and what you deliberately keep out. That's not a wording problem. It's a systems problem, with the same shape as the ones I've worked on for a decade. What data does this component need? Where does it come from? What's the cost of moving it? What happens when there's too much?
Swap "component" for "model" and you've described my week.
The context window is a memory hierarchy
The mental model that unlocked this for me: treat the context window like RAM, and everything else, your database, your docs, your vector store, as disk. The model computes over what's in RAM. Your job is deciding what gets paged in, and when.
Two failure modes fall straight out of that framing.
Starvation. The model doesn't have what it needs, so it guesses. The fix is rarely a better prompt; it's retrieval. Pull in the schema, the relevant module, the conventions doc, the last three messages that matter.
Flooding. You dumped everything in "to be safe," and now the signal is buried. This one is less obvious and more common. Models get measurably worse as the window fills with marginally relevant tokens; the important instruction sitting at position 400 of 900 gets skimmed. More context is not more intelligence. Past a point it's noise you're paying for, twice, once in dollars and once in quality.
Good context engineering is the constant negotiation between those two. Enough, and no more.
What it looks like in practice
Building LaraCopilot's agent pipeline, most of our quality wins came from context work, not model swaps or prompt tweaks. A few patterns that earned their keep:
A project brief, written like an onboarding doc. The single most valuable artifact we have is the document each agent reads first: conventions, module boundaries, the three things this codebase does that would surprise a new hire. It reads like something you'd hand a person on day one, because that's exactly the job it does. Curating it is design work, and it's never finished.
Retrieval scoped to the task, not the repo. Feeding an agent the whole codebase is flooding with extra steps. We pull the slice a task actually touches, the target module, its tests, its direct dependencies, and leave the rest on disk. Smaller window, better output, lower bill.
Compaction over accumulation. In a long agent run, raw history is mostly dead weight. Instead of carrying every tool call, we summarize: "explored the auth module, found the guard in X, tests live in Y." The model keeps the conclusions and drops the transcript. Long agent runs got noticeably more reliable once we stopped hoarding history.
Format as a first-class decision. The same facts land differently as prose, as JSON, as a diff. Structure the payload so the important thing is impossible to miss, and errors read like nudges, not dead ends. That's interface design, aimed at a model instead of a person.
Why this is architecture, not prompt-fiddling
Here's the part I'd underline for anyone who thinks this is a soft skill. Every context decision has the same tradeoffs as classic system design. Retrieval is a caching problem: what's hot, what's cold, when do you invalidate. Compaction is lossy compression: what can you throw away without losing the thread. Scoping is a boundary problem, the same coupling-and-cohesion questions we've always asked, now asked about what a model can see.
The engineers who are good at this are the ones who were already good at drawing boundaries and reasoning about data flow. The skill transferred. It just found a new consumer.
Where I've landed
I don't think prompt engineering was ever going to be a durable discipline; it's a phrasing skill, and models keep getting better at meeting us halfway. Context engineering is the opposite. As models get more capable, the leverage moves further toward what you feed them, because a smarter model does more with a well-designed environment and is wasted on a starved or flooded one.
So I've stopped treating "what does the model see" as a prompt detail and started treating it as the architecture it is. Diagrams, boundaries, data flow, budgets. The old discipline, pointed at a new kind of machine.
I'm building LaraCopilot, an AI development platform for Laravel, and writing about agentic systems and MCP as I go. If you're designing context for your own agents, email me. I usually reply within a day.