Context Engineering Is the Core Competency Nobody Is Teaching

Prompt engineering was a workaround. Context engineering is the actual discipline. Here’s what 8 months of building production agents taught me.

Somewhere in the past 18 months, “prompt engineering” became a punchline.

Not because it wasn’t useful. Getting consistent output from an LLM by crafting careful prompts is a genuine skill. But as AI agents moved from chat interfaces to production pipelines, the prompt stopped being the thing that determined whether agents worked. Something else did.

Context engineering. The discipline of architecting everything an AI agent knows: not just the prompt, but the entire information ecosystem it operates within.

QCon London had a dedicated session on it in March 2026: “Context Engineering: Building the Knowledge Engine AI Agents Need.” Martin Fowler published on it. Anthropic’s 2026 Agentic Coding Trends Report named it a core competency for teams working with AI agents. Gartner reported a 1,445% surge in multi-agent system inquiries from Q1 2024 to Q2 2025.

The term is catching up to a practice that developers who’ve been building production agents have been doing for a while, without a unified name for it.

This is what I’ve learned building production agents as a solo developer over 8+ months.

Why Agents Fail (Hint: It’s Not the Model)

The most common debugging session for AI agents in production goes like this: the agent did something wrong. You look at the model. The model is fine - you can reproduce the correct behavior by feeding it the right context manually. The failure happened because the agent ran without context it needed.

Context starvation is the root cause of most agent failures in production.

The frontier models available in 2026 are genuinely capable of most tasks you’d assign them. The difference between an agent that works reliably and one that fails unpredictably is almost always the richness and accuracy of the context it operates on.

This shifts the design problem significantly. You’re not primarily asking “can the model do this?” You’re asking “does the agent know what it needs to know, at the right time, in the right format, with the right constraints, to make the right decision?”

That’s a different problem. It’s a systems design problem, not a model selection problem. It’s context engineering.

A Taxonomy from Production

After 8+ months of running AI agents in production (content pipelines, research workflows, data processing, agentic coding) I’ve come to think about context in three layers.

Layer 1: Static Context

Static context is what an agent always knows. It doesn’t change between runs. It doesn’t get retrieved. It’s loaded into the agent’s operational environment at initialization.

The primary vehicles for static context:

System prompts - the foundational instruction set that shapes the agent’s behavior, tone, decision heuristics, and constraints
CLAUDE.md files (or equivalent configuration files) - operational intelligence documents that tell agents about the specific environment they’re operating in: what categories to work in, what scoring methodologies to apply, what rules are non-negotiable
Tool definitions - the descriptions of what tools the agent can use and what they do, which directly shape the agent’s reasoning about when and how to use them
Behavioral constraints - explicit statements of what the agent should not do, which tend to have higher ROI than statements of what it should do

The CLAUDE.md file in every pipeline I run is static context engineering. It answers, in advance, questions the agent would otherwise get wrong: What are the categories we publish in? What platforms are we writing for? What’s the scoring methodology? What are the non-negotiable rules? Every line of that file is preventing a class of failures.

Layer 2: Dynamic Context

Dynamic context is what an agent retrieves per task. It changes every run because the state it reflects changes.

The primary vehicles for dynamic context:

Retrieved documents via semantic search or RAG - the most common form, and the one with the most documented quality problems
Codebase state - current file contents, recent git history, dependency versions, test results
External data - live API responses, database queries, real-time information
Memory from previous runs - what the agent did last time, what decisions it made, what it learned

The quality principle here is absolute: garbage in, garbage out applies harder for AI agents than for any prior system. A language model will generate confident, coherent output from low-quality retrieved context. The output will be wrong, but it will look right. This is worse than the traditional garbage-in scenario where bad input produces obviously bad output.

Dynamic context engineering means taking responsibility for the quality, relevance, and freshness of what the agent retrieves - not just assuming that semantic search will return the right thing.

Layer 3: Behavioral Context

Behavioral context is how an agent decides what to do with what it knows. This is the most neglected layer and, in my experience, the highest-ROI investment.

The primary vehicles for behavioral context:

Permission scopes - what tools and data sources the agent can access, which directly constrain what actions it can take
Escalation rules - criteria that trigger human review instead of autonomous action; the boundary between what the agent decides alone and what it surfaces for judgment
Output constraints - format requirements, length limits, tone specifications, and structural rules that shape what the agent produces
Priority hierarchies - when the agent encounters competing objectives, what wins?

Most agent failures in production come from undefined behavioral context. The agent had the static context. It retrieved good dynamic context. But it didn’t have a clear framework for what to do in the specific situation it encountered. It improvised. The improvisation went wrong.

Writing explicit behavioral context (“when X happens, do Y, not Z”) is tedious. It also prevents the class of failures that are hardest to debug after the fact.

The Build-in-Public Version

I’m going to be specific, because I think the abstract framework is less useful than concrete examples.

Here’s a behavioral context rule from an actual production pipeline:

“Topics scoring 75+ get graduated to content generation. Topics scoring 50-74 get refined with a better angle. Topics scoring < 50 get killed. Max 3 graduated topics per run. Depth over breadth - one great piece beats four mediocre ones.”

That’s behavioral context. Without it, the agent would make its own judgment about how many topics to graduate. Sometimes that judgment would be good. Sometimes it would produce six pieces of mediocre content because “more seems better.” The rule eliminates the decision.

Here’s a static context example from a tool definition:

“Only graduate topics where we have AUTHORITY - things we actually do: AI Governance, Data Compliance, Data Engineering, Databricks, Mercedes-Benz, Atlanta GA, Trending AI news.”

Without that constraint, the agent would evaluate topics based on trend momentum alone. With it, the agent applies an authority filter that’s invisible to a pure trend analysis, and produces content that’s qualitatively different because it comes from genuine experience.

These aren’t clever prompts. They’re operational decisions encoded as context.

What Context Engineering Looks Like as a Practice

The discipline, as I practice it:

Map what the agent needs to know. Before writing a single line of prompt, document the decisions the agent will face, the information those decisions require, and where that information lives. This is the requirements document for context engineering.

Invest disproportionately in constraints. Positive instructions (“do X”) are necessary. Negative constraints (“don’t do Y”) are where most agents break. Invest more in constraints than in affirmative instructions, and document the edge cases that triggered each constraint.

Treat context as a first-class artifact. Your CLAUDE.md files, system prompts, tool definitions, and behavioral rules should be version-controlled, reviewed, and maintained like code. They are the source of truth for how your agents behave.

Test context changes like code changes. When an agent starts failing, update the relevant context layer and verify the fix. When an agent succeeds unexpectedly well, understand why - often it’s because the context was particularly rich.

Plan for context staleness. Static context gets stale. The rules you write today reflect the decisions you’ve made today. As your agents operate in production and you encounter new failure modes, your static context needs to be updated. This is ongoing maintenance, not a one-time setup.

The Career Implication

Context engineering is becoming a hiring criterion.

Anthropic’s 2026 Agentic Coding Trends Report is explicit: teams working with AI agents need fluency in “agent orchestration, prompt engineering and context design, and AI evaluation.” The QCon London session signals that senior engineers are now expected to understand this at the conference-talk level.

For individual contributors building AI products, it’s the skill that determines whether you can ship reliable agents or just impressive demos.

For teams deploying agents at enterprise scale, it’s the design discipline that determines whether those agents can be governed, audited, and trusted, or whether they’ll be in the 53% that require significant rebuilds.

The models are good. They’re getting better. The bottleneck on AI agent quality has shifted from “can the model do this?” to “does the agent know what it needs to know?”

Context engineering is the practice of answering that question systematically, before production finds out the answer the hard way.