What does Foundry Agent Service provide?
Microsoft Foundry Agent Service offers managed capabilities for building, deploying, and operating agents. It supports configured prompt agents and code-based hosted agents. The choice affects how much application logic the team controls and maintains. Confirm current regional support, feature status, and cost for the design you intend to release.
Select the operating model deliberately
Use the business task to decide how much custom code and coordination is necessary. A simpler configuration may be easier to support, while a specialized workflow may justify a code-based approach. Document which responsibilities belong to the platform and which remain with the application team, including data quality, business rules, and user support.
Test tools as carefully as answers
An agent that writes a good explanation can still perform the wrong action. Validate tool inputs, limit access, and check the result of each important operation. Prevent retries from creating duplicates. Test malicious instructions in retrieved content, unavailable systems, and changes to user permissions. Keep high-impact actions subject to explicit authorization.
Create a release evidence pack
Maintain representative test cases and agreed acceptance thresholds. Record the model, instructions, tools, and configuration used for each release. Include results for ordinary tasks, edge cases, and failures. Review cost per successful task as well as response time, and make the evidence understandable to the business owner approving the rollout.
Prepare support and recovery
Name the team that will investigate incidents and communicate with users. Provide traces that explain which step failed without exposing unnecessary sensitive content. Define when the workflow should stop, request help, or use a manual fallback. Release to a limited group and expand when real operating evidence supports the decision.
Turn the demo into a release specification
Write down the business task, supported audience, information sources, and permitted actions. Include examples of successful completion and appropriate escalation. This becomes the specification against which the agent is evaluated. A demonstration that produces an attractive response does not establish how the service behaves with missing records, different permissions, or an interrupted operation.
For an illustrative internal service assistant, begin with retrieving approved guidance and preparing a draft case. Define submission as a separate action with its own checks. This distinction lets the team assess answer quality before expanding the consequences of a mistake. It also gives support a clear explanation of what the first release is intended to accomplish.
Review the complete Azure deployment boundary
List every system the workflow contacts, the identity used, and the information that crosses each boundary. Ask the responsible team to review network access, secrets, diagnostic records, and administrative privileges for the actual deployment. Selecting an Azure service does not establish that the surrounding application configuration meets the organization's requirements.
Document where application information is stored and which personnel can inspect it. Check the selected region, model, and service configuration against the engagement's requirements. WTA's AI strategy and governance services can help define these acceptance questions; AI-native product engineering connects them to implementation and release evidence. Keep architectural assumptions visible throughout delivery.
Run a realistic failure rehearsal
Choose an operation that updates a business record and interrupt the response after the request is sent. The team should be able to determine whether the update succeeded before attempting it again. Also test expired access, unavailable information sources, and user cancellation. Record what the employee sees and what support needs to investigate each situation.
Give consequential operations an explicit approval path. The approver should see the proposed change and enough supporting context to evaluate it. Approval of one action should not silently authorize unrelated steps. Rehearse rejection and delayed approval as well as acceptance; ordinary enterprise workflows do not always proceed immediately or in the expected order.
Measure the cost of accepted work
Define a successful task in business terms and count the resources consumed across successful and failed attempts. Include retrieval, model use, application infrastructure, and human correction. A low cost per request can hide an expensive service if users repeat requests or reviewers frequently redo the output. Compare the complete process with its existing baseline.
Release to an audience the support team can reasonably serve. Review recurring errors before expanding access. Maintain a record of the application version, its evaluated configuration, and the person approving each release. When a model, source, or tool changes, rerun the relevant business cases. The purpose is to preserve known behavior while making useful improvements, not to freeze the service indefinitely.
Frequently asked questions
Does managed hosting remove application responsibility?
No. The organization still owns the workflow's intended use, information access, business rules, evaluation, and support. A managed service can supply platform capabilities, but the application must be assessed as a whole. Identify which responsibilities belong to Microsoft, the delivery partner, and the customer's operating team before release.
What evidence should approve a production release?
Use results from representative task tests, access checks, failure rehearsals, and a complete cost review. Record known limitations and the people accepting them. A release should also have support ownership and a way to pause or recover the workflow. A successful demonstration alone is insufficient evidence for a wider audience.
Should every new platform feature be enabled immediately?
No. Evaluate the specific business need, current availability, implementation effort, and operating implications. Confirm the feature's status for the chosen configuration and region. Introduce it through a tested change rather than assuming that a newer capability automatically improves the existing workflow or is appropriate for its consequences.
How should a failed business action be handled?
Show an accurate status and preserve enough context for investigation. Before retrying, establish whether the action already completed in the connected system. Where the outcome is uncertain, escalate to an authorized person. Recovery should protect business records from duplicate or contradictory changes while helping employees finish their work.
Published September 18, 2026. Microsoft Foundry Agent Service overview. Related: Microsoft Agent Framework: An Enterprise Guide.
Apply this to your workflow
Explore our AI Delivery Pods & Agentic Platforms service, or discuss this challenge with WTA. Share your current process, the systems involved, and the result you want to achieve.
.svg)
.svg)
.svg)
.svg)
.svg)
.png)
.svg){kind=small}
.png)