Taking Agents to Production With Foundry Agent Service and Agent Framework

From prototype to production agent

Getting an AI agent to work on a laptop is the easy part. The harder job in a large company is running it safely for thousands of people: giving it an identity, limiting what it can read, recording what it did, and putting it in front of users inside the tools they already have open. Microsoft Foundry Agent Service, together with the open-source Microsoft Agent Framework, is aimed at that gap. The first handles hosting with enterprise controls, measurability and discoverability, and lets you bring agents built with whatever tools you prefer. The second helps you build both single agents and multi-agent workloads with orchestration.

The pitch is that an agent can be deployed straight from a local environment, run under a secure identity with scoped permissions, and be monitored interaction by interaction, so it can be debugged, improved and scaled without anyone losing control. Agents can also be published into familiar tools, with every action traceable, governed and isolated.

The other half of the story is grounding. Agents become useful when they work from real business data: emails, meetings and operational systems feed personalized insights, documents and presentations. Teams build with familiar frameworks, then manage performance, cost and quality across all their agents as the count grows.

What makes enterprise deployment hard

Building an agent has become much easier. Deploying one safely and reliably across a whole organization hasn't. Many of the agents now being written are well past the small pilot stage. Some are chat experiences used by thousands of employees, and others run quietly in the background, occasionally wired into mission-critical systems.

All of them need the same foundations: identity and access control, private connectivity, and telemetry and tracing at the level of a single agent and of the whole fleet. Stitching those together by hand is complicated, which is the problem the Foundry services are meant to remove, so agents run securely, at scale and with full visibility. It helps to picture the alternative. A team that hosts its own agent has to decide how the agent authenticates, which service account it borrows, where the logs go, how one user's data stays away from another's, and who gets paged when it misbehaves. Each of those answers is a small project, and a security review will ask about every one before the agent touches a calendar or a customer record.

The example: a sales meeting preparation agent

The running example is an agent that helps a sales team get ready for customer meetings. Its code is already written, using the Microsoft Agent Framework in Python, although any framework and language could be substituted. It defines a good number of tools, some middleware logic and a workflow, and at this point everything runs locally.

The open question is how to move it into something secure, scalable, compliant and safe across the enterprise. In Visual Studio Code, expanding the AI Toolkit extension offers a deploy-to-hosted-agents action. It packages the agent as written and deploys it inside Foundry as a hosted agent. The same agent that ran locally now appears in the Foundry portal, and the playground can call it to show what the hosting layer adds.

Asking it which important meetings are coming this week demonstrates the newer agent patterns. The agent runs inside a secure sandbox, a microVM, where it reasons, checks the calendar and can write and execute code, much as coding agents such as GitHub Copilot CLI or Claude Code do.

Identity, isolation and guardrails

Several things happen the moment the agent is deployed, and the next image shows where that identity and permission setup surfaces in the portal.

• The agent receives its own unique ID from Microsoft Entra. Any action it takes, such as reading a calendar, can be traced back to it. With that identity it can reach resources autonomously under its own scoped permissions, or it can act on behalf of a person in the loop using that user's permissions instead.
• Each user who starts an agent session gets a dedicated secure microVM. If two salespeople ask questions at the same moment, each has a separate agent instance, so the information from each session is read, written and stored in its own space.
• For every interaction, the service checks policies and guardrails the organization has defined, covering things like content filtering, protection against prompt injection and the use of copyrighted material. Precise control over what the agent may do and access comes from setup that happened automatically at deploy time.

Back in the playground, the agent returns its answer. Based on the signals it gathered and looped through, one customer account, Zava DIY, comes out as the top priority. In this case the agent worked on the user's behalf, with that person's identity and permissions, to look at the calendar and surface the accounts that deserve attention. Given that it needs to read an inbox, a calendar, data and file stores, having the right access controls in place is exactly what's required for a compliant system.

Monitoring and publishing

Two more enterprise needs come straight from Foundry. The first is observability. The portal provides monitoring and traces, so you can follow every conversation, see how the agent goes about answering each question and check the agent's overall health.

The second is discoverability. Once an agent runs, it still has to reach the people who need it, and nobody enjoys building a new app and hoping everyone finds the link and bookmarks it. If a company already lives in Microsoft 365 and Teams, a Publish button can take any agent deployed in Foundry and register it in those services. People then find it and use it where they already work, on a desktop or on a phone away from the office. In Microsoft 365 the agent shows up in the Copilot Chat experience, and it's available in Teams as well.

The intelligence layer behind grounded answers

Foundry also integrates with Microsoft's unified intelligence layer for AI, which keeps agents grounded in the right knowledge and business context so their output is relevant. That goes well beyond what a single-source MCP server offers. Three pieces make it up.

• Work IQ supplies context about how a person works: connections to email, calendar, past meetings, Teams chats, files and more.
• Fabric IQ adds context over connected business operations, such as sales data, customer records or logistics.
• Foundry IQ combines several knowledge sources for an agent, from structured data and databases to unstructured material in cloud stores, and even images can be retrieved by agentic processes.

In the first run, only the calendar lookup was visible, which is the Work IQ piece. The more advanced agent uses all three.

A fuller run: preparing for the Zava meeting

The same agent has access to all three IQs through the tools and skills it's been given. Back in the playground, a note from the agent's earlier output flags an important Zava meeting, so the next request asks it to help prepare for that meeting.

