Azure AI Foundry Agent Service Enterprise Guide (2026)

Pattern 1 — Trading floor research + execution agent

The trading floor agent runs inside a custom Foundry-powered application embedded in the trader workstation. It grounds on Bloomberg and Refinitiv news feeds via OpenAPI tools, the firm’s internal research library in SharePoint via Graph connector with MNPI segmentation enforced by sensitivity label, the position book in Azure SQL, and the historical trade store in Fabric OneLake. Function tools wrap the order management system for staged-order creation, the risk system for pre-trade limit checks, and the compliance engine for restricted-list verification. The agent uses a planner-executor orchestration pattern — a reasoning model plans the multi-step research path, a faster model executes each tool call, and a final reasoning pass summarizes the recommendation with full citation. Defender for Cloud AI monitors for any cross-segment data leakage. FINRA-aligned audit logs every prompt, tool call, and recommendation through Purview audit and the firm’s WORM-compliant archive.

Pattern 2 — Clinical trial protocol agent for life sciences

The clinical trial agent grounds on the protocol library, the case report form (CRF) data captured in the EDC system, the adverse event database, and the regulatory submission archive. EPC Group wires it to Azure Health Data Services for FHIR-conformant patient data access, function tools for site enrollment status lookup, eCRF query generation, deviation reporting, and adverse event coding. The orchestration pattern is supervisor — a parent supervisor agent classifies the incoming request (protocol question, eligibility check, AE coding, regulatory question) and routes to a specialist child agent with the right tool list and grounding scope. GxP-aligned validation is enforced through the evaluation harness with locked test datasets per release, electronic signature on every model and prompt change, and Part 11 audit trail through Purview. HIPAA BAA covers the underlying Azure OpenAI and Foundry services. Cross-link to /microsoft-purview-data-governance-enterprise-2026 for the Purview baseline.

Pattern 3 — Contract review agent for legal operations

The contract review agent ingests an inbound third-party contract, grounds against the firm’s playbook (approved clauses, prohibited clauses, fallback positions), and produces a structured redline with rationale per change. Knowledge sources include the playbook library in SharePoint with sensitivity-label gating, the precedent contract corpus in the vector store, and the regulatory-clause library covering data protection (GDPR, CCPA), security (SOC 2 attestation flow-through), and indemnification standards. Function tools wrap the contract lifecycle management (CLM) system for clause-by-clause checkout, the e-signature platform for routing, and the conflicts-check system. The agent uses a handoff orchestration pattern — a triage agent classifies the contract type, hands off to a specialist agent per contract family (MSA, DPA, NDA, SOW, vendor) with the right playbook scope. Human-in-the-loop sign-off is mandatory on every redline before send.

Pattern 4 — IT incident commander agent on Sentinel + Defender XDR

The IT incident commander agent runs inside a custom SOC console powered by Foundry. It grounds on the Sentinel incident feed, the Defender XDR alert graph, the asset inventory in Microsoft Defender for Endpoint, the configuration management database (CMDB) in ServiceNow, and the historical incident runbook library. Function tools wrap Sentinel for KQL execution, Defender for Cloud for posture queries, Entra ID for token revocation and conditional access policy changes (under approval gate), and ServiceNow for incident creation and update. The orchestration pattern is supervisor with specialist children — an Identity child for Entra-side response, an Endpoint child for Defender-side response, a Network child for Azure Firewall and NSG changes, and a Communications child for stakeholder notification drafting. Human-in-the-loop gates govern every change-the-state action. Cross-link to /microsoft-defender-xdr-enterprise-2026 for the Defender XDR baseline.

Pattern 5 — Supply chain planner agent for manufacturing

The supply chain agent grounds on the demand forecast in Fabric OneLake, the inventory position from D365 Supply Chain Management, the supplier lead-time history, and the logistics-route library. Function tools wrap the MRP run for scenario simulation, the supplier portal for purchase order issuance under approval gate, the freight carrier APIs for booking, and the warehouse management system for slotting changes. The agent uses a planner-executor pattern — a reasoning model plans the multi-step replenishment scenario across constraints (lead time, MOQ, dual-source, transportation cost), an executor model runs each function tool in sequence with backpressure-aware retry, and the result is a costed plan handed to the planner for sign-off. The Foundry observability surface tracks per-run cost and latency so the planning team can balance reasoning quality against decision speed during a supply disruption.

