The Job Nobody Has Yet
There is a role that does not exist in most enterprises right now.
It is the most important AI role you have not hired for. It does not require a PhD. It does not require a machine learning background. It requires a specific kind of architectural thinking that sits somewhere between information design, systems engineering, and organizational strategy.
The role is Context Architect. And by the end of 2026, the organizations that built this function will look back at the ones that didn't the way we now look back at companies that had no cloud strategy in 2015.
What Changed and Why It Matters Now
For two years, the dominant skill in enterprise AI was prompt engineering. Write a better instruction. Add examples. Adjust the tone. Get a better output. That framework made sense when AI interactions were simple, single-turn exchanges. Ask a question. Get an answer. Improve the question.
In 2026, that framework is insufficient. Not obsolete as a skill. Insufficient as a complete strategy.
Andrej Karpathy, one of the architects of modern AI, put it precisely in June 2025: "The LLM is like the CPU, and its context window is like RAM." The context window is the model's working memory. Everything the model can reason about during a single response has to fit inside that buffer before the first word of output is generated. Prompt engineering optimizes one layer of that buffer. The instruction you write. Context engineering optimizes all of it. What goes in, what stays out, in what order, from what source, at what point in the workflow.
The distinction sounds technical. The consequences are organizational. And the consequences arrived nine days ago.
The Regulation That Made This Urgent
On August 2, 2026, the EU AI Act's full enforcement framework went live.
Article 10 of the Act requires enterprises deploying high-risk AI systems to document data governance practices across their AI infrastructure. Deployers must maintain logs for a minimum of six months. They must conduct Fundamental Rights Impact Assessments before first deployment. They must demonstrate human oversight mechanisms that are operational, not theoretical.
The penalties are not symbolic. Violations of high-risk obligations carry fines up to 15 million euros or 3% of total worldwide annual turnover. Deploying a prohibited system carries fines up to 35 million euros or 7% of global revenue. For context, 7% of Google's revenue is approximately $14 billion. The Act applies extraterritorially. If your AI system serves EU customers, touches EU residents' data, or is embedded in products sold in EU markets, the obligation follows regardless of where your company is incorporated.
Here is the question that the EU AI Act is now legally requiring enterprises to answer: what did your model see when it made that decision?
That is a context engineering question. Not a model question. Not a prompt question. A context question. What information was in the buffer. Where it came from. What was excluded. What the retrieval logic prioritized. What the governance layer permitted.
The enterprises that built a context architecture before August 2, 2026 can answer that question. The ones that didn't are now scrambling to reconstruct a paper trail for decisions their AI systems have already made.
The Science Behind the Urgency
In July 2025, researchers at Chroma published a technical report called "Context Rot: How Increasing Input Tokens Impacts LLM Performance." They tested 18 frontier models including GPT-4.1, Claude 4, Gemini 2.5, and Qwen3 across controlled experiments at increasing context lengths.
The finding was unambiguous and universal. Every single model tested gets measurably worse as input length increases. Not some models. Not most models. All 18. Across every model family tested.
The degradation is not a cliff at the context window limit. It is a continuous decline that begins well before the window fills. A model with a 200,000 token context window can show significant accuracy loss at 50,000 tokens of input. A 1 million token window does not reliably reason across 1 million tokens. The marketing page says one thing. The peer-reviewed research says another.
For coding agents specifically, context rot is the primary production failure mode. Not model capability. Not reasoning ability. The models are capable enough to solve the problem when their context stays clean. The problem is that context does not stay clean. Agents accumulate noise during search, exploration, and backtracking. That noise directly degrades every subsequent output.
The practical consequence: Gartner forecasts that 40% of enterprise AI applications will integrate task-specific agents by the end of 2026, up from less than 5% in 2025. The same Gartner analysis predicts that over 40% of those agentic AI projects will be cancelled by 2027. The reason cited is not model quality. It is poor context management. Agents fed fragmented data, deployed on broken workflows, operating without the institutional knowledge they need to act well.
The cancellations are already starting. They are just not being reported as context failures. They are being reported as AI disappointments.
What Context Engineering Actually Is
Context engineering is the discipline of deciding exactly which information earns a place in an AI agent's context window at each step of its work, and what you deliberately keep out.
It operates across six layers that most enterprise AI deployments manage poorly or not at all.
The system instructions layer defines the model's role, constraints, and operating rules. Most enterprises write this once during deployment and never revisit it. The instruction that worked for a single-query chatbot is often wrong for an agentic workflow running dozens of sequential steps.
The memory layer manages what the model retains across sessions and what gets compressed or discarded. Production memory systems maintain both short-term session context and long-term persistent memory, with a compaction step that condenses older turns into summaries before the window fills. Enterprises running agents without a memory architecture are handing the model a notebook that fills up mid-task and then silently starts losing pages.
The retrieval layer controls what information gets pulled from external sources and injected into the context at the moment it is needed. Retrieval Augmented Generation, RAG, sits here. The architecture question is not whether to use RAG but how to retrieve the right information at the right granularity without flooding the window with noise that triggers context rot before the task is complete.
The tool definitions layer specifies what the agent can call and how. Tool sets that cover too much functionality or create ambiguous decision points force the model to burn reasoning capacity deciding between near-duplicates rather than completing the actual task.
The conversation history layer manages accumulated turns in a multi-step workflow. Every tool call, every retrieved document, every intermediate result accumulates in the window. Without active management, the history layer becomes the primary source of context rot.
The output structure layer defines what format the model should return its results in. Poorly structured output from one agent step becomes poorly structured input to the next. In multi-agent architectures, output structure failures compound across the pipeline.
Most enterprises manage none of these layers deliberately. They write a system prompt, connect a retrieval pipeline, and ship. The result is an agent that works in the demo and degrades in production, exactly as the Chroma research predicts, for exactly the reasons the Gartner cancellation forecast describes.
The Organizational Problem Nobody Is Naming
Here is the structural issue underneath the technical one.
Context engineering is nobody's job.
The model selection decision has an owner. Usually the CTO or a VP of AI. The prompt writing has an owner. Usually the engineering team or a dedicated AI team. The data pipeline has an owner. Usually data engineering or platform.
But who owns what goes into the context window, when, from where, in what order, governed by what policy, documented against what regulatory requirement?
In most enterprises, the answer is: nobody specifically. The decision gets made implicitly by whoever is closest to the deployment. Which means it gets made inconsistently, without governance, without documentation, and without any mechanism to answer the regulator's question after the fact.
This is not a technical failure. It is an organizational design failure. And it is the same failure that produced the cloud waste crisis of 2018, the tokenmaxxing crisis of 2026, and every other AI deployment problem that turned out to be a governance problem wearing a technology mask.
The function that needs to exist is a Context Architecture practice. A small team, in some organizations potentially a single senior hire, responsible for designing and governing the information architecture that feeds every AI agent in the enterprise. What data sources are authorized. What retrieval logic is approved. What compression strategies are in use. What governance documentation exists for each system. What the audit trail looks like when a regulator asks.
82% of IT and data leaders now agree that prompt engineering alone is no longer sufficient to power AI at scale. 95% of data teams plan to invest in context engineering capability in 2026. The investment is happening. The organizational structure to receive it largely does not exist yet.
What This Means for Your AI Operating Model
The MAO Framework that AndMaverick uses to design enterprise AI systems has always treated context as a first-class architectural concern. Not a prompt detail. Not a deployment afterthought. An explicit design decision at the Model layer that determines everything that happens at the Action and Orchestration layers downstream.
Context engineering sits inside the Model layer. But its consequences propagate upward through the entire operating model. An agent with a poorly governed context window produces unreliable outputs. Unreliable outputs embed into workflows at the Action layer and produce wrong decisions at scale. Wrong decisions at scale, without governance documentation, become regulatory exposure at the Orchestration layer.
The EU AI Act made that chain of consequences legally consequential nine days ago.
The organizations that already have a context architecture have a compliance answer, a cost advantage from cleaner context meaning less token waste, and a quality advantage from agents that do not rot in production.
The ones that do not have one are not just behind on a technical capability. They are behind on a governance obligation that is now enforceable.
The job nobody has yet is the job that needs to exist before the end of this quarter.
Andrew Quillen is the founder of AndMaverick, a global Enterprise AI Orchestration consultancy. The MAO Framework is designed to build the governance architecture that context engineering requires at enterprise scale. To continue the conversation, visit andmaverick.com.
