Enterprise architecture context is the curated, metamodel-aware model of the IT estate — applications, capabilities, technologies, integrations, and the How/Why evidence that explains them — that humans and agents share when they decide. Document RAG retrieves passages; it does not own that landscape. Search phrases such as architecture context for AI, enterprise context vs knowledge base, and why RAG is not enough for EA all point at the same gap.
What do people mean by “context” in AI and IT?
The word is overloaded. At least three layers are routinely conflated:
- Session context — the prompt window, chat history, and tools available to a model in one run.
- Retrieval context — passages fetched from wikis, tickets, or PDFs by similarity (classic RAG).
- Enterprise architecture context — a governed representation of what exists in the landscape, how it relates, and why past choices were made, with an accountable owner of curation.
Layer (1) and (2) are necessary for many assistants. Layer (3) is what architecture decisions and agentic delivery actually require. Without it, every squad’s bot becomes a competing architecture office — the problem framed in why EA must own enterprise context in the agentic era.
A working definition
In knowledge-management terms, this is closer to architecture knowledge management than to a document knowledge base: the organisation stores commitments about the estate, not only text that mentions systems. Thin factsheets that hold the What without How/Why are incomplete context (why EA factsheets miss the How and Why).
Why is document RAG not enough?
Retrieval-augmented generation answers: which passages look similar to this question? Enterprise architecture must answer: what is authorised to be true of our landscape for this decision? Those are different problems. RAG alone typically fails to:
- Maintain a metamodel (applications vs components vs capabilities) so relationships stay consistent.
- Resolve conflicts when two HLDs disagree, or when a wiki page outlives a retirement decision.
- Record what was rejected or deferred — absence of a false claim is not the same as a curated map.
- Provide provenance for audit that leaders can defend under change and regulatory pressure.
That is why Copilot or plain RAG is not a substitute for an Architecture Decision Workspace, and why a metamodel-aware agent differs from a writing Copilot.
Architecture context vs CMDB vs document stores
A useful comparison for evaluators:
- Document knowledge base / wiki — stores narrative; excellent for reading, weak as a single landscape authority.
- CMDB / inventory — stores operational assets; strong on “what is deployed,” weak on capability framing and design rationale.
- Classic EA repository — stores structured What; often hollow without continuous evidence (Discovery Tax).
- Enterprise architecture context — structured What plus How/Why evidence, curated into a living, askable map — the continuum described in the IT Knowledge Continuum.
How context is shaped (not merely retrieved)
Shaping context is a method, not a bigger context window:
- Discover — propose entities and links from documents, dialogue, and inventory (automated EA discovery).
- Structure — align proposals to a metamodel (including LeanIX-aligned modelling where that is the organisation’s language).
- Bind evidence — keep source passages with entities so claims remain explainable.
- Curate — humans accept, edit, reject, or defer; trusted updates beat unsupervised “100% coverage.”
- Ask and publish — Enterprise Ask and generated artefacts (documents as views of living context) consume the same Context of Record.
Why this matters for agentic delivery
Coding, infra, and change agents need a reliable slice of the estate — blast radius, dependencies, standards, owned systems — before they act. If each agent builds its own retrieval pile, the organisation pays a recurring Context Tax: re-assembling landscape truth on every run. Architecture context is the shared plane those agents should consume; delivery agents remain responsible for build and deploy. That separation is how EA stays relevant in an agent mesh without pretending to be a coding Copilot.
How does DecisionPen provide architecture context?
DecisionPen is an Architecture Decision Workspace: it holds the architecture context plane so discovery becomes durable memory, not a one-off baseline PDF.
- Metamodel-aware map — applications, capabilities, technology, integrations, and relationships as shared authority.
- Evidence-linked entities — documents and notes remain bound to the What.
- Human curation — AI proposes; architects ratify.
- Ask with citations — answers grounded in the curated map, not vibes over Confluence.
Trial DecisionPen on one contested domain: compare a cited landscape answer to an ungrounded chatbot — that is the context test.
When is DecisionPen not the right tool?
If you only need a general writing Copilot, a pure ops CMDB, or freeform Visio / Lucid / BPMN drawing. DecisionPen holds living architecture context and can generate diagram images from that context; it is not a drawing canvas or a document summariser alone.