# Microsoft previews Microsoft Agent Framework > Microsoft announced the public preview of Microsoft Agent Framework, an open-source SDK and runtime for multi-agent orchestration. The company positioned it alongside Azure AI Foundry capabilities for building, observing, and governing agent systems. The announcement described a framework that combines ideas from AutoGen and Semantic Kernel and emphasized workflow composition, agent-to-agent coordination, observability, and governance for enterprise scenarios. Canonical: https://hypler.com/ai-news/microsoft-agent-framework-preview-2025 Hypler publication: 2026-10-06 Hypler updated: 2026-10-06 Original source date: 2025-10-01 Byline: Hypler editorial team Source publisher: Microsoft Editorial standard: https://hypler.com/ai-news#editorial-standard Article kind: source-briefing Category: Developer tools Tags: Microsoft, agents, orchestration, Azure AI Foundry ## Engineering relevance Multi-agent frameworks can simplify coordination while making failure modes harder to trace. A framework announcement is a prompt to define responsibility boundaries before adding agents: who selects tools, which agent may act, how state flows, and where a human can intervene. Observability features help only when teams decide what behavior, evidence, and exceptions they need to retain. ## Source record: a framework preview for agent composition On October 1, 2025, Microsoft announced the public preview of Microsoft Agent Framework, describing an open-source SDK and runtime for agent and workflow composition. The announcement connected the framework with Azure AI Foundry observability and governance capabilities, and described multi-agent workflows in private preview. Microsoft documentation describes model clients, sessions, context providers, middleware, MCP clients, and workflows. Application teams select these components for the task, define their contracts, and evaluate the complete workflow before release. ## Hypler engineering interpretation: coordination needs an accountable owner More agents do not automatically create a better system. Each agent introduces a new decision boundary: who owns task selection, what state it can see, what it may delegate, which tools it may call, and who resolves disagreement. Start by assigning a single accountable workflow owner, even if the implementation uses several specialized components. That owner defines the shared schema, terminal states, retry rules, and the point where a human must decide rather than let coordination continue indefinitely. Specialization is useful when it creates a measurable boundary. A retrieval component can gather cited material; a planner can form a non-executable plan; a validator can check a proposed artifact against deterministic rules. Calling each step an agent can obscure this difference. Prefer the simplest component that can satisfy the contract, and make the handoff between components explicit enough to inspect later. ## Hypothetical workflow: a controlled policy review A hypothetical policy-review workflow could begin with a document intake component that validates file type and classification. A retrieval component then selects allowed passages and returns source identifiers. A drafting component produces a labeled proposal that cannot send, publish, or change a record. A deterministic checker verifies required headings, citations, and prohibited terms. Finally, a reviewer receives the proposal, the source list, and the checker result. The reviewer, not the workflow, owns approval. The useful observation is not that several components participated. It is that each one has a narrow input and output, and the workflow can stop safely after any failure. If retrieval cannot establish an allowed source, drafting should not invent a substitute. If the checker fails, the artifact should be returned as incomplete rather than silently routed around the control. ## Architecture: state, middleware, and tool policy Treat workflow state as an explicit data model rather than an accumulation of conversational text. Include a task identifier, input version, permitted sources, stage, owner, allowed transitions, and terminal reason. Persist only the state required to resume or audit the work; avoid giving every component unrestricted history by default. A retry should carry the same identity and an attempt count so that an interrupted operation cannot become multiple independent actions. Middleware is a natural place to enforce policy around model and tool calls, but it should not be the only evidence of enforcement. Tool servers should validate authorization themselves. Emit structured events for stage changes, tool requests, validation failures, and human decisions. Avoid recording sensitive prompt contents by default. The trace should make it possible to distinguish a model response, a tool result, and a workflow decision without treating any one of them as automatically authoritative. ## Failure modes: loops, lost context, and misleading traces Multi-step workflows can loop on retries, pass stale context into a later decision, or allow one component to reinterpret another component's output as an instruction. Concurrent branches can also race to update shared state. Design for cancellation, maximum attempts, stable ordering, and an explicit conflict state. A graceful stop with a useful reason is safer than an apparently complete answer assembled from inconsistent inputs. Observability can fail when traces lack a task identifier, omit the tool arguments that matter, or record only successful spans. Test a failed tool call, a timeout, an injected instruction in retrieved content, two incompatible proposed updates, and a human rejection. The expected result should show where the workflow stopped, what was preserved, and what a reviewer would need to retry safely. ## Evaluation and release checklist Define test cases for normal completion, missing evidence, invalid state transitions, duplicate delivery, tool denial, and human escalation. Evaluate the complete workflow, not only an individual model response. Inspect whether every output can be traced to allowed inputs, whether state is preserved across a restart, and whether the system avoids side effects after a failed validation. Use deterministic fixtures for tool results so regressions are attributable. A release candidate needs owners for schemas, tool policies, logs, updates, and rollback. Begin with a workflow reviewed before it reaches a system of record. Monitor stop reasons, validation failures, and completion rates. Re-run integration and fixture tests when the framework changes. Compare the updated version with the prior release, review changed dependencies, and retain the evidence that supports the upgrade decision. ## Original source - [Microsoft](https://azure.microsoft.com/en-us/blog/introducing-microsoft-agent-framework/) ## Related links - [Microsoft Azure Blog: Introducing Microsoft Agent Framework](https://azure.microsoft.com/en-us/blog/introducing-microsoft-agent-framework/) - [Microsoft Learn: Microsoft Agent Framework overview](https://learn.microsoft.com/en-us/agent-framework/overview/) - [Custom software and product engineering](https://hypler.com/custom-software-development) ## Image provenance ### Primary image ![Generated editorial illustration in cut paper: parallel work and a stopped action branch; not Microsoft software or an implementation diagram.](https://hypler.com/assets/news/agent-framework-paper-workflow.webp) generated illustration. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography. - [Image source](https://hypler.com/ai-news/media.md) ### Supporting image ![Generated editorial illustration of staged work tickets, a saved checkpoint and a retry path; not a Microsoft architecture specification.](https://hypler.com/assets/news/agent-framework-checkpoint-retry.webp) generated illustration. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography. - [Image source](https://hypler.com/ai-news/media.md) ## Reading boundary Historical source briefing with Hypler engineering analysis. Source details reflect the original publication date; implementation examples are hypothetical. Public reading grants no private access or execution authority.