Azure Topology

The bird's-eye view. Every Azure service the harness needs, organized by resource group, with the data flows that connect them.

Four resource groups

The recommended deployment organizes Azure resources into four resource groups, each scoped to a single concern. This keeps IAM policies tight, cost tracking clear, and blast radius contained when you need to tear down and recreate a layer.

Full topology

The diagram below shows every Azure service and the connections between them. Each box is color-coded by category: blue for compute, purple for AI, green for data, teal for networking, orange for security, yellow for monitoring, and gray for storage.

Data flow: a user message

To make the topology concrete, here's what happens when a user sends a message through the harness. Every hop crosses a service boundary shown in the diagram above.

1. User → Front Door → Harness API Container App. The user's message arrives via HTTPS. Front Door handles TLS termination, WAF inspection, and routes to the nearest Container App revision.
2. API → Azure OpenAI (LLM call). The harness builds the prompt (system instructions + conversation history + skill context + retrieved documents) and sends it to the chat completion deployment. The model returns a response, possibly including tool-use requests.
3. API → AI Search (RAG retrieval) → Azure OpenAI (embeddings). If RAG is triggered, the query is embedded via the embedding deployment, then sent to AI Search for hybrid vector + BM25 retrieval. Results are reranked and assembled into the context window.
4. API → Knowledge graph backend (graph query). For graph-backed memory queries — entity lookup, community detection, cross-session recall — the API hits the configured graph backend (Neo4j on AKS in the validated payloads, or a managed PostgreSQL store).
5. API → Application Insights (telemetry). Every step emits OpenTelemetry spans: the LLM call duration, token counts, retrieval latency, tool execution time, and governance decisions. All flow to Application Insights via the OTLP exporter.

Environment variations

Not every environment needs every service. The table below shows the recommended configuration at each tier, from zero-cost local development to a full production deployment.

Generated topology diagrams

The three tiers above were modeled deterministically with the AzureCraft Architecture Generator and validated against the Azure Well-Architected Framework pillars (security, reliability, performance, operational excellence, cost). The generator places services into the right resource group, VNet, and subnet automatically; the cost figures above are pulled directly from its pricing model for the East US region.

The payload files below are the source of truth for the topology — edit them and re-POST to the generator's /api/generate endpoint (port floats per restart; see the "How to regenerate" callout below this table for the current invocation) to refresh. The full DiagramState JSON (nodes, edges, layout, validationResults, costSummary) is saved by the generator under its own generated/ directory; reference the file IDs from the table below.

Invoke-RestMethod -Uri 'http://localhost:3002/api/generate' `
  -Method Post -ContentType 'application/json' `
  -InFile 'documentation/architecture/assets/diagrams/payloads/prod.json'