A Microsoft Foundry Agent solution should be scoped as a business application with probabilistic reasoning and tool access, not as a free-standing assistant. The platform can host and scale agents, connect models and tools, integrate identity and expose evaluation and tracing capabilities, but the adopting team still owns the workflow, data permissions, tool safety, user experience, operating objectives and risk decisions. Start from a bounded task such as preparing a support case, retrieving approved knowledge or drafting a controlled action. Add execution authority only after the read and draft paths produce reliable evidence.
The source record uses the older phrase 'Agent Foundry'; current Microsoft documentation calls the product Microsoft Foundry and the managed capability Foundry Agent Service. This guide uses current naming while preserving the article ID. The Foundry agent implementation checklist provides detailed launch tasks, and the Foundry solution FAQ covers architecture and safety questions. Service features, previews, regions, quotas and prices change; verify them for the intended subscription and deployment date.
1. Define the workflow and agent authority
Map trigger, user, approved knowledge, decisions, tools, records, exception route and durable outcome. Decide whether the agent reads, drafts, recommends or executes. Define prohibited actions and data, maximum steps, time and spend, approval conditions and fallback. A support agent might retrieve entitled product information and draft a response, while refund execution remains a typed tool with amount limits and human approval. Keep those controls in the application and tool layer rather than relying on an instruction to 'be careful.'
Write acceptance measures before choosing models: grounded answer quality, tool selection, parameter accuracy, policy compliance, escalation, latency, cost and reviewer effort. The AI solutions agent scope guide offers vendor-neutral planning. Use it to challenge platform assumptions: if deterministic search and workflow rules solve the problem more reliably, an agent may add unnecessary operating risk.
2. Choose the Foundry agent type deliberately
Microsoft's current Agent Service overview distinguishes prompt agents, workflow agents and hosted agents. Prompt agents are configuration-led; workflow agents support branching and human steps; hosted agents run custom code in containers. As of the documentation updated March 25, 2026, workflow and hosted agents carry preview qualifications for some capabilities. Preview status, networking and support constraints should be treated as architecture inputs, not footnotes.
Choose the least complex type that satisfies control and orchestration needs. Prompt agents fit bounded conversational retrieval and tools. Workflow agents may suit visible multi-step coordination when their current limitations are acceptable. Hosted agents offer code control and framework choice but add image, dependency and runtime responsibilities. Record portability, state ownership, endpoint stability, test strategy and exit for each option. Do not adopt multi-agent choreography where one explicit workflow is easier to evaluate and operate.
| Decision | Prompt agent | Workflow agent | Hosted agent |
|---|---|---|---|
| Primary fit | Configured single-agent assistance | Declarative multi-step flow | Custom orchestration code |
| Control surface | Instructions, model and tools | Branches, steps and approvals | Application code and container |
| Main tradeoff | Less custom orchestration | Preview and feature constraints | More engineering ownership |
| Test focus | Grounding and tool policy | State transitions and handoffs | Code, dependencies and runtime |
| Exit artifact | Definitions, prompts and evaluations | Workflow definition and contracts | Source, image and protocol |
| Buyer action | Verify current limits | Verify preview suitability | Own secure build and operations |
3. Design identity, network, data and tools
Use separate resources and roles for platform administration, agent development, invocation and tool execution. Give each agent or workload narrowly scoped identity; preserve user context where downstream authorization requires it. Validate every tool input and output, apply allowlists and business limits, and make side effects idempotent. Protect secrets in managed stores and avoid exposing them to model context. Isolate untrusted retrieved content from instructions and treat model output as untrusted input to rendering and downstream systems.
Microsoft's baseline Foundry chat architecture demonstrates private endpoints, controlled outbound traffic and customer resources for state in a production-oriented baseline. It is a reference, not a universal bill of materials. Tailor regions, availability, firewall, search, storage and database decisions to the workload. Document where prompts, conversations, files, traces and evaluation data reside, who can access them and how they are deleted or exported.
4. Evaluate behavior and agentic threats
Create a versioned test set with ordinary, edge, unauthorized, ambiguous and adversarial cases. Score groundedness, completeness, tool choice, arguments, postconditions, refusal, escalation and user correction effort. Evaluate the complete agent version: model, instructions, retrieval, tool schemas, policy and application. NIST's AI RMF provides a cross-sector structure for governing, mapping, measuring and managing AI risk. Use context-specific thresholds and named risk acceptance.
Threat-model goal hijack, indirect prompt injection, poisoned knowledge, excessive agency, credential leakage, unsafe output handling and denial of wallet. The OWASP Agentic Top 10 provides current categories and mitigations. Test that documents cannot silently change tool policy, that one tenant cannot retrieve another tenant's content, and that approval cannot be forged by conversational text. Red-team failures should become automated regression cases and architecture changes.
| Release evidence | Measure or test | Required owner |
|---|---|---|
| Task quality | Representative grounded and tool-use evaluation | Product owner |
| Authorization | Cross-role, cross-resource and cross-tenant denial | Security and data owners |
| Action safety | Limits, approval, idempotency and postcondition | Workflow owner |
| Resilience | Timeout, dependency failure, retry and fallback | Service owner |
| Privacy | Data path, retention, support access and deletion | Privacy owner |
| Economics | Accepted-task cost at normal and peak demand | FinOps or business owner |
5. Operate versions, traces and incidents
Trace model calls, retrieval, tool decisions, policy results and latency with stable correlation, while redacting or minimizing sensitive content. OpenTelemetry signals provide a vendor-neutral vocabulary for traces, metrics and logs that can complement platform telemetry. Monitor task outcomes, source failures, tool errors, denials, approval age, token or model consumption, latency, user corrections and safety events. Dashboards should lead to owned action, not accumulate every available metric.
Publish immutable versions and promote them through environments. Define rollback for agent configuration and application code, plus a kill switch that disables side-effecting tools without blocking every manual process. Incident procedures should cover compromised knowledge, leaked credentials, unsafe actions, provider degradation and unexpected cost. Preserve relevant evidence and determine affected conversations, tools and records. Model changes and platform feature changes need regression evaluation even when application code is unchanged.
6. Model cost and deliver a representative slice
Cost includes models, agent runtime, search, storage, databases, network, telemetry, evaluation, security, support and human review. Microsoft's standard agent setup documents bring-your-own storage, search and conversation-state resources and minimum throughput assumptions that can materially affect small workloads. Verify current pricing and region availability rather than reproducing a static estimate. Calculate cost per quality-accepted task, not only tokens per request.
Deliver through charter, architecture and threat model, offline evaluation, read-only pilot, approved tool pilot and controlled production. The first vertical slice should use real identity, authorized knowledge, one typed tool, telemetry, support and rollback. Include an injection case and dependency failure. Expand tools and users only when outcome, permission, safety, service and cost gates pass. The business process solutions guide helps compare agentic automation with conventional workflow design.
Set commercial and technical boundaries for platform dependence. Decide which Microsoft-managed features are essential and which can use stable application contracts. Keep business logic out of portal-only configuration when it must be reviewed, tested or ported. Export definitions and evaluation results on a schedule, and test that a replacement model or runtime can still call the organization's typed tools under the same policy. Exit planning is not a prediction that the platform will fail; it is a way to prevent routine feature or pricing changes from becoming emergency architecture work.
Production acceptance should include capacity and quota behavior. Test peak concurrent requests, long conversations, large retrieval results, tool latency and dependency throttling. Define timeouts, retry budgets, queue limits and user messages so a provider limit does not trigger an uncontrolled retry storm or runaway spend. Monitor cost and quota by agent version and business workflow. Ask who can raise a quota, who approves the resulting cost and what degraded mode applies while capacity is constrained. These are service decisions, not merely Azure configuration.
Key takeaways
- Use current Microsoft Foundry naming and verify service status for the target region.
- Define agent authority, budgets, approvals and fallback outside conversational instructions.
- Select prompt, workflow or hosted agents from control and lifecycle needs.
- Evaluate the whole agent version with unauthorized and adversarial cases.
- Instrument retrieval, policy and tools while minimizing sensitive trace content.
- Model all platform resources and human review per accepted task before expansion.
Microsoft Foundry Agent solution FAQ
Is Foundry Agent Service the same as a model endpoint? No. It provides an agent runtime and integrations around models, instructions, conversations and tools. The application still needs product logic, access policy, evaluation and operations.
Which agent type should a team start with? Usually the simplest type that meets orchestration and control requirements. A prompt agent can prove a bounded read or draft workflow; custom hosted code is justified when explicit logic or framework control is necessary.
Does private networking prevent prompt injection? No. It constrains network paths. Prompt injection is an application and data-trust problem requiring content separation, limited tools, authorization, validation, evaluation and monitoring.
What should remain portable? Keep workflow definitions, prompts, tool contracts, evaluation cases, source mappings, policies, data exports and operational records under organization control. Portability reduces exit risk even when the runtime is platform-specific.
Conclusion
A Microsoft Foundry Agent solution is production ready when the organization can explain its authority, data paths, version, tool decisions, operating limits and cost. Start with one representative workflow and one narrow tool, build identity and policy into every request, and use evaluation as the release contract. Foundry can reduce platform work, but accountable delivery still depends on the surrounding application and team. Expand capability only when difficult cases, failure and rollback are as visible as the successful demo.