Architecture perspective · 10 October 2026 · Ahmad Al Shami
Build agentic AI around a business outcome, explicit authority and a recoverable execution process. The model is one component; the architecture determines whether the work can be trusted, measured and operated.
What is changing in agentic AI architecture?
Current engineering guidance gives architects several useful signals. Microsoft recommends choosing the lowest level of agent complexity that reliably meets the requirement, with a single tool-using agent often a sensible enterprise starting point. Multi-agent coordination adds latency, cost and failure modes. Source: Microsoft’s orchestration guidance.
A more recent development is the separation of reasoning, execution environments and durable session history. Anthropic’s April 2026 Managed Agents architecture describes these as independently replaceable components, with credentials kept outside agent-generated code environments. My architectural takeaway: design stable interfaces and recoverable state so a model or runtime change does not require rebuilding every business integration. Source: Anthropic, 8 April 2026.
Context engineering is also becoming a distinct design concern: selecting relevant evidence, managing working context and retaining useful state across longer tasks. It is more deliberate than passing an entire document collection into every prompt. Source: Anthropic’s context-engineering guidance.
These are engineering directions reflected in the sources, rather than a claim that every enterprise has adopted them. My recommendation is to translate them into an operating model before committing to a platform.
A practical enterprise reference architecture
The following is a proposed design, adaptable to your systems and risk appetite.
| Layer | What to build | Decision to make |
|---|---|---|
| Business outcome | A bounded request, process owner and success measure. | Which decision or task can the agent support? |
| Orchestration | Workflow states, routing, timeouts, retries and escalation. | Which steps are deterministic, and which need model reasoning? |
| Agent runtime | Instructions, a model, typed tools and execution limits. | What can it decide, and when must it stop? |
| Knowledge and context | Permission-filtered retrieval, source references and task state. | What evidence is authoritative and current? |
| Tool and action gateway | Scoped APIs, parameter validation and approval enforcement. | Who authorizes each change to a business system? |
| Operations and assurance | Durable execution records, evaluations, monitoring and recovery. | Can the team explain and recover a failed run? |
Apply identity, access controls and data handling rules across every layer. Keep business systems authoritative for their records. Treat retrieved documents and tool results as data, rather than instructions that can override policy.
How I would build the first use case
1. Select a narrow workflow and establish a baseline
Choose work with a clear owner, accessible evidence and a manageable consequence of error. For example, an agent could assemble an enterprise architecture impact assessment for a proposed application change. Measure current review time, missing evidence and rework before introducing AI.
2. Define the authority boundary
Write down permitted reads, permitted drafts, prohibited actions and approval requirements. Start with read access and draft generation. A recommendation to change an application portfolio record should remain a proposal until an authorized person approves the exact record and change.
3. Build the knowledge path
Inventory architecture records, policies, ownership and source freshness. Azure Data Lake can hold governed source material; a retrieval layer must separately index it and enforce access. A data lake alone does not provide retrieval quality or row-level permission enforcement. Return source identifiers with each finding so reviewers can inspect the evidence.
4. Connect one agent through controlled tools
Use a single agent for the first bounded assessment. Expose narrow tools such as “retrieve application dependencies” and “prepare assessment draft,” with validated inputs and structured outputs. Integrate with Sparx or Orbus through supported interfaces available in your deployment. API and MCP connections still require authentication, authorization and server-side policy enforcement.
5. Use n8n for workflow coordination where it fits
An illustrative flow is: request received → validate scope → retrieve authorized evidence → generate a structured assessment → check required fields and sources → human review → approved system update → audit record. n8n supports human review on selected AI Agent tools, pausing execution for approval or denial. Source: n8n’s human-review documentation.
Bind approval to the exact proposed payload. If the target or parameters change, obtain a new approval. Store credentials in an approved secret store and enforce permissions in the action gateway; a prompt instruction is not an access control.
6. Make execution recoverable
Persist workflow status outside the model’s context window. Assign a request identifier and prevent duplicate writes with idempotency controls. Retry only operations that are safe to repeat, and reconcile ambiguous results before writing again. Set run-duration, tool-call and spending limits, with a human escalation path when limits are reached.
7. Evaluate before expanding autonomy
Create a small, representative evaluation set covering successful requests, missing evidence, conflicting sources, unauthorized data, hostile document instructions, tool timeouts and denied approvals. Check task completion, factual grounding, policy adherence, reviewer corrections, latency and cost per accepted result. Define release thresholds with the process owner rather than relying on a convincing demonstration.
When should you introduce multiple agents?
Add specialization when evaluation shows that one agent cannot reliably handle the task, or when distinct access boundaries and parallel work justify it. Define the handoff contract, shared state and conflict-resolution rules first. Architecture review, data analysis and compliance checks may deserve separate components; they do not automatically require separate autonomous agents.
Connect strategy to execution
Map each use case to the capability it improves, the value stream it supports and the person accountable for the outcome. Assign ownership for knowledge quality, model evaluation, integration reliability and operational support. Expand autonomy only when observed performance and the consequence of failure justify the change.
My recommendation: build one useful, governed workflow; prove it against real operating measures; then extend its scope. This connects agentic AI investment to an enterprise architecture and a delivery model that the organization can sustain.
Discuss your Agentic AI architecture
The workflow above is an illustrative reference design, not a claim of a deployed client solution. The accompanying image is an AI-generated conceptual illustration. Vendor capabilities and deployment requirements should be checked before implementation.