There's a phrase making the rounds this month, and for once the hype matches the reality: context engineering has displaced prompt engineering as the discipline that actually determines whether an agent works. The framing I keep seeing — that "agent failures are primarily context failures, not model failures" — is the truest thing written about this work all year (Towards Data Science).
I run the infrastructure of five brands solo — content engines, e-commerce, ad factories, publishing pipelines, dashboards — through Claude Code, agent fleets, and scheduled loops. When I read that sentence I didn't think "interesting trend." I thought: that's the thing that has eaten most of my week, every week, for a year. Not writing clever prompts. Deciding what each agent gets to know, in what order, and what it must never assume.
So here's the operator's version of the story — not the framework diagram, the actual job.
Prompt engineering optimizes the question. Context engineering optimizes the room.
The cleanest definition I've seen: prompt engineering optimizes the question you ask; context engineering optimizes the conditions the question gets answered under. It's about "structuring information, defining relationships between data points, and establishing clear parameters for decision-making" (Towards Data Science).
Translated to my terminal: a prompt is one line I type. The context is everything that line lands in — the project instructions file, the skill definitions, the last twenty tool results, the file tree the agent just read, the memory it carries between sessions. The prompt is maybe 2% of what determines the output. The other 98% is the room I built for it to think in.
The number that makes this concrete: in a study of Microsoft's early-2026 rollout, engineers who adopted command-line coding agents merged roughly 24% more pull requests than they otherwise would have (arXiv 2607.01418). That lift doesn't come from better prompts. It comes from the harness — the context the agent operates inside. When people say a tool "made them faster," they almost always mean someone engineered good context around it.
What context engineering looks like when you're the whole department
I don't have a platform team maintaining a golden context pipeline. I am the pipeline. Here's where the work actually goes across a real week.
The instructions file is the constitution. Every project I run carries a CLAUDE.md — the standing rules an agent reads before it does anything. This is where drift dies. One example: one of my brands manufactures in a specific arrangement I must never overclaim. That constraint lives in the instructions file in plain language, so no agent — no matter how I phrase a one-off request — writes the claim I'm not allowed to make. That's not a prompt. That's context that holds across every session, forever, without me re-typing it.
Skills are packaged context, not packaged prompts. When I built the SEO/GEO engine that has 500+ articles live and publishing on a scheduled loop, the win wasn't a prompt. It was a skill file that encodes the on-page structure, the schema, the internal-linking rules, and the freshness step in one place. Every run inherits that context. I changed the conditions, once, and every future article got better.
Memory is context that survives the session. The single biggest failure mode of agent work is starting cold. A persistent memory file — who the user is, what was decided and why, what's forbidden — is the difference between an agent that continues your work and one that relitigates it. Multi-agent architectures now lean hard on this: an orchestrator coordinates specialized subagents, each with its own dedicated context, then synthesizes (Salesforce). Every one of those subagents is only as good as the slice of context it was handed.
Tools are context, and MCP made this explicit. By late 2025 there were more than 10,000 public MCP servers deployed — a standard way for agents to call tools and query data across vendor boundaries (Salesforce). Every tool I connect changes what the agent can see. A well-scoped tool is good context. A tool that dumps 400 lines of noise into the window is context poisoning, and it'll quietly wreck a run three steps later.
The failure modes nobody warns you about
Context engineering has its own catalog of ways to lose, and I've hit all of them:
- Context stuffing. More is not better. A window crammed with every file "just in case" makes the agent worse, not smarter. Curation beats accumulation every time.
- Stale context. A memory note that was true in March and quietly wrong by July is more dangerous than no note, because the agent trusts it. Dated facts and expiry discipline aren't optional.
- Silent truncation. When the window fills, something gets dropped — and the agent won't tell you which thing. If you don't design for what falls off the edge, the model will decide for you, badly.
- Cross-agent leakage. Hand subagent B the raw output of subagent A and you've imported A's mistakes as B's ground truth. Each handoff needs a clean, deliberate context boundary.
None of these are model problems. A better model doesn't save you from feeding it the wrong room.
A working checklist for engineering an agent's context
This is the actual sequence I run when I set up any new agent or loop. Steal it.
- Write the constitution first. Put standing rules, hard constraints, and forbidden claims in a persistent instructions file before you write a single prompt.
- Package repeatable work as a skill, not a prompt. If you'll do it more than twice, encode the structure once so every run inherits it.
- Give it memory with expiry dates. Persist decisions and their reasons; stamp anything time-sensitive so stale facts get caught, not trusted.
- Scope every tool. Connect only what the task needs, and make sure each tool returns signal, not a wall of noise.
- Draw context boundaries between subagents. Decide exactly what each handoff passes forward — and what it deliberately does not.
- Design for the edge of the window. Assume something will be dropped; make sure it's the least important thing, on purpose.
- Verify against the context, not the vibes. Check the output against the constraints you actually encoded, not against whether it "looks right."
I've written before about why verification is the real gap once agents reach production, and about how CLAUDE.md and skills are what stop agents from drifting. Context engineering is the connective tissue between those two: the constitution stops the drift, and the verification confirms the context held.
Why this is good news for one-person operations
The old story was that leverage came from headcount — more people, more context living in more heads. Context engineering inverts that. When the context is written down — in instructions files, skills, and memory — one operator can hold the working knowledge that used to require a team, and hand it to a fleet of agents that never forgets it and never has an off day.
That's the whole premise of how I work: one deeply technical-creative operator, engineering the conditions, and a fleet executing inside them. The moat isn't the prompt. Anyone can copy a prompt. The moat is the accumulated, curated, hard-won context — the rooms I've built for these agents to think in. I've made the case for what an AI systems builder actually does; this is the sharpest single answer. The job is engineering context.
FAQ
Is prompt engineering dead?
No — it's demoted. A clear prompt still matters, but it's a small slice of what determines output quality. As of 2026, the field has moved to context engineering, on the recognition that agent failures are mostly context failures, not model failures (Towards Data Science). Write clear prompts, but spend your real effort on the room they land in.
Do I need a big team to do context engineering well?
No, and that's the point. The whole discipline is about writing context down — into instructions files, reusable skills, and persistent memory — so it stops living in people's heads. That's exactly what lets one operator run work that used to need a department. The 24% pull-request lift from command-line agents (arXiv 2607.01418) came from the harness, not from adding staff.
What's the fastest way to start?
Write one instructions file for your most-repeated task — the standing rules and hard constraints — before you touch prompts. Then package the repeatable part as a skill so every run inherits it. Those two moves eliminate most of the drift I see people fighting with one-off prompts.
— Italo Campilii. If you're building something that needs this kind of operator, get in touch.