# AI Agent Orchestration Platform

**Solution Architecture v1.0 · Data & AI Global Practice · 2026-08 · 32 views · Microsoft Azure**

A centralised runtime and control plane for designing, deploying, orchestrating, observing and governing AI agents and multi-agent workflows on Azure. Eight decisions carry the design: the control plane and the execution plane are separated absolutely, and the interface between them is a signed immutable bundle rather than a shared database; durable execution runs on Azure Durable Functions behind a workflow-engine port, so the engine can be replaced without touching agent code; every model call goes through API Management as an AI gateway, so metering, token limits, semantic caching, circuit breaking and provider fallback are policy rather than application code; tools are out-of-process and least-privileged, with credentials brokered per call and code execution confined to Hyper-V isolated session sandboxes; policy is authored centrally as signed Rego bundles and evaluated locally in every worker, so a control-plane outage cannot make policies fail open; delivery is at-least-once with idempotency pushed to the handler; memory is four stores rather than one, each permission-filtered and audited; and budget is reserved at admission, so a run cannot start that it cannot afford to finish.

---

## What is here

| Path | Contents |
|---|---|
| `diagrams/index.html` | The view index — 32 views grouped into six acts, every format linked |
| `diagrams/*.html` | One self-contained page per view: the inlined diagram plus the reasoning it deliberately omits, with copy / PNG / PDF export |
| `diagrams/svg/*.svg` | The same 32 views as SVG with the diagram XML embedded — re-opens in diagrams.net fully editable |
| `diagrams/drawio/*.drawio` | draw.io native source |
| `specs/views.json` | Diagram specifications — the source of truth for every view (assembled from `part-a..f.json`) |
| `specs/manifest.json` | Acts, page titles, subtitles and the decision / assumption / risk cards (assembled from `manifest-a..b.json`) |
| `scripts/build.sh` | Rebuilds every deliverable from the specs |
| `scripts/pin-icons.mjs` | Pins one mark per component so the same box carries the same icon on every page |
| `ask.md` | The original requirement |

Every component carries its own mark — 679 icons embedded in the files, so the deliverable renders identically anywhere with no external requests. Each view page links to its own SVG and draw.io source, back to the index, and to the previous and next view.

To rebuild after editing a spec:

```bash
bash scripts/build.sh          # requires Node 20+ and nothing else
```

Edit `specs/part-a.json` … `part-f.json` and `specs/manifest-a.json` / `manifest-b.json`; the build script assembles `views.json` and `manifest.json` from them, pins the icons, then generates, validates, renders and link-checks in one pass.

---

## The six acts

| Act | What it lands | Views |
|---|---|---|
| 1 · Context and scope | The boundary, the actors, the dependencies, and the plane separation that governs everything after it | 01–03 |
| 2 · Structure | The layering rule, the deployable units, every interface, and the three planes agents actually touch: model, tool and message | 04–11 |
| 3 · Data | Which store holds what, how memory is scoped, how a context window is assembled, and what a decision reads | 12–16 |
| 4 · Runtime | One run end to end, six coordination patterns, durable recovery, human approval, and the guardrail and policy chain | 17–22 |
| 5 · Operations | Where it runs, how a change reaches production, what is watched, what it costs, and how quality improves | 23–27 |
| 6 · Assurance and delivery | Trust boundaries, delegated identity, tenant isolation, every failure mode, and the order of delivery | 28–32 |

---

## The 32 views

| # | View | Layout | What it answers |
|---|---|---|---|
| 01 | System Context | context | Who uses the platform, what it depends on, and where the boundary is drawn |
| 02 | High-Level Architecture | flow | The shape of the platform in one picture, for the reader who will see only one |
| 03 | Control Plane and Execution Plane | nested | The one architectural boundary everything else depends on |
| 04 | Layered Architecture | bands | What depends on what, and the single dependency that points the wrong way |
| 05 | Container and Component Architecture | nested | The deployable units, their technology, their replica ranges and the Azure service each one owns |
| 06 | Integration and Interface Catalogue | hub | Every way something enters or leaves, with protocol, direction and cadence |
| 07 | Agent Runtime Internals | flow | What one worker does between leasing a step and committing it, and where the controls sit |
| 08 | Model Abstraction and Routing | nested | How a request for a capability becomes a call to a specific model, and what happens when that model is unavailable |
| 09 | Tool Plane and Permissions | swimlane | How each class of tool is discovered, authorised, invoked, validated and recorded |
| 10 | Event and Messaging Topology | nested | Which queues and topics exist, why there are several, and how a stuck message reaches a human |
| 11 | Definition Lifecycle and Versioning | flow | How a definition becomes an immutable published version, and what version pinning protects |
| 12 | Data Architecture and Storage Zones | nested | What is authoritative, what is rebuildable, and what disaster recovery actually has to cover |
| 13 | Memory Subsystem | grid | Six kinds of memory, where each lives, how it is retrieved, who may read it and how long it survives |
| 14 | Context Management | flow | How one model invocation's context window is assembled, compressed, protected and accounted for |
| 15 | Data Flow by Data Class | swimlane | Six classes of data, each traced from where it is produced to where it finally rests |
| 16 | Platform Data Model | er | Who ran what, on which version, with whose approval, at what cost |
| 17 | Execute an Agent | sequence | One synchronous run end to end, and the point at which the result becomes final |
| 18 | Multi-Agent Coordination | swimlane | Six coordination patterns, all of them workflow definitions rather than different platforms |
| 19 | Durable Execution and Replay | flow | What survives a crash, how failure is classified, and where a run goes when recovery is exhausted |
| 20 | Human-in-the-Loop | sequence | How a run suspends for a human decision, and what happens when nobody answers |
| 21 | Safety Guardrails | swimlane | Six threat classes, and what the platform does about each at detect, decide, act and record |
| 22 | Policy and Budget Enforcement | grid | Five policy scopes against five decision points: exactly what is evaluated, and where |
| 23 | Deployment Topology | nested | What runs where, what is redundant, and what a region loss actually costs |
| 24 | CI/CD and Environment Promotion | flow | How a change reaches production, and what stops a bad one at each hop |
| 25 | Observability and Tracing | grid | Six signal types across emit, collect, store, consume and act, and the identifier that joins them |
| 26 | Cost Management and Attribution | flow | How every token and tool call is metered, attributed, capped and then made cheaper |
| 27 | Evaluation and Quality | cycle | The loop from production failure back to a better agent version, and the gate that closes it |
| 28 | Security Zones and Trust Boundaries | zones | Where an attacker arrives, what stops them, and what an agent is trusted to do |
| 29 | Identity and Delegation | sequence | The path from a user signing in to a tool credential, and what is deliberately not passed along it |
| 30 | Multi-Tenant Isolation | nested | Four layers of isolation, what each prevents, and what the pooled tier still accepts |
| 31 | Failure Modes and Residual Risk | grid | Eight ways this platform fails, what detects each, what contains it, and what is left over |
| 32 | Delivery Roadmap | flow | What is built first, what waits, and which items are prerequisites rather than enhancements |