Pattern 6 — Finance close agent on Dynamics 365 + Fabric

The finance close agent automates the recurring month-end and quarter-end close. It grounds on the trial balance in D365 Finance, the consolidation worksheet in Fabric, the close calendar in Project Operations, and the SOX control library in the GRC platform. Function tools wrap the journal entry creation in D365, the close task certification in the close-management platform, the variance analysis prompt against prior-period and forecast data, and the auditor evidence package generation. Orchestration is supervisor with a Reconciliation child agent per balance-sheet account family, a Variance Analysis child for material-deviation explanation, a Disclosure child for footnote drafting, and a Controls child for SOX control attestation. Every artifact produced is signed off by a human controller before posting, and the agent surfaces the SOX control map (cross-link to /standards-alignment) as the documentation evidence layer for the external audit.

Use case selection, Assistants API migration plan, capacity model

Phase one selects the right first Foundry agent for the customer maturity profile, inventories any existing Azure OpenAI Assistants API surface that should migrate to Foundry, and produces a capacity model sized against projected run volume, tool-call volume, and model mix. EPC Group runs a two-week assessment ending in a costed roadmap, an agent backlog ranked by ROI and risk, an Assistants-API-to-Foundry migration sequence (if applicable), and a PTU-versus-PAYG capacity recommendation aligned to the Assess stage of the EPC Group Lifecycle.

• Use case backlog with ROI, complexity, and risk weighting
• Inventory of existing Azure OpenAI Assistants API usage with a Foundry migration sequence
• Capacity model — run volume, tool-call volume, model mix, PTU vs PAYG, three-year TCO
• Code-first Foundry vs Copilot Studio decision per agent in the backlog

Tool taxonomy, knowledge architecture, orchestration topology

Phase two designs the function-tool catalog, the knowledge architecture (vector stores, connectors, refresh cadence), the orchestration topology (single agent, handoff, supervisor, planner-executor), the evaluation strategy (predefined plus custom evaluators with test datasets), and the observability plan (OpenTelemetry destinations, Content Safety rules, Defender for Cloud AI scope). EPC Group ships the design document with sequence diagrams, tool-by-tool schemas, knowledge-source matrices, and the responsible AI risk register reviewed by the customer compliance function before any code is written.

• Tool catalog with JSON Schema definitions and developer-owned execution contracts
• Knowledge architecture — vector stores, ingest sources, refresh, sensitivity label scope
• Orchestration topology — single, handoff, supervisor, or planner-executor per use case
• Evaluation plan and responsible AI risk register, signed off pre-build

Agent build with SDK, vector ingest, and evaluation gates

Phase three is the code-first build sprint — Azure SDK (Python, .NET, JavaScript) for agent and tool implementation, vector-store ingest pipelines for knowledge sources, function-tool execution endpoints (Azure Functions, Container Apps, AKS, or on-prem call-out via Azure Relay), evaluation suites running in CI/CD, and the observability instrumentation. EPC Group ships in two-week increments to a controlled tester cohort, captures evaluation metrics and live telemetry, and tunes against measured groundedness, relevance, and tool-call accuracy rather than building in a vacuum and launching cold.

• Two-week sprints with controlled tester cohort and live evaluation feedback
• Vector-store ingest pipelines with refresh, deduplication, and chunking tuning
• CI/CD-gated evaluation suites — pre-merge groundedness, relevance, F1 thresholds
• OpenTelemetry instrumentation wired to Azure Monitor and Application Insights from day one

Content Safety, Defender for Cloud AI, Purview audit, abuse monitoring

Phase four anchors the agent in the Azure responsible AI baseline — Azure AI Content Safety configured for jailbreak, protected material, PII, and groundedness checks; Defender for Cloud AI workload protection for prompt injection, model theft, and exfiltration; Purview audit log capture when grounding touches Microsoft 365 content; and customer-managed abuse monitoring settings consistent with the customer data residency and privacy posture. The customer security and compliance functions sign off against a documented control map before production cutover.

