Cover illustration: a conceptual view of strategy, an architecture repository, agents, human approval and operational evidence.
By Ahmad Al Shami | Strategy, Enterprise Architecture & AI Transformation
An AI-ready enterprise architecture repository should help answer a practical question: what is this agent allowed to do, for which business outcome, under whose authority, and with what evidence that it works?
Application inventories and infrastructure diagrams remain useful. As software begins to coordinate tasks and invoke tools across business domains, architects also need to make authority, information quality and operational dependencies visible.
My recommendation is to extend the repository around one business workflow first. Connect its business architecture to the agents, services, data and controls that support execution. Use that model to guide investment, implementation and change decisions.
Watch the illustrated presentation
A 7-minute illustrated explanation with American Michael narration.
Watch and subscribe on YouTube
Why this matters now
In its March 2026 article on enterprise architecture for the agentic era, McKinsey describes both incremental and broader modernization paths. Its incremental approach retains existing systems while introducing agents and a coordination layer. For EA teams, the implication is concrete: model the dependencies between new agent workflows and the existing enterprise core. [1]
Microsoft’s July 2026 multi-agent guidance emphasizes least privilege, defined task contracts, auditability and human approval for high-impact actions. Those design requirements need identifiable owners and traceability in the architecture repository. [2]
This article proposes a practical repository profile. It is not an official ArchiMate AI extension or a claim that a modelling tool can enforce runtime policy.
Begin with business architecture
Start with the outcome and the work, before deciding how many agents are needed.
For supplier selection, the business objective might be to shorten evaluation time while preserving approval controls. The relevant capability is supplier sourcing and selection. The workflow includes gathering supplier evidence, assessing risk, comparing options and approving a commitment.
Business architecture clarifies which decisions belong to people, what information each step needs and how success will be measured. Enterprise architecture then connects that design to application services, integrations, data and infrastructure.
A capability is not automatically an agent. Several agents may support one capability; one reusable agent may support several workflows. A deterministic workflow or a single agent may also be sufficient.
What the repository should capture
| Architecture concern | Suggested ArchiMate 3.2 concepts | AI-specific information to maintain |
| Business purpose | Goal, Outcome, Capability, Value Stream | Intended value, scope, benefit owner and measures |
| Accountability | Business Actor, Business Role, Business Process | Decision owner, approver, escalation and handover |
| Agent structure | Application Component, Application Collaboration | Agent identity, custodian, version and lifecycle |
| Behaviour and services | Application Function, Application Process, Application Service | Task boundaries, coordination and service contracts |
| Tools and data | Application Interface, Data Object, Artifact | Permitted actions, knowledge sources, deployed configuration and provenance |
| Controls and change | Requirement, Constraint, Assessment, Work Package, Gap | Autonomy boundaries, risk, readiness, evaluation gates and migration work |
These are proposed modelling conventions using familiar 3.2 concepts. Check the ArchiMate version and metamodel implemented in your repository before importing or changing definitions. Distinguish logical information objects from deployed files and configuration artifacts.
Represent a software agent primarily as an application component. Keep the accountable human or organization visible as a business actor or role. An agent carrying out a task does not inherit accountability for the business decision.
A procurement example
Consider a conceptual supplier-selection workflow:
- A supplier evidence agent retrieves approved supplier records.
- A risk agent evaluates that evidence against procurement policy.
- An orchestrator combines the results into a supplier recommendation.
- A procurement approver reviews the recommendation and authorizes the commitment.
- An ERP service creates the approved purchase order.
The repository should make it easy to distinguish reading supplier information, recommending a supplier and committing company funds. Each has a different authority boundary.
Record the relevant application components, functions, services and data objects. Use appropriate assignment, serving, access and realization relationships. Capture approval as a business responsibility and the commitment boundary as a constraint. Runtime authorization and workflow controls must enforce the design.
The example is illustrative. It is not a reported client implementation or a measured result.
Explore the procurement ArchiMate model
A conceptual model with 21 elements and 19 relationships. The preview simplifies routing; the downloadable model and relationship register contain the full design.
Download editable ArchiMate model Download model package & guide
Open the native .archimate file in Archi. Uses ArchiMate 3.2 concepts with proposed AI profile conventions. XML and references checked; desktop import has not been tested. This is a hypothetical design.
Extend the repository with a small AI profile
For each agent, maintain a stable identifier, business purpose, accountable business owner, technical custodian, lifecycle status and version. Link the agent to the capabilities and workflows it supports.
Document the actions it may perform, the data it may access, approval conditions, escalation route and operational fallback. Reference the deployed tool contracts and configuration versions rather than copying secrets into the repository.
Connect architecture records to evaluation results and operational dashboards through stable references. Keep detailed execution logs in their operational systems. The repository needs to support decisions and impact analysis without becoming a second log store.
Define who maintains each attribute and when it is reviewed. An impressive agent catalogue becomes unreliable quickly if ownership and update responsibilities are unclear.
Treat change impact as a business question
A model upgrade is more than a technical version change. It may alter recommendation quality, cost, latency or behaviour at an approval boundary.
Before release, ask which workflows consume the affected agent or service, which datasets and policies it relies on, which owners must approve the change, and which evaluations must be repeated.
MCP and A2A can support tool access and agent interaction. They do not settle business decision rights or replace authorization controls. Model both the integration contract and the authority behind it. [2]
Test readiness through one workflow
An EA team can run a focused readiness review using five questions:
- Can we trace each agent to a business outcome and a named owner?
- Can we identify its permitted read, write and external actions?
- Can we locate the authoritative data sources and their custodians?
- Can we see approval, escalation and recovery responsibilities?
- Can we link the deployed version to evaluation evidence and outcome measures?
Use the gaps to prioritize repository improvements. Then pilot one bounded workflow and measure its performance against a baseline: cycle time, review effort, exceptions, quality, cost and control failures.
The repository is ready to support transformation when it helps teams make these decisions consistently—and stays connected to what is actually deployed.
Strategy → business capability → accountable decision → agent-enabled execution → measured outcome.
Sources
[1] McKinsey, Rethinking enterprise architecture for the agentic era, 12 March 2026: https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/rethinking-enterprise-architecture-for-the-agentic-era
[2] Microsoft Learn, Multi-agent patterns, updated 6 July 2026: https://learn.microsoft.com/en-us/agents/architecture/multi-agent-patterns