From Prompt Engineering to Context Engineering: the 2026 Shift

Sovereign context operating model

An AI agent is only as good as the context it can reach. For a regulated enterprise, that context — the architecture repository — is also one of its most sensitive assets.

The operating model that matters is not "expose the repository over MCP"; it is "govern what context leaves, to whom, and under which residency and audit constraints".

• Decide which object types are queryable, and which are never exposed
• Keep context fresh: reconcile the repository against live sources, not a yearly snapshot
• Make every answer traceable to a governed source the user is entitled to see

The four-year shift: from prompt to context

In 2023, the headline skill was prompt engineering — phrase the instruction well and a single model would do impressive things. By 2024 the conversation had moved to retrieval-augmented generation (RAG): the model was no longer asked to know everything, it was fed relevant documents at query time. In 2025 the spotlight turned to agent engineering — multi-step systems that plan, call tools and act, not just answer. And in 2026 the discipline underneath all of it has a name: context engineering.

Each step did not replace the last so much as expose its real bottleneck. Better prompts revealed that the model lacked knowledge — hence RAG. Better retrieval revealed that single answers were not enough — hence agents. And capable agents revealed the deepest constraint of all: an agent is only ever as good as the context it can reason over. That is the thesis of 2026.

Why the bottleneck moved to context

As frontier models became excellent at following instructions, clever wording stopped being the differentiator. Two systems running the same model now diverge almost entirely on what they put in front of it: which sources, how fresh, in what structure, with which permissions. That is context engineering — deciding and delivering the right information into an agent's working context.

The vocabulary is worth recovering deliberately, because vendors are already claiming it. Ardoq, among others, helped popularize the term context engineering for enterprise architecture, and the framing is correct: in an enterprise, the hard part is never the prompt, it is assembling trustworthy context across a sprawling estate. We credit that framing — and then push it somewhere it has not yet gone.

• Prompt engineering (2023): optimize the instruction sent to one model
• RAG (2024): feed the model relevant documents at query time
• Agent engineering (2025): plan, call tools, act over multiple steps
• Context engineering (2026): engineer the knowledge the agent reasons over

Structured enterprise context already lives in EA

Here is the part most context-engineering discussions skip. The richest enterprise context an agent needs is not scattered loose in wikis and tickets — much of it is already modeled. Which applications exist, which business capabilities they support, what depends on what, which data flows where, what is obsolete or at risk: this is precisely the content of an enterprise architecture model.

That makes EA the natural System of Context — the layer an agent queries to reason about the whole estate — sitting alongside the Systems of Record (CRM, ERP, ITSM) that each answer for one domain. A System of Record tells you what happened in a silo. The System of Context tells you what breaks if a component fails, what is redundant, and what is exposed. RAG over loose documents is shallow context; a connected EA graph is deep, structured context.

• Application portfolio and the capabilities each system supports
• Dependencies — what breaks if a component fails
• Data flows — where sensitive data actually goes
• Lifecycle signals — what is obsolete, redundant or at risk

The condition the context must be living

There is a hard prerequisite. An EA repository only works as a System of Context if it is current. An agent that reasons confidently over an eighteen-month-old snapshot will give confident, wrong answers — and in a regulated setting, a confident wrong answer is worse than no answer.

So context engineering in the enterprise is not a one-off retrieval pipeline; it is a commitment to a living, agent-ready repository that is continuously refreshed. The model behind the agent is a commodity you can swap. The freshness, structure and governance of your context is the durable asset. Get the order right: context first, then the rest.

Sovereign context engineering: the regulated lens

Now add the constraint the giants tend to skip. An enterprise architecture map is, in effect, a near-complete blueprint of the organization: full system inventory, critical dependencies, obsolete components, known weaknesses, sensitive data flows. Feeding that to a US-cloud model by default is a DORA, NIS2, GDPR and EU AI Act landmine for a regulated bank, insurer or public body.

Context engineering done under data-residency and governance constraints deserves its own name: sovereign context engineering. It keeps the context inside the EU or your own infrastructure, makes access permission-aware, and leaves an audit trail an auditor will accept. The question stops being can AI talk to your architecture and becomes can AI reason on your architecture without you losing control of it. For regulated finance, that second question is the only one that matters.

• Data-residency-aware: context stays in the EU or on infrastructure you control
• Permission-aware: who can query what is enforced, not assumed
• Auditable: a defensible trail for DORA / CSSF / NIS2 scrutiny

EA as the System of Context — and the honesty rail

Put the pieces together and the 2026 picture is clear: the agent is a commodity, the prompt is a small lever, and the decisive asset is a living, governed, sovereign context layer. Enterprise architecture is the natural home of that layer — the System of Context that makes an agent's answers trustworthy and an auditor's acceptance possible.

We will be precise about what exists. A sovereign MCP server connecting agents to that context is a direction ArchiLU is building toward — a conviction about how regulated enterprises should do this, not a shipped product we claim today. What is real now is the foundation: a living EA model, EU-region or on-premise hosting you control, native French and English, published pricing. Build the System of Context first; the protocol on top comes last, and only once the context is worth querying.

Regulated AI context KPIs

Measure whether your context is trustworthy and governed, not how many queries the agent runs.

• Context freshness: median age of architecture objects vs live reality
• Share of answers traceable to a governed, permission-scoped source
• Sensitive object types covered by redaction/residency policy
• Audit coverage: prompts and responses logged and reviewable

Common mistakes

Most MCP-for-EA initiatives fail on context quality and governance long before they fail on the protocol.

• Exposing the full architecture repository to external LLMs without data-residency controls
• Treating MCP as the differentiator instead of the governed context behind it
• Connecting an 18-month-old, hand-maintained repository an agent cannot trust
• No permission-awareness, logging, or redaction of sensitive object types

Practical checklist

Run this before connecting any AI agent to your architecture repository.

• Confirm where prompts and responses go, and whether data stays in your region
• Enforce permission-aware access so the agent only sees what the user may see
• Classify and redact sensitive object types (vulnerabilities, data flows, controls)
• Log prompts and answers for audit, and keep a human in the loop for any change