An agent that answers a question is a starting point. An agent that completes useful work needs more: an interface users can interact with, memory beyond the current conversation, an appropriate environment for executing code, and a way to recover when work is interrupted.<\/p>\n
Recent Microsoft Agent Framework updates address those needs across .NET and Python. Here\u2019s how to use them\u2014from connecting an agent to your application to running and debugging longer-lived workflows.<\/p>\n
Sign in with az login. Set FOUNDRY_PROJECT_ENDPOINT to your Foundry project endpoint and FOUNDRY_MODEL to your deployed model name.<\/p>\n
Install the packages for the AG-UI and memory examples:<\/p>\n
pip install --pre agent-framework-foundry agent-framework-ag-ui azure-identity aiohttp fastapi uvicorn<\/code><\/pre>\nFor CodeAct, also install the Hyperlight integration on a supported platform:<\/p>\n
pip install --pre agent-framework-hyperlight<\/code><\/pre>\nFor the memory example, set FOUNDRY_MEMORY_STORE_NAME to an existing Foundry memory store configured with supported chat and embedding model deployments. See Foundry managed semantic memory<\/a> for setup and .NET examples.<\/p>\n.NET<\/h3>\n
Create a new Blazor project and install the required dependencies:<\/p>\n
dotnet new blazor -n FoundryAgUi\r\ncd FoundryAgUi\r\ndotnet add package Azure.Identity\r\ndotnet add package Azure.AI.Projects --prerelease\r\ndotnet add package Microsoft.Agents.AI.Foundry --prerelease\r\ndotnet add package Microsoft.Agents.AI.Hosting.AGUI.AspNetCore --prerelease<\/code><\/pre>\nConnect agents to interactive applications with AG-UI<\/h2>\n
A useful agent interface should communicate more than the final answer. Users need to see progress, understand tool activity, approve actions, and interact with results.<\/p>\n
AG-UI provides an open, event-based protocol for that interaction. Microsoft Agent Framework\u2019s integration lets you expose an agent through an AG-UI endpoint and connect compatible frontends, including applications built with CopilotKit or the new<\/u> Blazor AI components for creating agentic user interfaces in .NET.<\/p>\nPython: expose an agent through FastAPI (stable release)<\/h3>\n
Save the following as app.py and run uvicorn app:app –reload:<\/p>\n
import os\r\nfrom contextlib import asynccontextmanager\r\n \r\nfrom fastapi import FastAPI\r\nfrom agent_framework import Agent\r\nfrom agent_framework.ag_ui import add_agent_framework_fastapi_endpoint\r\nfrom agent_framework.foundry import FoundryChatClient\r\nfrom azure.identity.aio import AzureCliCredential\r\n \r\ncredential = AzureCliCredential()\r\nagent = Agent(\r\n client=FoundryChatClient(\r\n project_endpoint=os.environ[\"FOUNDRY_PROJECT_ENDPOINT\"],\r\n model=os.environ[\"FOUNDRY_MODEL\"],\r\n credential=credential,\r\n ),\r\n name=\"ResearchAssistant\",\r\n instructions=\"Help users research topics and explain your findings.\",\r\n)\r\n \r\n@asynccontextmanager\r\nasync def lifespan(app: FastAPI):\r\n async with credential, agent:\r\n yield\r\n \r\napp = FastAPI(lifespan=lifespan)\r\nadd_agent_framework_fastapi_endpoint(app, agent, \"\/ag-ui\")\r\n<\/code><\/pre>\nLearn more: Quickstart: Build agents using the Responses API<\/a>.<\/p>\nThe integration translates agent execution into AG-UI events for streaming responses, tool activity, and other supported interactions.<\/p>\n
Recent Python work extends beyond chat: workflow checkpointing and resumption, improved approval continuity, shared and predictive state updates, and optional A2UI integration for agent-generated interfaces.<\/p>\n
GitHub:<\/strong> Python AG-UI package and quickstarts<\/a> \u00b7 Interactive examples<\/a><\/p>\n.NET: expose a Foundry-connected agent through ASP.NET Core (public preview)<\/h3>\n
This example uses the same Foundry configuration, agent name, instructions, and \/ag-ui endpoint as the Python example. Replace Program.cs with the following and run dotnet run:<\/p>\n
using Azure.AI.Projects;\r\nusing Azure.Identity;\r\nusing Microsoft.Agents.AI;\r\nusing Microsoft.Agents.AI.Hosting.AGUI.AspNetCore;\r\n \r\nstring endpoint = Environment.GetEnvironmentVariable(\"FOUNDRY_PROJECT_ENDPOINT\")\r\n ?? throw new InvalidOperationException(\"FOUNDRY_PROJECT_ENDPOINT is not set.\");\r\nstring model = Environment.GetEnvironmentVariable(\"FOUNDRY_MODEL\")\r\n ?? throw new InvalidOperationException(\"FOUNDRY_MODEL is not set.\");\r\n \r\nvar builder = WebApplication.CreateBuilder(args);\r\nbuilder.Services.AddAGUIServer();\r\n \r\nAIAgent agent = new AIProjectClient(\r\n new Uri(endpoint), new AzureCliCredential())\r\n .AsAIAgent(\r\n model: model,\r\n name: \"ResearchAssistant\",\r\n instructions: \"Help users research topics and explain your findings.\");\r\n \r\nvar app = builder.Build();\r\napp.MapAGUIServer(\"\/ag-ui\", agent);\r\nawait app.RunAsync();\r\n<\/code><\/pre>\nThe updated .NET support for AG-UI uses the new AG-UI .NET SDK, which provides abstractions for the AG-UI events as well as client and server support based on Microsoft.Extensions.AI.<\/p>\n
The .NET hosting integration remains in preview. Both languages support interactive agent experiences, but their capabilities are not identical\u2014use the language-specific examples rather than assuming feature parity.<\/p>\n
These minimal endpoints also need application security before deployment: authenticate callers and authorize access to their sessions. A thread ID identifies a conversation; it does not establish who may access it.<\/p>\n
Docs & Samples: AG-UI Integration with Agent Framework<\/a>, Agent Framework AG-UI samples for .NET<\/a><\/p>\nReuse agent logic across channels<\/h2>\n
AG-UI connects agents to interactive frontends. The new Python agent and workflow channels<\/strong> packages address another integration problem: exposing the same agent logic through different protocols and surfaces.<\/p>\nThe packages provide helpers for OpenAI Responses, Telegram, A2A, and MCP<\/strong>. Those serve different purposes: messaging users, serving API clients, communicating with other agents, and exposing capabilities as tools.<\/p>\nShared session helpers keep the agent-facing code small. For example, inside an async function:<\/p>\n
from agent_framework_hosting import AgentState\r\n \r\nstate = AgentState(agent)\r\n \r\nsession = await state.get_or_create_session(\"demo-session\")\r\nresult = await agent.run(\r\n \"Summarize the research we have collected.\",\r\n session=session,\r\n)\r\nawait state.set_session(\"demo-session\", session)\r\n \r\nprint(result.text)<\/code><\/pre>\nYour application owns the mapping between a channel\u2019s identity and an authorized session, along with storage and concurrency policy. The fixed session ID above is for a local demonstration\u2014not a production identity strategy.<\/p>\n
This separation lets developers reuse agent logic without surrendering control over application routing, authentication, or persistence.<\/p>\n
GitHub:<\/strong> Responses hosting sample<\/a> \u00b7 Telegram hosting sample<\/a><\/p>\nDeep dive:<\/strong> Introducing agent and workflow channels<\/a><\/p>\n\u00a0Add memory through context providers<\/strong><\/h2>\nConversation history preserves what was said. Longer-term memory helps an agent bring useful information into a new conversation without replaying the entire transcript. Memory in Foundry Agent Service integrates with Microsoft Agent Framework through FoundryMemoryProvider, which retrieves relevant memories before a run and submits conversation information for asynchronous memory extraction afterward.<\/p>\n
The following Python example connects both model inference and memory to your Foundry project. Save this as memory_demo.py:<\/p>\n
import argparse\r\nimport asyncio\r\nimport os\r\n \r\nfrom agent_framework import Agent, InMemoryHistoryProvider\r\nfrom agent_framework.foundry import FoundryChatClient, FoundryMemoryProvider\r\nfrom azure.ai.projects.aio import AIProjectClient\r\nfrom azure.identity.aio import AzureCliCredential\r\n \r\nasync def main(message: str) -> None:\r\n async with (\r\n AzureCliCredential() as credential,\r\n AIProjectClient(\r\n endpoint=os.environ[\"FOUNDRY_PROJECT_ENDPOINT\"],\r\n credential=credential,\r\n allow_preview=True,\r\n ) as project_client,\r\n ):\r\n memory = FoundryMemoryProvider(\r\n project_client=project_client,\r\n memory_store_name=os.environ[\"FOUNDRY_MEMORY_STORE_NAME\"],\r\n scope=\"demo-user\",\r\n update_delay=0,\r\n )\r\n async with Agent(\r\n client=FoundryChatClient(\r\n project_client=project_client,\r\n model=os.environ[\"FOUNDRY_MODEL\"],\r\n ),\r\n instructions=\"Use relevant remembered preferences when helping the user.\",\r\n context_providers=[\r\n memory,\r\n InMemoryHistoryProvider(load_messages=False),\r\n ],\r\n default_options={\"store\": False},\r\n ) as agent:\r\n response = await agent.run(\r\n message, session=agent.create_session()\r\n )\r\n print(response.text)\r\n \r\nif __name__ == \"__main__\":\r\n parser = argparse.ArgumentParser()\r\n parser.add_argument(\"message\")\r\n asyncio.run(main(parser.parse_args().message))\r\n<\/code><\/pre>\nFirst record a preference:<\/p>\n
python memory_demo.py \"For project updates, I prefer a short summary followed by action items.\"<\/code><\/pre>\nAfter memory extraction has completed, start a separate process to ask for that preference:<\/p>\n
python memory_demo.py \"How should you format my next project update?\"<\/code><\/pre>\nEach invocation creates a fresh session with the same memory scope. Service-side response storage and local transcript loading are disabled, so the second invocation does not replay the first conversation. Memory extraction is asynchronous: update_delay=0 starts processing without a batching delay but does not guarantee immediate recall.<\/p>\n
For production, derive the scope from authenticated application identity rather than accepting an arbitrary user-supplied identifier. Use an appropriate production credential, apply your application’s memory retention and deletion policies, and evaluate recall quality.<\/p>\n
Azure Cosmos DB remains an alternative through the Python-preview CosmosMemoryContextProvider integration, with hybrid vector and full-text retrieval. See the Cosmos DB memory package<\/a> and technical deep dive<\/a>.<\/p>\nExecute suitable multi-step tasks with CodeAct<\/h2>\n
Some agent tasks involve many small, chainable operations. Asking the model to select a tool, inspect the result, and select another tool at every step can add unnecessary latency and token consumption.<\/p>\n
CodeAct<\/strong> lets the model express suitable sequences as a program and receive a consolidated result.<\/p>\nThis Python example uses a pure calculation tool and a Foundry-connected model client. Save it as codeact_demo.py and run python codeact_demo.py.<\/p>\n
import asyncio\r\nimport os\r\n \r\nfrom agent_framework import Agent, tool\r\nfrom agent_framework.foundry import FoundryChatClient\r\nfrom agent_framework_hyperlight import HyperlightCodeActProvider\r\nfrom azure.identity.aio import AzureCliCredential\r\n \r\n@tool\r\ndef line_total(unit_price_cents: int, quantity: int) -> int:\r\n \"\"\"Calculate a line total in cents.\"\"\"\r\n return unit_price_cents * quantity\r\n \r\nasync def main() -> None:\r\n async with AzureCliCredential() as credential:\r\n codeact = HyperlightCodeActProvider(\r\n tools=[line_total],\r\n approval_mode=\"never_require\",\r\n )\r\n async with Agent(\r\n client=FoundryChatClient(\r\n project_endpoint=os.environ[\"FOUNDRY_PROJECT_ENDPOINT\"],\r\n model=os.environ[\"FOUNDRY_MODEL\"],\r\n credential=credential,\r\n ),\r\n name=\"OrderCalculator\",\r\n instructions=\"Use execute_code to combine calculations when useful.\",\r\n context_providers=[codeact],\r\n ) as agent:\r\n response = await agent.run(\r\n \"Calculate the combined total for 12 items at 250 cents each \"\r\n \"and 8 items at 175 cents each.\"\r\n )\r\n print(response.text)\r\n \r\nif __name__ == \"__main__\":\r\n asyncio.run(main())\r\n<\/code><\/pre>\nHyperlightCodeActProvider supplies the execution tool and instructions. Registered tools are available to generated code through call_tool(…).<\/p>\n
The isolation boundary matters: Hyperlight isolates model-generated code; registered application tools execute in your application\u2019s runtime.<\/strong> Those tools retain their own permissions and responsibilities. This example permits automatic execution because its only tool performs arithmetic. Actions requiring individual approval should remain explicitly approval-gated.<\/p>\nThe CodeAct walkthrough<\/a> reports approximately 50% lower latency and more than 60% lower token usage in its evaluated workload. Treat those as workload-specific results and measure the tradeoff in your own application.<\/p>\nGitHub:<\/strong> Python Hyperlight package and platform prerequisites<\/a> \u00b7 .NET CodeAct samples<\/a><\/p>\nMake long-running work recoverable<\/h2>\n
A longer timeout does not make an agent resilient. Long-running work needs recoverable execution state, a way to reconnect to results, and clear behavior when a process stops.<\/p>\n
Agent Framework\u2019s integration with hosted agents in Foundry Agent Service<\/strong> connects workflow checkpoints and agent sessions to resilient background responses.<\/p>\nPython: enable resilient background execution<\/h3>\n
After constructing a workflow, configure its Responses host:<\/p>\n
from agent_framework_foundry_hosting import ResponsesHostServer\r\nfrom azure.ai.agentserver.responses import ResponsesServerOptions\r\n \r\nworkflow_agent = workflow.as_agent(name=\"report-workflow\")\r\n \r\nserver = ResponsesHostServer(\r\n workflow_agent,\r\n options=ResponsesServerOptions(resilient_background=True),\r\n)\r\n \r\nserver.run()\r\n\r\n<\/code><\/pre>\nThe complete Python sample builds a countdown workflow so recovery is easy to observe. You can submit a background request, interrupt the server, restart it, and reconnect to the response.<\/p>\n
For that sample, the request body is:<\/p>\n
{\r\n \"input\": \"Count down from 20\",\r\n \"background\": true,\r\n \"store\": true,\r\n \"stream\": true\r\n}<\/code><\/pre>\nGitHub:<\/strong> Python resilient long-running workflow<\/a><\/p>\n.NET: configure the resilient Responses host<\/h2>\n
The corresponding .NET integration uses AddFoundryResponses:<\/p>\n
using Microsoft.Agents.AI;\r\nusing Microsoft.Agents.AI.Foundry.Hosting;\r\nusing Microsoft.Agents.AI.Workflows;\r\n \r\nAIAgent agent = workflow.AsAIAgent(\r\n id: \"report-workflow\",\r\n name: \"report-workflow\",\r\n includeWorkflowOutputsInResponse: true);\r\n \r\nvar builder = WebApplication.CreateBuilder(args);\r\nbuilder.Services.AddFoundryResponses(\r\n agent,\r\n configure: options => options.ResilientBackground = true);\r\n \r\nvar app = builder.Build();\r\napp.MapFoundryResponses();\r\n \r\nawait app.RunAsync();<\/code><\/pre>\nOn recovery, the host reloads persisted state and selects the workflow checkpoint associated with the saved response. A restarted process must reconstruct matching workflow and executor identities.<\/p>\n
Recovery does not imply exactly-once execution of external effects.<\/strong> An interrupted step may run again. If a tool sends an email, charges a payment, or writes to another service, design that operation to tolerate retries\u2014for example, through downstream idempotency keys.<\/p>\nGitHub:<\/strong> .NET resilient workflow with deployment instructions<\/a> \u00b7 Local recovery and idempotency demonstration<\/a><\/p>\nFor Azure Functions<\/strong>, the Durable extension for Agent Framework<\/a> provides a separate durable-execution path. See the Azure Functions samples<\/a> for that hosting model.<\/p>\nWe\u2019re also extending the development lifecycle in VS Code<\/strong>. Foundry Toolkit support will let developers start a long-running agent, leave the interaction, and reconnect to inspect progress or results without starting the work again.<\/p>\nStart with the capability your application needs next<\/h2>\n
These capabilities are composable. You can connect an AG-UI frontend, attach memory, evaluate CodeAct, or adopt resilient workflow hosting without treating every feature as a prerequisite.<\/p>\n