Context Engineering Is the Real Job Now — Notes From Running Agent Fleets Solo

Context engineering is the discipline of designing everything an AI agent knows at the moment it acts — the standing instructions it reads before every task, the reusable skills that encode how work gets done, the memory that persists between sessions, and the tools that determine what it can see and touch. Where prompt engineering optimizes a single request, context engineering optimizes the entire information environment the request lands in: what the agent is told, in what order, at what level of authority, and what it must never assume. It is the practical answer to the observation that agent failures are primarily context failures, not model failures (Towards Data Science).

That's the definition. Here's why I'm the one giving it: 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. Context engineering isn't a trend I read about. It'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 external framing 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 is context engineering, concretely? The four layers I actually run#

Definitions are cheap; running systems are not. Here is the real layered context architecture behind my fleet — not a diagram from a lab paper, the files on my machine, every one of them load-bearing daily.

The layers are ordered by authority. Global rules override project habits; project rules override skill defaults; memory records how conflicts were resolved last time. When an agent misbehaves, the debugging question is never "what's wrong with the model?" It's "which layer failed to say the thing I assumed was obvious?"

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 project 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.

The global layer above it does the same job for rules that must hold across every brand: language standards, execution behavior, what stack every build starts from. Two files, two scopes, zero repeated typing.

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.

This is the sharpest mental shift in the whole discipline: a prompt is spent when the run ends; a skill compounds. I've written the full breakdown of this layer in how CLAUDE.md and skills stop agent drift — if the table above is the map, that post is the street view of the two layers where most of the leverage lives.

Memory is context that survives the session#

The single biggest failure mode of agent work is starting cold. My memory layer is an index file — MEMORY.md — that links out to dated, single-topic files: this decision was made on this date for this reason, this approach is forbidden, this account belongs to this brand. A fresh agent reads the index, pulls only the entries relevant to its task, and continues my work instead of re-running last month's arguments.

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. I go deeper on the mechanics — index-plus-detail-files structure, dating discipline, what belongs in memory versus instructions — in the agent memory primer.

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 — it's why every entry in my memory files carries the date it was verified.
• 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.
• Layer confusion. Putting a per-project rule in the global file (now every brand obeys it) or a permanent constraint in a one-off prompt (now it evaporates at session end). The layered table above exists precisely because each kind of knowledge has exactly one correct home.

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.

1. Write the constitution first. Put standing rules, hard constraints, and forbidden claims in a persistent instructions file before you write a single prompt.
2. Split global from project. Rules that must hold everywhere go in the global file; brand- or repo-specific rules go in the project file. One home per rule.
3. 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.
4. Give it memory with expiry dates. Persist decisions and their reasons in an indexed memory file; stamp anything time-sensitive so stale facts get caught, not trusted.
5. Scope every tool. Connect only what the task needs, and make sure each tool returns signal, not a wall of noise.
6. Draw context boundaries between subagents. Decide exactly what each handoff passes forward — and what it deliberately does not.
7. Design for the edge of the window. Assume something will be dropped; make sure it's the least important thing, on purpose.
8. 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. Context engineering is the connective tissue: 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#

What is context engineering in one sentence?#

Context engineering is the practice of designing the full information environment an AI agent operates in — persistent instructions, reusable skills, cross-session memory, and scoped tools — rather than optimizing individual prompts.

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.

How is context engineering different from prompt engineering?#

A prompt is a single request, spent when the run ends. Context is the layered, persistent environment the request lands in — global and per-project instructions files, skill definitions, memory, and tool access. Prompt engineering tunes the question; context engineering builds and maintains the system that answers it the same way every time.

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.