Context Engineering Explained for CIOs and CISOs

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

Why this lands on your desk now

If you run IT or security at a regulated institution, you have probably been asked some version of the same question this year: can we point an AI agent at our own systems? The honest answer is not yes or no — it is a question about context. An AI agent is only as good, and only as safe, as the context it can reach. Context engineering is the discipline that decides what that context is, where it comes from, and how tightly it is governed.

This is not a hype piece. There is no claim here that agents will replace your architects or that a model will read your estate and hand you a compliance certificate. The point is narrower and more useful: the value and the risk of enterprise AI both concentrate in the same place — the context layer — and that layer is now a decision-maker's concern, not a detail left to whoever wired up the integration.

What context engineering actually means

A useful way to separate the terms: prompting tells a model what to do; context engineering governs what it is allowed to reason over. The prompt is the question. The context is everything the model can see while answering — your application portfolio, your dependency maps, your decision records, your policies. Most of the quality of an answer, and almost all of the risk, lives in that second part.

For a regulated enterprise the natural home of that context is the enterprise architecture model: the connected picture of capabilities, applications and dependencies that describes how the organization actually runs. Treated well, it becomes what we call a System of Context — a governed layer that agents query — sitting alongside the Systems of Record (your ERP, CRM, ITSM) rather than replacing them. Context engineering is the work of making that layer fresh, scoped, in-region and accountable enough that an agent can use it without anyone losing control of it.

• Prompting = what the model is asked to do
• Context = what the model is allowed to see while answering
• Most answer quality, and most risk, lives in the context
• For EA, the System of Context is the connected model agents query

Why the context layer is also the risk layer

Here is the uncomfortable part. An enterprise architecture map is, for practical purposes, a blueprint of the organization: the full system inventory, the critical dependencies, the obsolete components nobody has retired, the sensitive data flows, sometimes the security measures themselves. It is precisely the document you would least want to hand to an outsider.

So the casual version of the question — "can we connect Claude or ChatGPT to our EA repository?" — hides a much larger one. Connecting a general-purpose, out-of-region model to that map can mean sending a near-complete description of your institution outside your control. Under GDPR, DORA, NIS2 and the EU AI Act, that is not a neutral act. The skill of context engineering, done seriously, is governing where the context goes — not only who is allowed to ask the question.

Five questions a decision-maker should ask

You do not need to become a prompt engineer to govern this well. You need to ask the right five questions of any AI agent that is going to touch your architecture, and to insist on answers you could defend to an auditor. The diagram above frames them around the governed context layer.

• Where does the context come from? Named, owned sources you can point to — not a scrape or a black box.
• Is it fresh? A living model that reflects today's estate, not an 18-month-old snapshot that will produce confident, wrong answers.
• Is it governed? Access control, scoping per role, and an audit trail of what was queried and returned.
• Does it leave our region? Data residency you can prove — where the context physically goes when an agent uses it.
• Who can it answer for? Clear accountability: which questions the agent is authorized to answer, and who owns the consequences when it does.

The compliance angle, stated honestly

There is a real and defensible connection to your regulatory documentation. DORA and CSSF expectations lean heavily on being able to show your ICT dependencies, your critical functions and the decisions behind your architecture. A governed, current context layer makes that documentation easier to produce, keep current and defend under review. That is genuine value.

It is also where vendors overreach, so let us be precise. A context layer is a documentation and evidence aid. It is not a compliance guarantee, and no software can be. Whether your institution is compliant remains a judgement made by your auditors and your regulator, on the full picture — not something a tool certifies. Anyone selling you the opposite is selling you the wrong thing.

What to do first

You do not need an MCP server or an agent rollout to start. In fact you should not start there. The first move is to make your context worth reaching: a connected, current model of your capabilities, applications and dependencies, hosted where you can prove it stays, with access you control. Get that right and the rest — copilots, agents, a future sovereign interface — has something safe to stand on. To be plain about our own position: a sovereign, data-residency-aware MCP is the direction we are building toward at ArchiLU, not a feature we ship today.

A practical first step is to find out how governable your context already is. ArchiLU's free EA Maturity Assessment scores ten dimensions of your architecture practice and returns a prioritized action plan in about ten minutes — a concrete way to see whether your context is fresh, governed and ready to be reached safely, before any agent goes near it.

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