---

## Azure services in the design

| Capability | Service |
|---|---|
| Edge, WAF, global routing | Azure Front Door Premium, DDoS Protection |
| Platform API and AI gateway | Azure API Management Premium (GenAI policies: token limit, token metric, semantic cache, load-balanced pools, circuit breaker) |
| Control plane compute | Azure Kubernetes Service, 3 availability zones, workload identity |
| Execution plane compute | Azure Container Apps with KEDA queue-depth scaling; Azure Functions for durable orchestration |
| Sandboxed code and browser use | Azure Container Apps dynamic sessions (Hyper-V isolated, no default egress) |
| Models | Azure AI Foundry (Azure OpenAI PTU pool plus pay-as-you-go spillover), Foundry Models, open-weight models on AKS with KAITO |
| Safety | Azure AI Content Safety — prompt shields, groundedness detection, harm categories |
| Policy | Open Policy Agent bundles signed by the control plane, evaluated by a sidecar in every worker |
| Definitions and transactional metadata | Azure SQL Database Business Critical, zone redundant, geo-replica |
| Execution state and memory | Azure Cosmos DB (partitioned by tenant), Azure Managed Redis |
| Retrieval | Azure AI Search — hybrid retrieval with semantic reranking and security trimming |
| Artifacts and large payloads | Azure Data Lake Storage Gen2, immutable blob for audit |
| Messaging | Azure Service Bus Premium (work), Event Grid (lifecycle and webhooks), Event Hubs (telemetry) |
| Secrets and keys | Azure Key Vault with HSM-backed signing keys, one vault per tenant with its own customer-managed key |
| Identity | Microsoft Entra ID — SSO, OIDC, RBAC, workload identity federation, agent identities |
| Observability | Azure Monitor, Application Insights, Log Analytics, Azure Data Explorer, Azure Managed Grafana, OpenTelemetry GenAI conventions |
| Governance and security operations | Microsoft Purview, Microsoft Defender for Cloud, Microsoft Sentinel, Azure Policy |
| Cost | Azure Cost Management plus per-execution token accounting from the gateway |
| Delivery | GitHub Actions, Azure Container Registry with Notation signing, Bicep |

---

## Non-functional targets stated in the set

| Attribute | Target |
|---|---|
| Control plane availability | ≥ 99.9 percent, active with a warm standby in the paired region |
| Execution availability | 99.9 percent tier 1, 99.5 percent tier 2, region-pinned |
| Orchestration overhead | p95 under 120 ms per step, excluding model and tool latency |
| Streaming | first token p95 under 900 ms end to end |
| Scale | 5,000 concurrent executions, 8× peak-to-average |
| Recovery | RTO 15 minutes, RPO 5 minutes for execution state; RPO ≈ 0 for definitions |
| Retention | traces 90 days hot and 2 years archived; audit 7 years write-once; prompts and completions 30 days, capture off by default |

---

## Known limits of this deliverable

- **Assumptions, not confirmations.** The identity provider, the default inference surface, the residency regions, the retention defaults and the sizing basis are all stated assumptions on the relevant view's cards. Each is defensible and each needs confirming.
- **Three decisions are still the sponsor's.** Whether a dedicated-tenancy tier is required at launch, whether prompt and completion capture defaults on for internal projects, and the PTU commitment level. All three are on view 32's cards.
- **Cost figures are ratios, not quotes.** The warm-standby figure and the cost levers are sizing guidance; a priced bill of materials is a separate exercise.
- **Nine edge labels out of 138 sit over a node box** on views 06, 08, 23 and 28. Each is drawn on a white plate so the text stays legible; the placement is the generator's, and the rate is at parity with the toolchain's own reference deliverable. The strict geometry validator reports zero errors and zero warnings across all 32 views.