• Azure AI Content Safety rules tuned per use case with severity thresholds
• Defender for Cloud AI workload protection covering the Foundry project and dependencies
• Purview audit log integration when grounding touches Microsoft 365 content surfaces
• Customer-managed abuse monitoring posture aligned to data residency and privacy commitments

Managed Foundry agents with senior-architect escalation

Phase five is steady-state operation. EPC Group provides managed Foundry agent services — model upgrade evaluation, evaluation harness maintenance, vector-store ingest health, tool-execution-endpoint SRE, capacity rebalancing across PTU and PAYG, and senior-architect escalation for incident response. Quarterly governance review with the customer security and compliance officers. Continuous responsible AI monitoring with content safety and Defender for Cloud AI signal triage routed into the broader Defender XDR incident graph.

• Monthly agent health — evaluation trend, tool-call accuracy, capacity burn, model cost
• Quarterly governance review with customer security and compliance officers
• Continuous responsible AI signal triage routed into Defender XDR for incident response
• Senior-architect on-call escalation tied to incident severity matrix

What is Azure AI Foundry Agent Service and how is it different from Azure OpenAI Service?

Azure AI Foundry is the unified platform that replaces the standalone Azure OpenAI Service portal experience. The Foundry Agent Service is the agent-runtime capability inside AI Foundry — a code-first, server-managed runtime that handles agent lifecycle, thread state, parallel tool calling, run scheduling, evaluation, and observability. Azure OpenAI Service models (GPT-4o, GPT-4.1, o-series, GPT-5-class) are still the underlying model layer; Foundry adds the agent runtime, the unified Foundry catalog (open-weight models alongside Azure OpenAI), the evaluation harness, the responsible AI tooling, and project-level governance. Customers using the legacy Azure OpenAI standalone portal are migrating to Foundry projects as Microsoft consolidates the experience. The model endpoints remain Azure OpenAI; the developer surface is now Foundry.

How do I migrate from the Azure OpenAI Assistants API to the Foundry Agent Service?

Foundry Agent Service maintains a compatible API contract with the Azure OpenAI Assistants API — threads, runs, messages, and steps remain first-class objects with the same semantics, and the SDK call shapes are nearly identical. A typical migration is three steps. First, point the SDK base URL at the Foundry project endpoint and update the authentication to use Azure RBAC against the Foundry project (rather than Azure OpenAI resource RBAC). Second, recreate agents in the Foundry project — the create-agent payload accepts the same model, instructions, and tool list with minor schema additions for Foundry-specific features like knowledge sources and connector tools. Third, migrate any existing thread state if continuity matters; new threads typically just flow into the Foundry runtime. EPC Group has run this migration across customers with multi-agent Assistants-API deployments in 2025 and ships the migration plan as part of the Phase 1 Foundry Accelerator deliverable.

When should I use Azure AI Foundry Agent Service versus Microsoft Copilot Studio?

Use Foundry Agent Service when the build team is code-first (Python, .NET, JavaScript developers), when the agent will run inside a custom application or product rather than inside Microsoft 365 surfaces, when fine-grained control over the model call (model, temperature, function-calling shape, streaming, reasoning-budget) is required, when the integration surface is dominated by non-Microsoft systems or by APIs that need OpenAPI-tool import, when token-level cost optimization and PTU reservation matter, or when multi-agent orchestration patterns (planner-executor, supervisor-with-specialists) require explicit programmatic control. Use Microsoft Copilot Studio (see /microsoft-copilot-studio-agents-enterprise-2026) when the build team is low-code, when the agent lives primarily inside Teams, Microsoft 365 Copilot, or web chat, and when out-of-the-box Purview governance is preferred over custom controls. Many enterprises run both — Foundry for the product-grade and custom-application agents, Copilot Studio for the Microsoft-surface departmental agents.

What is the cost model for Foundry Agent Service — PTU versus pay-as-you-go?

