The enterprise AI stack: Foundry, Copilot, and Work IQ in 24 layers
An animated reference architecture that connects workplace context to Azure evidence, with delegated identity, typed tools, deterministic decisions, and verified outcomes.
AI-assisted / research-based
AI-assisted research and implementation. This is an independent reference design, not Microsoft's internal architecture. The examples and interactive policy simulation use synthetic data; no production deployment or measured results are claimed.
A VP of engineering asks a seemingly simple question: “Which staging resources can we reduce before Friday without disrupting the launch?”
Azure can tell us which resources exist. Telemetry can tell us whether they are busy. Neither fact establishes whether a quiet environment is reserved for tomorrow's release rehearsal. That commitment might live in a Teams conversation, a launch document, or an email thread.
A useful enterprise agent must connect those facts without confusing access to a conversation with permission to stop a virtual machine. That is the architecture problem. The chat window is only its entry point.
This companion to the cloud billing architecture ↗ follows the same approach: expose the layers, make their contracts explicit, and show where correctness is enforced. The 24 layers below are a proposed application decomposition, not a claim that Microsoft ships a product with 24 corresponding components.
First, separate the products
Microsoft's current documentation calls the platform Microsoft Foundry, previously Azure AI Foundry. It brings models, agents, tools, and operational capabilities into a common development environment. A model deployment is one dependency within that platform, not the complete application. Microsoft Foundry overview ↗.
Microsoft 365 Copilot is a workplace experience. Foundry agents can be published to Microsoft 365 Copilot and Teams through a supported publishing path. Endpoint creation, application packaging, organizational approval, and user distribution are separate delivery steps. Publish a Foundry agent ↗.
Work IQ exposes workplace intelligence through interfaces including A2A, MCP, and REST. It can provide the work context an application needs, subject to the calling user's access. It is not a replacement for Azure Resource Manager or a general grant of access to an organization's documents. Work IQ overview ↗.
Azure Copilot is the distinct Azure operations experience. It works with Azure context and the user's Azure permissions. This article does not assume a native Azure Copilot–Work IQ integration or that a custom Foundry agent can simply be installed into Azure Copilot. Our proposed implementation combines the two evidence domains in a Foundry application and exposes it through a supported application channel. Azure Copilot overview ↗.
Finally, Foundry IQ addresses knowledge retrieval using knowledge bases backed by Azure AI Search. It is an optional route to approved runbooks and technical knowledge here, not another name for Work IQ. Foundry IQ architecture ↗.
Follow one request through the stack
The motion advances every four seconds. Pause at any layer or select a card to inspect its input, output, implementation, and failure condition. Reading order follows six phases; it does not imply that every internal operation must execute sequentially.
ROOT18D / 24-LAYER REFERENCE ARCHITECTURE
From work context to a verified outcome
Proposed application flow · not Microsoft’s internal architecture · no live tenant connection
Select any layer for its input, output, implementation, and failure boundary. Motion advances one layer every 4 seconds; it stops after layer 24. All layers remain visible.
Enter
Orchestrate
Ground
Decide
Act & answer
Operate
01 / 24 · Enter
Experience & channel
- Input
- User question and channel identity
- Output
- Request envelope with channel and conversation IDs
- Implementation
- Teams, Microsoft 365 Copilot, or custom web client
- Failure boundary
- Do not confuse publishing to Microsoft 365 with extending Azure Copilot.
Phase 1: enter with an identity and a bounded question
The experience accepts the question and establishes the tenant, signed-in user, conversation, and permitted subscription scope. These are server-verified facts, not fields the language model supplies.
A conversation identifier must be namespaced by tenant and user. Reusing a previous user's conversation because the browser presents an existing identifier is a data isolation defect, even if the next model response sounds reasonable.
Admission control limits input size, request rate, tool budget, and lifetime. The initial product scope should also be explicit: staging virtual machines, a known subscription set, and recommendations first. “Find anything we can save” is too broad to become an executable contract.
Phase 2: orchestrate with a versioned agent
The application selects an agent version containing instructions, allowed tools, model configuration, and response schema. Each run records those versions so a later investigation can reproduce the configuration responsible for a decision.
Adaptive reasoning is useful when the question is ambiguous: does “the launch” refer to a product release or an infrastructure migration? The agent can ask a follow-up question or choose a narrowly scoped evidence query. Ordinary code should handle token validation, schema parsing, retry budgets, and permission checks.
The tool catalog contains typed capabilities such as read_launch_commitments, list_staging_vms, and read_utilization_window. It does not expose unrestricted shell commands or accept arbitrary URLs generated by the model. Retrieved messages and documents are evidence, never instructions that can expand the tool catalog.
Phase 3: ground in two independently authorized domains
The Foundry Work IQ connection supports delegated user context through an on-behalf-of flow. Its documented integration is preview, has no SLA, and is not recommended by Microsoft for production use. Calls can cross the Azure compliance boundary; deployment review must follow the actual service data path. That makes this a pilot architecture until the selected integration and contractual requirements are acceptable. Connect Foundry to Work IQ ↗.
The user-delegated identity used for workplace context is distinct from an Azure resource credential. An application service identity must not silently substitute its broader permissions for the user's authorization. An OBO implementation exchanges a validated incoming user assertion for the appropriate downstream token; it does not forward one token indiscriminately to every service. Microsoft identity platform OBO flow ↗.
Azure Resource Graph provides resource inventory over authorized scopes. It is not a substitute for a time series of utilization observations. The implementation should separately acquire telemetry, record its measurement window, and distinguish “no measurements” from “zero utilization.” Azure Resource Graph overview ↗.
Context is not execution authority
For the staging example, normalize the retrieved evidence into application-owned records. Preserve source identifiers, retrieval time, observed time, and authorization context. Do not assume every tool returns the same citation format or that a natural-language summary proves a resource relationship.
A launch document mentioning “staging” must be mapped to the exact resource set through a verified service identifier, ownership registry, or explicit owner confirmation. Guessing that two similar names refer to the same environment creates a dangerous join.
Phase 4: reconcile evidence before proposing action
Suppose resource evidence shows a VM has been quiet, but the launch owner reserved it for a rehearsal. The correct output is a blocked recommendation with that conflict explained. Low utilization alone is insufficient.
The agent can reconcile terminology, summarize conflicting commitments, and propose questions for the owner. Deterministic code then checks resource scope, freshness, operation allowlists, commitment state, and approval validity.
A proposed change becomes a typed plan. The approval binds to a canonical digest of its tenant, actor, exact resources, operation, parameters, and expiry. Any edit creates a new plan version and invalidates the old approval. The digest is an integrity binding, not a substitute for authenticated approval storage.
Phase 5: act through a narrow adapter and verify
If execution is enabled later, a server-side adapter revalidates authorization and current resource state immediately before acting. It claims an idempotency key in an operation ledger, records the provider operation identifier, and transitions through explicit states: proposed, approved, submitted, verified, failed, or uncertain.
A timeout after submission means uncertain, not “nothing happened.” Recovery checks the recorded operation and resulting resource state before retrying. Blind retries can duplicate effects even when the first client never received a response.
The final answer distinguishes a recommendation, an accepted operation, and a verified outcome. “Request submitted” cannot become “resource stopped” until a postcondition confirms it. Deallocating compute also does not imply all associated storage or network charges disappear; a savings estimate needs its own rate and cost model.
Phase 6: operate the decision system
Capture correlated spans for admission, orchestration, evidence retrieval, policy evaluation, approval lookup, provider operation, and verification. Foundry tracing provides an observability foundation; application spans must cover the business decisions outside the model call. Trace an agent application ↗.
Persist evidence references and policy outcomes rather than indiscriminately logging email bodies or access tokens. Retention, access controls, and redaction belong to the trace design. A dashboard that exposes retrieved documents to every operator can undo the permissions enforced during retrieval.
Implementation: a protocol call is not the entire application
The direct Work IQ A2A endpoint offers a concrete integration seam. A version 1.0 JSON-RPC request uses SendMessage, a user role, and text parts. The version header matters: omitting it selects a different protocol version. Authentication requires an appropriately delegated token for the Work IQ audience, not an Azure management token. Work IQ A2A quickstart ↗.
POST https://workiq.svc.cloud.microsoft/a2a/
Authorization: Bearer <server-acquired-user-delegated-token>
Content-Type: application/json
A2A-Version: 1.0{
"jsonrpc": "2.0",
"id": "unique-request-id",
"method": "SendMessage",
"params": {
"message": {
"role": "ROLE_USER",
"messageId": "unique-message-id",
"parts": [{"text": "Find current launch commitments for the Orion staging environment. Identify conflicting or missing evidence."}]
}
}
}Generate unique identifiers per request. Handle the returned task state explicitly: an HTTP success does not establish that the task completed. Keep any returned conversation context isolated to its authorized user. Normalize evidence using the actual API response contract rather than inventing a universal citations field.
On the Azure side, an inventory query might begin with:
Resources
| where type =~ 'microsoft.compute/virtualmachines'
| project id, name, resourceGroup, subscriptionId, location, tagsThe server supplies the authorized subscription scope separately. Tags can suggest environment ownership, but they are not authorization boundaries. Validate the resulting resource identifiers before invoking another adapter.
The application-owned decision envelope can then carry:
{
"schemaVersion": 1,
"tenantId": "synthetic-tenant",
"actorId": "synthetic-user",
"runId": "run-001",
"agentVersion": "staging-advisor-3",
"policyVersion": "staging-policy-2",
"planVersion": 1,
"resourceId": "synthetic-staging-vm",
"operation": "deallocate-staging-vm",
"evidenceRefs": ["work-evidence-7", "azure-evidence-12"],
"approvalId": null,
"state": "proposed"
}This is our schema, not a Microsoft service response. Evidence records additionally need source scope, observation timestamps, integrity metadata, and expiry. Approval records need the approving principal, authority, bound plan digest, and validity interval. The operation ledger needs a unique idempotency key and provider correlation identifiers.
Try the deterministic decision gate
The miniature policy below illustrates a narrow server-side decision. It deliberately treats a launch freeze, missing authorization, old evidence, changed plan, or mismatched tenant as a block. Its five-minute freshness window is an example policy choice, not a Microsoft requirement.
Test the decision boundary
No tenant connection, model call or Azure action. This demonstration evaluates one proposed staging-VM operation.
A pass is not execution. A real server must authenticate these records, refresh authorization, claim an idempotency key and verify the resulting resource state.
Read the runnable policy source ↗. Its fixtures are synthetic and its digest is a placeholder. Production code must compute a canonical cryptographic digest and obtain authenticated records from trusted services. Browser state is never sufficient evidence for executing an Azure action.
Consider the recovery path: a proposal receives approval, then a newer launch commitment appears. Reconciliation changes the plan, so the previous approval no longer matches. Execution stops. The owner reviews the revised proposal, the system gathers fresh resource evidence, and a new approval can authorize the new version. The agent explains the change; it cannot approve its own revision.
There remains a time-of-check/time-of-use gap. Revalidation, short approval lifetimes, resource preconditions where available, and postcondition checks reduce that gap. They do not make two independent cloud systems transactionally atomic.
The contracts behind all 24 layers
Each layer below names an accountable owner and a concrete handoff. Some may share a process or database in an MVP. Separate contracts matter more than deploying 24 microservices.
01 · Experience & channel Product / channels
- Input
- User question and channel identity
- Output
- Request envelope with channel and conversation IDs
- Implementation
- Teams, Microsoft 365 Copilot, or custom web client
- Failure boundary
- Do not confuse publishing to Microsoft 365 with extending Azure Copilot.
02 · Identity & tenant Identity engineering
- Input
- Verified Entra claims and tenant selection
- Output
- Tenant and user binding for the request
- Implementation
- Token validation middleware; Entra configuration
- Failure boundary
- Reject wrong issuer, audience, tenant, or expired token.
03 · Scope & admission Platform engineering
- Input
- User scope, requested subscriptions, token and rate budgets
- Output
- Admitted bounded request or explicit rejection
- Implementation
- Quota store and resource-scope allowlist
- Failure boundary
- Never let a prompt expand a caller’s resource access.
04 · Conversation boundary Application engineering
- Input
- Conversation ID plus user and tenant binding
- Output
- Scoped history with retention policy
- Implementation
- Conversation store; retention metadata
- Failure boundary
- A guessed conversation ID must not disclose another user’s context.
05 · Versioned agent Agent engineering
- Input
- Agent instructions, tool contract versions, model deployment
- Output
- Pinned runtime configuration
- Implementation
- Foundry agent/project; deployment manifest
- Failure boundary
- A model update does not silently change approved tool policy.
06 · Model invocation Model platform
- Input
- Bounded prompt, model deployment, output schema
- Output
- Candidate response or structured tool request
- Implementation
- Model endpoint; token/time limits
- Failure boundary
- Handle truncation, invalid structure, and unavailable deployments.
07 · Plan & tool selection Agent engineering
- Input
- Question, tool descriptions, incomplete evidence
- Output
- Small plan with deadlines and stopping conditions
- Implementation
- Runtime state; maximum tool-call budget
- Failure boundary
- The plan is a proposal, not authorization to execute.
08 · Tool catalog & connections Integration engineering
- Input
- Allowlisted capabilities and versioned connections
- Output
- Validated tool name and arguments
- Implementation
- Foundry connections/toolbox; adapter registry
- Failure boundary
- Reject arbitrary URLs, unregistered tools, and schema drift.
09 · Delegated Work IQ call Identity + M365 integration
- Input
- Signed-in user context and scoped natural-language task
- Output
- Permission-aware work response via supported integration
- Implementation
- Work IQ connection; delegated OAuth/OBO path
- Failure boundary
- A managed identity alone does not become the human user.
10 · Work context & provenance Knowledge engineering
- Input
- Work IQ response and available citations
- Output
- Evidence records with source, time, and confidence caveats
- Implementation
- Ephemeral evidence store with user scope
- Failure boundary
- No source or inadequate permission means insufficient evidence.
11 · Azure resource evidence Cloud platform
- Input
- Allowlisted Resource Graph / Monitor queries and Azure identity
- Output
- Resource state and telemetry snapshot
- Implementation
- Resource Graph, Azure Monitor, ARM read adapters
- Failure boundary
- Microsoft 365 access does not imply Azure RBAC access.
12 · Optional domain retrieval Search / data platform
- Input
- Approved runbooks and product knowledge sources
- Output
- Cited domain evidence with access filtering
- Implementation
- Foundry IQ / Azure AI Search knowledge base
- Failure boundary
- Do not assume a custom index inherits source ACLs automatically.
13 · Evidence reconciliation Application engineering
- Input
- Work intent, Azure facts, freshness, conflicting sources
- Output
- Explicit facts, unknowns, and conflicting evidence
- Implementation
- Typed evidence bundle; timestamps and hashes
- Failure boundary
- Do not turn missing utilization data into a confident savings claim.
14 · Candidate plan Agent engineering
- Input
- Reconciled evidence and supported action schema
- Output
- Read-only report or proposed change plan
- Implementation
- Immutable plan document; revision and digest
- Failure boundary
- Model-generated shell commands are not the execution interface.
15 · Deterministic policy Security + platform
- Input
- Verified user scope, plan, evidence age, action rules
- Output
- Allow review, deny, or request more evidence
- Implementation
- Versioned policy engine
- Failure boundary
- Text saying “approved” cannot grant access.
16 · Approval record Service owner / change management
- Input
- Exact plan digest, scope, risk, deadline
- Output
- Server-verified approval bound to the plan
- Implementation
- Approval service; authorized approver record
- Failure boundary
- Expired approval or changed arguments require a new decision.
17 · Typed execution adapter Cloud platform
- Input
- Policy-passed plan and execution identity
- Output
- Provider API operation with bounded permissions
- Implementation
- Narrow ARM/ITSM adapter; no generic command runner
- Failure boundary
- Only supported operations may reach the provider.
18 · Operation ledger Reliability engineering
- Input
- Request ID, action ID, attempt, provider correlation ID
- Output
- Durable operation state and deduplication key
- Implementation
- Transactional operation store
- Failure boundary
- A retry after timeout must reconcile before resubmitting.
19 · Postcondition verification Reliability / service team
- Input
- Provider operation status and fresh resource read
- Output
- Verified success, failure, or uncertain state
- Implementation
- Provider status plus post-action snapshot
- Failure boundary
- HTTP acceptance is not proof the desired state was reached.
20 · Cited user response Product / application
- Input
- Verified outcome, citations, residual uncertainty
- Output
- Plain-language answer with evidence and action receipt
- Implementation
- Channel response; audit references
- Failure boundary
- Do not report an action as completed while it is still pending.
21 · Traces & audit Observability / security
- Input
- Correlated spans, policy decisions, operation IDs
- Output
- Latency and incident reconstruction without raw secrets
- Implementation
- OpenTelemetry; Application Insights; audit store
- Failure boundary
- Redact tokens and control access to work-context traces.
22 · Evaluation & regression Quality engineering
- Input
- Permission personas, adversarial cases, tool traces
- Output
- Quality and isolation scores; release decision
- Implementation
- Versioned evaluation dataset and run records
- Failure boundary
- A fluent answer can still fail authorization or source fidelity.
23 · Release & recovery Platform / release engineering
- Input
- Passed checks, pinned versions, cohort metrics
- Output
- Canary, promotion, rollback, or disablement
- Implementation
- CI/CD manifest; feature flags; kill switch
- Failure boundary
- Code rollback cannot reverse an external side effect.
24 · Economics & feedback Product + FinOps
- Input
- Model/tool usage, retries, human effort, accepted tasks
- Output
- Unit cost and evidence-backed improvement backlog
- Implementation
- Cost ledger; outcomes dashboard
- Failure boundary
- Low token cost does not prove the task created value.
Evaluate decisions, not just fluent answers
Build a versioned evaluation set containing ordinary requests and adversarial cases: inaccessible documents, ambiguous environment names, stale metrics, conflicting commitments, injected instructions in retrieved text, changed approval scope, and provider timeouts after submission.
Use model-assisted evaluation for explanation quality and evidence relevance. Use deterministic assertions for forbidden actions, tenant isolation, expiry, and plan binding. Foundry supports application evaluation workflows, but a model score cannot establish that an authorization invariant held. Evaluate a generative AI application ↗.
Release an agent version against a fixed evidence corpus first, then a constrained read-only pilot. Record unsupported claims, unresolved conflicts, tool errors, evidence coverage, and cost per useful recommendation. Track approved operations separately from verified outcomes. A high approval rate could mean a useful product or an overly permissive reviewer; it is not a sufficient success metric alone.
A practical product, built in increments
The first release should answer one recurring question for one engineering organization: which staging resources deserve owner review before the next launch? Deliver a cited recommendation with exact resource scope and explicit missing evidence. Keep execution disabled while measuring whether owners find the suggestions useful.
The second release adds durable review records and handoff to an existing change process. Only after identity isolation, negative tests, operational recovery, and the chosen integration's production suitability are established should a narrowly scoped executor be considered.
Measure time from question to reviewable recommendation, owner acceptance, incorrect or unsupported recommendations, retrieval failure rate, p95 latency, and cost per resolved review. For actual changes, compare verified resource outcomes and realized cost effects over an appropriate observation window. Do not equate proposed savings with money saved.
The product value is a shorter path from scattered evidence to a defensible decision. Work IQ contributes the organizational context. Azure provides independently authorized resource facts. Foundry coordinates the reasoning. The application owns the boundary between a plausible answer and an operation that can be trusted.