Enterprise architecture and agentic AI: from documents to machine-readable context

For years, enterprise architecture produced deliverables meant for humans: maps, target diagrams, decision registers, principle repositories. Its readers were a committee, a project manager, an auditor. With AI agents, a new reader appears: a system that acts inside the information system and also needs to "know" the rules. Several vendors and analysts in the field converge on the same formula: architecture shifts from control to context.

The problem: an agent doesn't read your slide deck

An agent automating an order, a reconciliation or a customer reply works with what's in its context: a prompt, retrieved documents, exposed tools. If the company's constraints — who may decide what, which data is sensitive, which system is authoritative for which information — live in documents only humans read, the agent ignores them. It isn't malicious; it is simply poorly informed. Incidents where agents "do what they were asked" yet break an implicit rule come from here.

What "machine-readable context" means in practice

It does not mean replacing architecture with a knowledge graph, but making part of what it decides queryable and enforceable:

• Policies in verifiable form: who can approve what, up to what amount, with what segregation of duties.
• Dependencies and data lineage: which system is the source of truth for a business object, and who depends on it.
• Architecture decisions: existing ADRs with their status, which an agent can consult so as not to contradict an already-settled choice.
• Capabilities and their owners: whom to escalate to when the agent reaches the limit of its scope.

Emerging approaches — knowledge graphs, ontologies, GraphRAG, instruction files such as AGENTS.md, exposing the architecture repository through MCP — all point this way. The issue isn't the tool but the discipline: keeping this context current, with an owner.

From gatekeeper to orchestrator

The architect's role is evolving. The one-off architecture review, where a committee blocks or approves upfront, doesn't hold against agents that change every week. The model emerging: architecture continuously supplies context and guardrails, continuously checks that agents respect them, and handles exceptions. It works less on documents than on agent lifecycles: how an agent is trained or configured, deployed, supervised, updated, retired.

Limits to keep in mind

Poorly maintained machine context is worse than an outdated document: it is applied automatically. Knowledge graphs are expensive to build and keep current, and many organizations don't yet have a reliable architecture repository for humans — digitizing it won't help. Finally, making a rule readable to an agent doesn't guarantee it follows it: you always need independent control over what the agent actually does.

Where to start

Pick a high-stakes, narrow domain — expense approval, say, or access to personal data. Formalize its rules, name an owner, expose them to a pilot agent, and measure deviations. This is also the spirit of TEAF, whose framework sets explicit roles (architecture owner, decision steward, AI control) precisely so that context has someone accountable.

• Architecture has a new reader: the agent. What isn't made accessible to it, it ignores.
• "Machine-readable" means queryable policies, dependencies, decisions and owners — not a giant graph at all costs.
• The architect's role shifts from one-off review to continuously maintained context and guardrails.
• Unmaintained context is dangerous, and a readable rule is not an obeyed rule: independent control is required.

Sources

• BlueDolphin — Agentic AI: Enterprise Architecture's shift from control to context
• Ardoq — Agentic AI and the future of enterprise architecture
• Avolution — Enterprise architecture in 2026: trends, skills, strategies