Prompts are a commodity, Context is the distinctive capability

I am going to say something that will annoy people.

Most AI advice for designers right now is dressed-up prompt engineering. We are still publishing prompt libraries, hosting prompt webinars, putting prompt checklists in our newsletters. Meanwhile, the rest of tech has long moved on. We see the consequence of that in client conversations: design teams stuck in workshops about "writing better prompts" while IT teams inside the same organization are already half a floor further, building something fundamentally different.

Time to set this straight on the substance.

The shift that has already happened outside design

Last year, Andrej Karpathy, Tobi Lütke and Simon Willison started pushing a new term to the front: context engineering. Anthropic adopted it as their official engineering framing. Gartner declared mid-2025 that context engineering is "in" and prompt engineering is "out". Datadog's 2026 State of AI Engineering report confirmed it with production data from thousands of customer environments: context quality, not model choice, is what determines whether an AI agent works in real life.

In design, we are still on prompts.

This is not a semantic debate. It is a structural difference.

Prompt engineering treats the instruction as the main variable. Write a better brief, get a better output. It works for demos and single-turn tasks. It breaks the moment you put an agent in production inside a real enterprise engagement, because the instruction is then just one input among many. Retrieved documents, tool outputs, conversation history, client facts, methodology references. All of them compete for the model's limited attention. The real engineering problem is deciding what enters that window, what gets compressed, what stays, and what gets cut.

Karpathy put it concisely: the model is a CPU, the context window is its RAM. The job is managing that RAM across time, across tasks, across stakeholders.

Why designers missed the shift

The design discipline has a long tradition with the word "context". Contextual design (Holtzblatt and Beyer, 1997). Context of use (ISO 9241). Situational context in service design. All three refer to human and situational context. None of these definitions has anything to do with the tokens entering an LLM at runtime.

That vocabulary collision is the first reason designers missed the shift. You hear "context engineering" and your brain maps it onto something you already know. The new concept doesn't register as new.

The second reason is audience. The early adopters were developer tooling companies: LangChain, Anthropic, Cognition, Weaviate. Their content is code-first, their audience is engineers. Designers don't read it, and the translation to design practice has not been made yet.

The third reason is positioning. Context engineering sits at the seam between engineering and methodology. Pure engineers treat it as tooling. Pure methodologists treat it as process. Enterprise design consulting is the discipline that naturally integrates both. And so far, no one in that discipline has claimed it.

Which I find odd, because this is exactly our territory.

What we built

We call the operationalization Context First Architecture. Two parts.

The stance: context gets designed before capability. The first question is not "which agent do I need" but "what does this agent need to know to produce output a senior consultant would put their name on". Capability without context produces generic AI demos. Context without capability produces expensive unused documentation. Both matter, with context leading.

The implementation: a three-layer Context Stack.

• The global layer holds our practice's identity, methods, and quality standards. Who we are. How we work. Which methodologies we apply. Rarely changes.
• The client layer holds enterprise context: brand tokens, regulatory posture, decision log, stakeholder map, system landscape. Changes quarterly, curated per engagement.
• The project layer holds today's reality: current sprint, open questions, active dependencies, the specific deliverable. Changes weekly.

Every layer is a codified markdown artifact. Versioned. Reviewable. Auditable. At runtime, all three layers compose into the working context the agent sees. Same agent, three contexts, enterprise-grade output.

On top of the Stack sits a four-tier validation protocol. Not every agent output carries the same risk. A commercial proposal for a board buyer is T1. A research summary for internal use is T4. Review depth, second-pair-of-eyes requirements, and escalation thresholds calibrate to the tier. That is what makes the architecture defensible in regulated industries. Honestly, it is also what makes it work. An architecture without governance is just a nice diagram.

What this means for practice leaders

Three implications matter.

First, prompts are commodity. Agents are becoming commodity. What competitors cannot copy is your codified methodology, your client-specific knowledge, and the discipline to keep both current. If you lead a practice, the real question is whether your methodology is codified well enough to serve as context. If it lives in the heads of senior consultants, it is not yet infrastructure. It is tacit knowledge, and tacit knowledge does not scale.

Second, governance beats novelty in regulated industries. Banks, pensions, healthcare, aviation. None of these will accept AI output without an audit trail. The Context Stack is the audit trail. Every output is traceable to the context that produced it. Every context change is versioned. This is not a feature. In regulated sectors, it is the entry condition.

Third, the window for naming this pattern is open but closing. DevOps got named between 2009 and 2013. MLOps between 2018 and 2022. Design systems between 2014 and 2019. In every case, the people who named the practice-level primitives in the first 24 months held the conceptual high ground for a decade afterwards. Context engineering was named in mid-2025. The primitives at the design-practice level are still unclaimed. That window closes within the next 12 to 18 months.

Where this goes

Context First Architecture is not a finished framework. It is a pattern we run at enterprise scale, validated across multiple engagements, and ready to be tested publicly. The thirteen-agent family, the four-tier validation protocol, the three-layer Stack, the governance overlay. All of it works. None of it is perfect, and some parts will almost certainly turn out to be wrong in ways I cannot see yet.

What it needs next is peer review. Other design and consulting practices running similar patterns, comparing notes, challenging the primitives. I am actively looking for that conversation. If you lead a practice and you are running into the same questions, how to operationalize AI across clients, how to govern output in regulated industries, how to move past prompt libraries, get in touch.

The AI industry has named the infrastructure. Our turn is now.