Inside the sandbox it does what was just described. It consults Work IQ for correspondence, pulling emails and Teams conversations about Zava. It reaches into Fabric IQ for usage data, purchasing patterns and contract details. And it searches sales enablement and marketing material through Foundry IQ to find what's most relevant to that customer.

The agent also carries a few skills built on the popular agent skills pattern. One generates a PowerPoint presentation and another produces briefing documents in Word. It returns two linked files: a Word briefing for the internal team and a custom deck for use with Zava.

• The briefing synthesizes the context pulled from the intelligence layer, plus relationship content from the CRM system, recent communications from the user's correspondence, business analytics on health, usage and metering, and support tickets from the ticketing system. The result is a single preparation document with recommended discussion topics.
• The presentation is personalized for this specific customer interaction and uses the company's brand colors. It combines material from Fabric IQ and Foundry IQ into talking points and customer-specific insights on recent activity, along with business operations data, campaign metrics, and new opportunities and services that could take the partnership further.

The value comes from more than deployment: the agents run on top of the intelligence layer, where they reach work data, business data and organizational knowledge on a person's behalf, with tight integration into Microsoft 365.

How it's built

For developers who want to build something similar, the starting point is simpler than the full example. The Azure Developer CLI can initialize a new project, for instance a sales prep agent. Chat-based agents are supported and remain very popular, any framework can be used, including LangGraph, and the service also supports emerging patterns. Templates scaffold the files needed, and from there the project can be debugged locally and deployed. That's a simple agent from a template, with plenty of room for customization.

Going back to the advanced agent shows what's behind it. The code defines tools and knowledge sources, including the three IQs, along with other types of skills that can be added to coding-agent patterns today. At the core, the agent uses the GitHub Copilot SDK, which runs an agentic loop over the defined set of tools. That loop did the reasoning over dozens of files, emails, earlier meetings and operational and service data, and the recommendations came out of it.

The Microsoft Agent Framework ties the pieces together and adds things like middleware. One example rule: if the coding agent tries to generate one of those documents without enough data from the three IQs, the middleware blocks it, since output without that grounded data is almost guaranteed to be hallucinated. Patterns like this matter when you scale an enterprise deployment, with quality controls spanning a whole sales team plus extra guardrails. The full benefit appears when both frameworks and patterns are combined and hosted inside Foundry Agent Service.

Running a fleet

Once several agents are running, the next question is monitoring and managing them, and that works because everything runs inside Foundry. The portal shows performance and cost for the entire fleet in one view: agent health and alerts (in the demo, all healthy and no alerts yet), estimated cost, success rates and token usage, with drill-in detail on run volumes for the top agents. The best and worst agents by success rate show which ones need attention.

Everything needed to go from experimentation to production, and to publish to all end users, is built in with full observability. The whole point is cutting the complexity of building and deploying agents safely and reliably across an organization. For anyone ready to try it, the route is to start a first project in the Foundry portal and browse Microsoft's public samples to find the right SDK.

A practical order of work follows from all this. Start with a small agent from a template and get it running locally. Add tools and knowledge sources one at a time, with middleware that refuses to proceed when grounding is missing. Deploy to the hosted environment early, so identity, isolation and tracing are exercised long before real users arrive. Publish to the chat tools people already use only after the traces look sane, and keep the fleet view open once several agents are live, because that is where cost creep and falling success rates show up first. Teams that follow this sequence tend to find problems while they are still cheap to fix.

Why local and hosted behave so differently

It's worth separating what the developer wrote from what the platform adds. The tools, middleware and workflow in the sales agent are ordinary application code, and they behave the same on a laptop as in the cloud. What changes after deployment is everything around that code. An identity exists, sessions are isolated, policies are evaluated on every interaction, traces accumulate, and a publishing path opens. None of that required rewriting the agent, which is why the demo treats deployment as a single action in an editor and not as a migration project.

Three questions summarize the approach, and each maps to a layer described above.

• Who is acting? The Entra identity answers it, whether the agent uses its own scoped permissions or borrows a user's.
• Where does the work happen, and who can see it? Per-user microVM sandboxes keep sessions apart, and the organization's content and injection policies apply on every call.
• What did it do, and is it doing well? Traces, conversation views, health indicators, cost and success-rate summaries answer that, per agent and across the fleet.

Guardrails inside the code

Platform guardrails don't replace guardrails written into the agent itself. The middleware rule that blocks document generation when the three IQs haven't supplied enough data is a good illustration, since it enforces a quality bar that no generic policy could know about. A briefing built without CRM history or usage figures would still look polished, and a salesperson might walk into a customer meeting relying on invented details. Stopping that at the code level, before a file is even produced, is cheaper than catching it afterward.

The same thinking explains why the demo bundles skills as separate, reusable pieces. A skill that builds a deck and a skill that writes a briefing can each be tested, versioned and reused by other agents, while the agentic loop decides when to call them. Combining that loop, the framework's middleware and the hosting layer gives three places to apply control: how the agent reasons, what it's allowed to emit, and what the environment lets it do.

Things to weigh before copying the pattern

The example shows a best case in which every data source is connected and permissions are tidy. In practice, the quality of the briefing depends on the quality of the underlying CRM, ticketing and analytics data. Scoped permissions only help when they've actually been scoped, and an agent acting under a user's own access can see everything that user can see, so overly broad accounts become overly broad agents. Fleet dashboards are useful for spotting the weakest agents, but someone still has to read the traces and decide whether a low success rate points at the model, a tool, a missing data source or a guardrail that's set too tightly.