The announcement came from Dan Taylor, a Principal Product Architect, on Microsoft's Agent Framework developer blog, and it reads more like a set of runnable recipes than a launch post. The recipes come with warnings about identity, retries and sandbox boundaries. Those warnings are the most useful part of the post, because each one marks a place where a demo sample will not survive production unchanged.
Microsoft Agent Framework 1.0 Laid the Groundwork These Updates Build On
For readers who haven't followed the project, Agent Framework is Microsoft's consolidation of its two earlier agent toolkits. Microsoft Learn calls it the direct successor, created by the same teams behind Semantic Kernel and AutoGen. It combines AutoGen's simple abstractions for single- and multi-agent patterns with Semantic Kernel's enterprise-grade features such as session-based state management, type safety, filters, telemetry, and extensive model and embedding support.
Several of the building blocks in the new post were already present in the 1.0 release this spring. The 1.0 announcement listed AG-UI / CopilotKit / ChatKit adapters that stream agent output to frontends, a pluggable memory architecture supporting conversational history, persistent key-value state, and vector-based retrieval, and a workflow engine where checkpointing and hydration ensure long-running processes survive interruptions. The September updates extend those foundations. The AG-UI support gets new Python features and a new .NET SDK, the memory story gains a working Foundry-managed example, and checkpointing is now wired to hosted background responses.
Language coverage is uneven. Microsoft Learn says that in the Go version of the framework, which is in public preview, declarative agents, RAG, CodeAct, and functional workflows are not yet available. Everything below applies to Python and .NET only.
All of the examples share a common setup. Developers sign in with az login, set FOUNDRY_PROJECT_ENDPOINT to their Foundry project endpoint, and set FOUNDRY_MODEL to the name of a deployed model. Python developers install agent-framework-foundry, agent-framework-ag-ui, azure-identity, aiohttp, fastapi and uvicorn with pip install --pre. The .NET walkthrough starts from a new Blazor project and adds Azure.Identity plus prerelease builds of Azure.AI.Projects, Microsoft.Agents.AI.Foundry and Microsoft.Agents.AI.Hosting.AGUI.AspNetCore.
AG-UI Streams Agent Activity to Python and .NET Frontends, at Different Maturity Levels
AG-UI is an open, event-based protocol for the conversation between an agent backend and a user interface. CopilotKit, whose frontend framework is one of the protocol's main consumers, describes it as the general-purpose, bi-directional connection between a user-facing application and any agentic backend. Microsoft's pitch is that a useful agent interface shows more than the final answer. Users should be able to watch progress, see which tools are being called, approve actions and work with the results. Agent Framework translates an agent's execution into AG-UI events for streaming text, tool activity and other supported interactions.
On Python, the pattern is short. Build an Agent backed by a FoundryChatClient using the Foundry endpoint, model name and an AzureCliCredential, manage the credential and agent inside a FastAPI lifespan handler, and register the agent at a route with add_agent_framework_fastapi_endpoint(app, agent, "/ag-ui"). Running uvicorn app:app --reload serves it. Microsoft labels this path a stable release. Recent Python work also adds workflow checkpointing and resumption, better approval continuity, shared and predictive state updates, and optional A2UI integration for interfaces generated by the agent.
The .NET version does the same job in ASP.NET Core. Call builder.Services.AddAGUIServer(), create an AIProjectClient with the endpoint and an AzureCliCredential, turn it into an AIAgent with .AsAIAgent(...), and expose it with app.MapAGUIServer("/ag-ui", agent). Under the hood it now uses a new AG-UI .NET SDK, which provides abstractions for the AG-UI events plus client and server support built on Microsoft.Extensions.AI. Frontend options include CopilotKit and Microsoft's new Blazor AI components for building agent interfaces in .NET.
Microsoft says plainly that the .NET hosting integration remains in preview and that the two languages don't have identical capabilities. It tells developers to follow the language-specific samples instead of assuming parity. In practice, the Python checkpointing and predictive-state features shouldn't be assumed to exist in .NET until the .NET samples show them.
The security warning attached to these samples applies to every AG-UI deployment. The minimal endpoints do no authentication. Before deployment, developers need to authenticate callers and authorize their access to sessions. As Microsoft puts it, a thread ID-style identifier tells the server which conversation a request belongs to, but it doesn't establish who is allowed to read or continue that conversation. An AG-UI endpoint that accepts any thread ID from any caller exposes other users' conversations.
Agent and Workflow Channels Reuse One Agent Across Responses, Telegram, A2A and MCP
AG-UI covers rich web frontends. The new Python agent and workflow channels packages tackle a separate problem: serving the same agent logic over several protocols at once. The packages include helpers for four surfaces, each with a different audience:
- The OpenAI Responses helper serves API clients that already speak that request format.
- The Telegram helper puts the agent in front of messaging users.
- The A2A helper lets the agent communicate with other agents.
- The MCP helper exposes the agent's capabilities as tools other systems can call.
Shared session helpers keep the code the agent sees small. Microsoft's example wraps an agent in an AgentState object from agent_framework_hosting. It then calls get_or_create_session with a session ID, runs the agent against that session, and saves the session back with set_session.
The example uses a hard-coded "demo-session" ID, and Microsoft says outright that this is for local demonstration and not a production identity strategy. The application owns the mapping between a channel identity, such as a Telegram user, and an authorized session, along with storage and concurrency policy. The framework handles protocol translation. Routing, authentication and persistence stay with the developer.
FoundryMemoryProvider Brings Back What Matters Without Replaying Old Conversations
Microsoft draws a clear line between conversation history and memory. History keeps a record of what was said. Memory brings the useful parts into a new conversation without replaying the whole transcript. Memory in Foundry Agent Service connects to Agent Framework through FoundryMemoryProvider, which is a context provider: a component that runs around each agent call. Before a run, it retrieves relevant memories. After a run, it submits the conversation for asynchronous memory extraction.
The prerequisite is heavier than the other examples. FOUNDRY_MEMORY_STORE_NAME has to point to an existing Foundry memory store configured with supported chat and embedding model deployments. The Python sample opens an AIProjectClient with allow_preview=True and creates the memory provider with a scope of "demo-user" and update_delay=0. It attaches that provider next to an InMemoryHistoryProvider(load_messages=False) and sets default_options={"store": False}. The last two settings turn off local transcript loading and service-side response storage. That makes the demo a real test: any recall has to come from the memory store, not from a replayed conversation.
The demo runs as two separate processes. The first run records a preference, in Microsoft's example a request for project updates as a short summary followed by action items. The second run starts a fresh session with the same scope and asks how the next project update should be formatted. The timing is where people will get caught out. Extraction is asynchronous, and update_delay=0 only removes the batching delay before processing starts. It does not guarantee immediate recall. If the second process runs before extraction has finished, the agent won't know the preference yet. A developer who concludes the feature is broken may simply have asked too soon.
For production, Microsoft's guidance comes down to four practices:
- Derive the memory scope from the authenticated application identity, never from an identifier the user supplies.
- Replace the Azure CLI credential with a credential suited to production.
- Apply your application's retention and deletion policies to stored memories.
- Evaluate recall quality against your own workload.
Foundry isn't the only backend. Azure Cosmos DB remains an alternative through CosmosMemoryContextProvider, which Microsoft introduced on September 4 in the Python-only preview package agent-framework-azure-cosmos-memory. That provider stores conversation turns, extracts facts, summaries and user profiles in the background, and supports vector, full-text and hybrid retrieval. Microsoft warns that the package and its APIs may change before general availability. Its scoping behaves differently from the Foundry provider: without a stable user ID, it falls back to memory scoped to the session instead of carrying knowledge across sessions. Its sample calls memory.flush() to wait for background extraction so the demo gives the same result every time. Because the two providers need different setup and are at different maturity levels, choosing between them is a real decision, not a matter of configuration.
CodeAct and Hyperlight Collapse Tool-Call Loops, but Only Generated Code Is Sandboxed
The CodeAct feature addresses a cost problem in tool-heavy agents. When a task involves many small, chainable operations, having the model pick a tool, read the result and pick the next tool at every step adds latency and burns tokens. With CodeAct, the model writes a suitable sequence as a short program, runs it, and gets back one consolidated result.
The Python integration installs separately with pip install --pre agent-framework-hyperlight, and it requires a supported platform. Microsoft points to the package's own platform prerequisites and doesn't list them in the post. The sample registers a single @tool function, line_total, which multiplies a unit price in cents by a quantity. That tool goes to a HyperlightCodeActProvider with approval_mode="never_require", and the provider is attached to the agent as a context provider. The provider supplies an execute_code tool and matching instructions. Inside generated code, registered tools are reached through call_tool(...). The sample prompt asks for the combined total of 12 items at 250 cents and 8 items at 175 cents. By our own arithmetic, that is 3,000 plus 1,400, or 4,400 cents.
Hyperlight isolates the model-generated code, but it doesn't isolate your tools. Registered application tools run in your application's own runtime, with their own permissions and responsibilities. A sandboxed script that calls a tool able to delete records can still delete records. Microsoft turned off approvals in the sample only because its one tool does arithmetic, and it advises that actions needing individual approval should stay explicitly approval-gated.
On performance, Microsoft cites its earlier CodeAct walkthrough, which reported roughly 50% lower latency and more than 60% lower token usage on the workload it evaluated. These are Microsoft's own measurements on its chosen workload. Microsoft itself says to treat them as workload-specific and to measure the trade-off in your own application. .NET CodeAct samples exist as well, but the post walks through only the Python version.
Resilient Background Responses Recover Workflows but Can Repeat Side Effects
Microsoft opens this section with a line many teams will recognize: a longer timeout doesn't make an agent resilient. Long-running work needs execution state that can be recovered, a way to reconnect to results, and defined behavior when a process stops. The new integration with hosted agents in Foundry Agent Service ties workflow checkpoints and agent sessions to background responses that survive a restart.
On Python, you convert a workflow into an agent with workflow.as_agent(name="report-workflow"), pass it to ResponsesHostServer from agent_framework_foundry_hosting with ResponsesServerOptions(resilient_background=True), and call server.run(). Microsoft's full sample builds a countdown workflow so recovery is easy to see. The client sends a request with the input "Count down from 20" and background, store and stream all set to true. You then kill the server, restart it, and reconnect to the same response.
On .NET, workflow.AsAIAgent(...) takes an ID and name of report-workflow and sets includeWorkflowOutputsInResponse: true. builder.Services.AddFoundryResponses(...) then sets options.ResilientBackground = true, and app.MapFoundryResponses() exposes the endpoint.
At recovery time, the host reloads persisted state and picks the workflow checkpoint linked to the saved response. That puts a constraint on deployments: a restarted process must rebuild matching workflow and executor identities. If a deployment renames a workflow or executor while a job is in flight, the host has no matching checkpoint to resume.
The more important limit is the one Microsoft states directly: recovery doesn't mean external effects happen exactly once. A step that was interrupted may run again. If that step sends an email, charges a card or writes to another service, it has to tolerate retries, for example by passing idempotency keys to the downstream service so it can recognize a duplicate. Microsoft ships a local demo of recovery and idempotency alongside the .NET deployment sample.
Teams on Azure Functions have a separate option. The Durable extension for Agent Framework provides its own durable-execution path. When it arrived in public preview last November, Microsoft described it as bringing the proven durable execution (survives crashes and restarts) and distributed execution (runs across multiple instances) capabilities of Azure Durable Functions directly into the Microsoft Agent Framework. Choosing between the two comes down to hosting model, Foundry hosted agents versus Functions, not to which one is more resilient.
On the tooling side, Microsoft says Foundry Toolkit support in VS Code will let developers start a long-running agent, walk away, and reconnect later to check progress or results without restarting the work. That is a stated plan, not a shipped feature.
What this means for you
Adopt these features one at a time, starting with whichever gap is hurting your current agent. Microsoft says the capabilities are composable, so AG-UI, memory, CodeAct and resilient hosting don't depend on each other. The version and release status of each piece should drive the decision. Python AG-UI hosting is the only component the post labels stable. The .NET AG-UI hosting is preview, Foundry memory runs through a preview-enabled client, Cosmos DB memory is a Python-only preview, and the packages install with --pre or --prerelease flags. Teams with strict change control can prototype now and hold production commitments until individual packages leave preview.
- Put authentication and session authorization in front of any AG-UI or channels endpoint before exposing it. A thread or session ID identifies a conversation but gives no access control.
- Derive memory scopes and channel session IDs from authenticated identity, and write retention and deletion rules for Foundry or Cosmos DB memory before storing real user data.
- Test memory with a wait between the write and the read, because Foundry extraction is asynchronous even with
update_delay=0. - Review every tool registered with
HyperlightCodeActProvideras if it will be called by untrusted code. Hyperlight sandboxes the generated script, not the tools, so keep consequential tools behind approval. - Make every externally visible workflow step idempotent before turning on
resilient_backgroundorResilientBackground, and keep workflow and executor identities stable across deployments. - Benchmark CodeAct on your own tasks before budgeting around Microsoft's reported 50% latency and 60% token savings.
The main thing this release does is make Agent Framework's weak spots explicit. Microsoft's samples show how to stream agent activity to a UI, recall a user's preference in a new session, sandbox generated code and resume a crashed workflow. Each one also names what the developer still has to supply: identity, retention policy, tool permissions and retry-safe side effects. For teams already on Foundry, the Python AG-UI and resilient-hosting samples are ready to try today. The next practical milestone is the .NET AG-UI hosting and the memory providers leaving preview, which would give .NET teams the same production footing Python developers have now.