An agent foundry solution is the governed platform and delivery path used to build, evaluate, publish and operate AI agents. An agent differs from a text assistant when it can select tools, retrieve state and take multi-step action. That authority creates the value and the risk. The implementation checklist must therefore define what the agent may know, decide and do for each identity and business state, then prove those boundaries under realistic and adversarial conditions.
Use this checklist with the agent foundry scope and cost guide, the agent foundry FAQ and the agent governance checklist. Product names and features evolve quickly; keep platform documentation, preview status and regional support in the release baseline.
1. Define the use case and authority envelope
Name the user, trigger, desired outcome, decision deadline and accountable process owner. Decompose the work into read, reason, propose and act steps. Classify each action by consequence, reversibility, value limit and required approval. For an invoice agent, reading an approved invoice is different from changing supplier bank details or releasing payment. Define prohibited outcomes and stop conditions before selecting models or frameworks.
- Document eligible users, business states, data classes, tools and action limits.
- Name human approvers for consequential, ambiguous or irreversible actions.
- Define fallback, escalation and user-visible uncertainty behavior.
- Set quality, safety, latency, reliability and cost guardrails.
- Record legal, privacy, records, employment and sector-specific obligations.
2. Design identity and tools before prompts
Give the agent a distinct workload identity and derive user context through an approved delegation pattern. Authorize every tool call against the current user, tenant, resource, action and business state. Never rely on model instructions to enforce access. Use narrow tools with typed schemas, bounded values, idempotency and clear errors instead of a generic database or shell tool. Separate read and write capabilities and require fresh approval tokens for high-risk actions.
Microsoft describes Foundry Agent Service as a managed runtime with models, instructions, tools, identity, observability and security capabilities. Those platform controls do not decide the application's business authority. Review built-in and custom tool authentication, data routing, preview status, network path and retention. Inventory MCP servers, APIs and connectors as suppliers. Pin versions where supported and test revocation, ownership transfer and compromised credentials.
| Authority tier | Example | Required control | Default failure |
|---|---|---|---|
| Read public | Retrieve approved product guidance | Source allowlist and citation | Return no answer |
| Read restricted | Summarize a tenant case | Delegated identity and resource authorization | Deny without leaking existence |
| Propose | Draft a refund or configuration change | Evidence, limits and named reviewer | Save draft only |
| Execute | Issue refund within policy | Fresh state check, approval, idempotency and outcome verification | Stop and create an owned exception |
3. Govern knowledge, context and memory
Create an approved source register with owner, audience, jurisdiction, effective date, retention and update cadence. Preserve document-level access during indexing and retrieval. Chunk content without separating a rule from its qualification, and return citations that reviewers can open. Define behavior for conflicting or stale sources. Keep system instructions and tool policy in protected configuration, not in retrievable content where a document can override them.
Treat memory as a separate data product. Decide what persists across turns, sessions and users; for how long; for which purpose; and how it is corrected or deleted. Do not promote model inference into a customer fact. Partition tenant and user state cryptographically and logically. Minimize sensitive content in prompts and traces. Test indirect prompt injection through documents, emails, websites, tool output and image text because retrieved content remains untrusted input.
4. Build an evaluation and red-team suite
Create scenarios from normal work, exceptions, policy boundaries, historical failures and deliberate attacks. Record input state, allowed tools, expected evidence, acceptable answer range and forbidden action. Evaluate task completion, groundedness, tool choice, argument correctness, authorization, policy compliance, refusal quality, latency and cost. Human reviewers should have domain competence and a disagreement process. Freeze versions of model, prompt, tools, sources and evaluation data for comparison.
NIST's AI RMF and Generative AI Profile support lifecycle governance, context mapping, measurement and risk treatment. OWASP's agentic guidance highlights risks introduced by autonomous goals, tools, identity, memory and multi-agent interaction. Test prompt and tool injection, privilege escalation, confused delegation, data exfiltration, excessive loops, poisoned memory, forged tool output, replay and denial of wallet. Re-run gates after material model, policy, source or tool changes.
| Evaluation set | Purpose | Metric | Release threshold example |
|---|---|---|---|
| Representative tasks | Prove useful completion | Correct outcome with sufficient evidence | Target by task and cohort, not one blended score |
| Boundary cases | Prove policy and uncertainty handling | Correct refusal, escalation or clarification | No unauthorized consequential action |
| Adversarial cases | Prove resistance to manipulation | Attack success and data disclosure | Zero critical exploit in approved threat set |
| Operational cases | Prove production behavior | Latency, retries, loop depth and cost | Within service and budget guardrails with fallback |
5. Instrument the runtime without creating a data leak
Trace model calls, retrieval, tool selection, policy decisions, approvals, retries and final outcomes with stable run and conversation identifiers. OpenTelemetry's generative-AI conventions provide common telemetry concepts, but teams must decide whether prompt and response content can be recorded. Default to metadata and approved redaction; protect trace access and retention. Capture model, prompt, tool and source versions so a production result can be reconstructed.
Set bounds on steps, tokens, time, concurrent runs, external calls and spend. Detect loops and repeated failures. Use circuit breakers for unhealthy tools and a global control that disables write actions without removing read-only diagnosis. Monitor task outcomes, approval rate, override, unsafe attempts, access denials, unsupported claims, latency, availability and cost per completed task. Acceptance alone is not quality when users rubber-stamp agent proposals.
6. Deploy through shadow, assist and bounded action
Begin offline, then shadow real cases without affecting users. Compare with actual decisions and investigate cohort differences. In assist mode, let users inspect, edit and reject outputs; collect structured reasons without penalizing disagreement. Release to a bounded group with support, incident command and rollback. Enable write authority tool by tool and action by action only after read and proposal quality is stable.
Promote immutable agent configurations through environments. Separate model deployment from application exposure and retain a tested fallback model or manual path where justified. Validate regional capacity, quotas and supplier failure. Use canaries and watch quality and cost, not just HTTP health. Never silently switch to a materially different model for consequential workflows without evaluation and approval.
7. Operate agents as identities and production services
Maintain an inventory of published agents, owner, users, model, tools, data, authority, risk tier and review date. Revoke abandoned agents and credentials. Patch frameworks and connectors, assess model updates and review tool permissions. Investigate incidents with preserved policy and tool evidence. Notify affected process and security owners according to impact. Add every material miss or exploit to regression evaluation.
Review outcomes with process owners: cycle time, human effort, correction, customer impact, control exceptions and unit cost. Sample completed cases for silent errors. Reassess whether the workflow should remain agentic; a stable high-volume path may be better as deterministic automation. Conduct periodic access recertification, knowledge freshness review, restore test and action-disable exercise. Retirement includes state export or deletion, identity revocation, connector removal and records retention.
Example: deploy a customer refund agent
The agent may retrieve an authenticated customer's order, delivery event, contact history and refund policy. It can propose a refund reason and amount within a configured ceiling. A policy service, not the model, determines eligibility and maximum. A staff member sees evidence and approves. The payment tool uses a one-time approval, validates order state and idempotency key, then returns a transaction reference. The agent verifies updated order and customer communication state.
Test another customer's order, forged delivery text, policy conflict, prior refund, split tender, changed bank details, tool timeout, duplicate callback and prompt injection in a support note. Measure correct proposals, reviewer corrections, unauthorized attempts, duplicate prevention, cycle time and customer contacts. Write authority remains disabled if financial reconciliation or access evidence is incomplete.
Final production checklist
- Use case, accountable owner, prohibited outcomes and authority tiers are approved.
- Agent and user identity are enforced independently at every tool and record.
- Knowledge and memory have purpose, access, freshness, retention and deletion controls.
- Representative, boundary, adversarial and operational evaluations meet tiered thresholds.
- Traces preserve versions and policy evidence without uncontrolled sensitive content.
- Step, time, spend and action limits plus manual fallback have been exercised.
- Rollout, incident, model-change, access-review and retirement procedures have owners.
Key takeaways
- Define agent authority before selecting models, prompts or orchestration.
- Enforce identity and policy in tools, not through natural-language instructions.
- Treat retrieved content, memory and tool output as governed and potentially hostile.
- Evaluate useful behavior and unauthorized action under frozen, realistic scenarios.
- Earn write authority gradually and operate every agent as a revocable identity.
Frequently asked questions
Does a managed agent platform provide governance automatically?
It can provide identity, networking, tracing, evaluation and deployment controls, but the organization still defines business authority, data purpose, tool policy, acceptance and response. Validate each platform control against the use case.
Should one model power every agent?
No. Select models by task quality, risk, latency, region and cost, then evaluate. Standardization can simplify operations, but it should not override evidence. Keep application contracts stable enough to test alternatives safely.
When is full autonomy appropriate?
Only when the action is sufficiently bounded, observable and recoverable, policy can be enforced independently, and representative evidence shows acceptable harm and failure. Many valuable agents should remain advisory or require approval.
Conclusion
A production agent platform is an authority system, not a prompt workshop. Explicit tools, identity, evidence, evaluation, telemetry and staged deployment let teams gain useful autonomy while preserving the human and technical controls that make it accountable.