Foundry Agent Service runtime is billed on the underlying model and tool surface. Model calls follow Azure OpenAI pricing — Provisioned Throughput Units (PTU) for reserved capacity with predictable latency and a monthly or annual reservation discount, or pay-as-you-go (PAYG) per input and output token for variable workloads. Code Interpreter sandbox sessions are billed per session-hour. File Search vector-store storage is billed per gigabyte-month, and ingest is billed per token embedded. Function tools execute in the customer Azure subscription (Functions, Container Apps, AKS) and bill against those services directly. Defender for Cloud AI workload protection has its own SKU. EPC Group sizes the capacity model in Phase 1 using projected run volume, average tool-call count per run, model mix, and channel-mix to recommend a PTU-plus-PAYG hybrid that minimizes idle reservation cost while protecting latency for the primary user-facing workload.

How does multi-agent orchestration work in Foundry Agent Service?

Foundry supports multi-agent orchestration through three composable patterns. The handoff pattern uses a triage agent that classifies the incoming request and transfers thread ownership to a specialist child agent. The supervisor pattern keeps a parent agent in conversational control and uses function tools (each tool wraps a child agent invocation) to delegate discrete subtasks; the parent reasons over the consolidated result. The planner-executor pattern uses a reasoning model to produce a structured multi-step plan and a faster executor model to run each step, with a final reasoning pass over the consolidated output. Foundry exposes these patterns through SDK primitives rather than a no-code orchestrator, which gives developers explicit control over the cost-versus-quality trade-offs at every step. EPC Group selects the pattern per agent in the Phase 2 Design deliverable based on subdomain separability, response composition needs, and token cost profile.

How does Foundry handle responsible AI, content safety, and prompt injection defense?

Foundry agents run inside the Azure responsible AI layer with multiple defenses. Azure AI Content Safety runs pre-call and post-call moderation for jailbreak attempts, protected material detection, groundedness violations, PII surfacing, and harmful content across six harm categories — each with severity thresholds the build team tunes per use case. Defender for Cloud AI workload protection monitors the Foundry project for prompt injection, model theft attempts, sensitive-data exposure, and adversarial input patterns, and routes alerts into Microsoft Defender XDR and Sentinel. Customer-managed abuse monitoring lets enterprises opt out of human review of stored prompts for highly regulated workloads. Purview audit covers Microsoft 365 content access through Foundry knowledge sources. The combined layer is the production-grade equivalent of what Copilot Studio bundles in low-code — but exposed to developers for explicit configuration and tunable thresholds.

Can I deploy Foundry agents in HIPAA, FedRAMP, FINRA, or CMMC environments?

Yes. Azure AI Foundry and the Foundry Agent Service are covered by the Microsoft Business Associate Agreement (BAA) for HIPAA, are on the FedRAMP High path inside Azure Government, support FINRA-aligned audit through Purview and customer-managed retention, and align to CMMC 2.0 Level 2 boundary controls inside Azure Government for the defense industrial base. The compliance posture is anchored on the customer-chosen Foundry project region, data residency commitments, abuse-monitoring opt-out, and the broader Azure platform compliance baseline. EPC Group runs the Phase 4 governance hardening against the customer regulatory profile, produces the auditor evidence package mapped to the relevant control framework, and cross-links to HIPAA, SOC 2, FedRAMP, FINRA, CMMC, GxP as documented in the standards alignment map.

What does an EPC Group Foundry Agent engagement cost and how long does it take?

EPC Group Foundry Agent engagements are fixed-fee, ranging from $200K to $700K for a first agent depending on complexity, multi-agent orchestration scope, knowledge-source breadth, and evaluation-suite depth. Typical timeline is 10 to 18 weeks across the five-phase accelerator (Assess, Design, Build + Ground, Governance Harden, Operate), with managed Foundry agent services available on a quarterly or annual basis once production is live. The first agent is the most expensive because the platform baseline (Foundry project provisioning, Defender for Cloud AI enablement, Content Safety tuning, evaluation-harness wiring, observability plumbing) is set up once and reused. Subsequent agents land at 40 to 60 percent of first-agent cost. EPC Group is a 29-year Microsoft Solutions Partner with senior-architect-led delivery across 70+ Fortune 500 clients and 11,000+ engagements; the Foundry Accelerator is the standard delivery vehicle for code-first agent programs.