mrkeyoor.com_
Tue 01 Sept 17:40 UTC
LLM Toolsevaluationupdated 25 Aug 2026

agent-framework review

Microsoft Agent Framework is a Python and .NET toolkit for building AI agents and joining them into stateful workflows. It supplies the machinery around model calls, including tools, middleware, checkpoints, streaming, human approval, tracing, and hosting patterns.

+141stars / 7d
Verdict

Our Agent Framework install pulled 233 packages and occupied 912 MB, then the full test run failed after 72 seconds, so adopting it requires a team willing to verify its exact workflow path. It is a strong candidate when Python and .NET parity, Foundry integration, checkpoints, or multi-agent graphs are firm requirements. Use a smaller provider SDK for a stateless assistant, and pin Agent Framework versions before production work.

We ran it

Lab card: what happened when we ran agent-frameworkScreenshot of agent-framework (aka.ms/agent-framework)
Install✓ · 144s233 packages · 912 MB
Build✓ · 10s
Tests✗ · 72sran, no count parsed
Known vulns0(pip-audit)
Repo5111 files~850,305 lines of source · 48.8 MB · 27 CI workflows · tests dir

Answers from our run

Does agent-framework build from source?

Dependencies installed in 144 seconds (233 packages), and the build succeeded in 10 seconds. We cloned commit a2a8635 into a clean Debian container with 3 CPUs and no project-specific setup.

Do agent-framework's tests pass?

The test command failed in our container, and its output did not report a pass or fail count.

Does agent-framework have known vulnerabilities in its dependencies?

pip-audit found none in the dependency tree at the time of our run.

Who should not use agent-framework?

Small applications that need one stateless model call: the README positions this framework for orchestration beyond a simple chat loop, while our install pulled 233 packages.

What are the alternatives to agent-framework?

LangGraph, AutoGen, Semantic Kernel. Our Agent Framework install pulled 233 packages and occupied 912 MB, then the full test run failed after 72 seconds, so adopting it requires a team willing to verify its exact workflow path.

Setup2/5Install passed, but 233 packages and a failed full test run add work
Docs5/5Clear quickstarts, samples, migrations, design records, and safety notes
Community5/5Fresh pushes, frequent releases, office hours, and active issue triage
Maturity3/5Wide production surface, with current workflow and MCP defects

Discussed on

  1. hnMicrosoft Agent Framework58 points
  2. hnMicrosoft Agent Framework9 points
  3. hnMicrosoft Embraces AG-UI Protocol for Agent UI7 points
  4. hnMicrosoft Agent Framework6 points
  5. hnThe Microsoft Agent Framework Harness is now released5 points

Who it’s for

Python or .NET teams whose agents need explicit workflow state, checkpoints, and human approval.
Microsoft Foundry or Azure OpenAI users who want first-party identity and hosting examples.
Platform engineers connecting model providers, MCP tools, A2A agents, and OpenTelemetry traces.
Developers replacing an AutoGen or Semantic Kernel system who can test the migration path before shipping.

Who it’s NOT for

Small applications that need one stateless model call: the README positions this framework for orchestration beyond a simple chat loop, while our install pulled 233 packages.
Teams that require a clean full-suite result before evaluation: our sandbox test command failed after 72 seconds, with the log tail saying async test functions were not natively supported.
Developers seeking a ready-made container handoff: our checkout had no Dockerfile, so container packaging remains their job.
Operators who cannot test workflow state after failures: open issue #7859 reports pending Python state leaking from a failed run into a later successful run.
Organizations assuming agent safety and data boundaries come configured: Microsoft's transparency FAQ assigns tool isolation, moderation, permissions, and external-service review to the application team.

Setup reality

At commit a2a8635, our Python 3.12 sandbox installed 233 packages in 144 seconds and used 912 MB. The build then passed in 10 seconds, but the test run failed after 72 seconds. Pip-audit found 0 known vulnerabilities.

A useful agent still needs a model provider, credentials, an endpoint or deployment, and provider-specific configuration. The README's first Python example uses Azure CLI authentication and Microsoft Foundry, although the framework also has adapters and samples for other providers.

The Python project sits under ./python/ inside a 5,111-file repository, and our checkout had no Dockerfile. The failing log names async golden tests and says async functions are not natively supported; it does not establish why the required async support was absent, so teams should reproduce the documented development setup before judging the suite.

Four workflow patterns make this more than a model client

Agent Framework names 4 workflow patterns across Python and .NET: sequential, concurrent, handoff, and group collaboration. Agents can call tools through native functions or MCP, talk over A2A, pause for human input, and emit OpenTelemetry traces. Its graph model also allows ordinary functions between model-driven steps. That matters in business processes where a parser or policy check should decide a transition instead of another prompt. The project is aimed at systems that need state and control after a demo has proved the idea.

The scale matches that ambition. Our checkout at commit a2a8635 contained 5,111 files and about 850,305 lines of source, with the working tree occupying 48.8 MB before dependencies. Python lives under ./python/, beside a separate .NET implementation and shared documentation. That is useful for organizations standardizing across both languages, though it also means the framework is a platform-sized dependency with parallel samples, packages, and release work. A simple support assistant may gain little from owning so much surface.

The one-line install became 912 MB on our box

Our Python 3.12 install turned the README's one pip command into 233 packages before an agent made its first provider call. The first sample uses Microsoft Foundry and requires Azure CLI authentication plus a project endpoint and model deployment, supplied through environment variables or constructor arguments. Other provider adapters broaden the choice, but none removes the need for credentials, service limits, and a decision about where conversation and tool data travel. Microsoft also recommends a specific production credential instead of relying on every fallback tried by DefaultAzureCredential.

Our clean Python 3.12 container installed those 233 packages in 144 seconds and consumed 912 MB on disk. Installation succeeded, so the published package can resolve from an empty Debian-based environment. The result is still much heavier than the README's short command suggests. Teams maintaining several services should account for image size, dependency updates, and cold build time. The checkout had no Dockerfile, which leaves the production container recipe and any system hardening to the adopter.

What happened when we ran it

In our sandbox, the build completed successfully in 10 seconds, while the test command exited with failure after 72 seconds. Pip-audit reported 0 known vulnerabilities among the installed Python packages. The run used 3 CPUs, 8 GB of RAM, Python 3.12 on Debian Bookworm, no secrets, and an unprivileged container. Those results describe commit a2a8635 in that environment. They are evidence about setup friction, not a claim about agent accuracy or model quality.

The failing log tail lists golden tests under packages/ag-ui/tests/ag_ui/golden/, including generative UI, human approval, and predictive-state scenarios. Each shown failure ends with the same message: async test functions are not natively supported. The log does not say whether a missing plugin, an invocation choice, or another configuration detail caused that condition, so assigning a cause would be guesswork. The practical finding is narrower: the repository's full test path did not pass untouched in our fresh sandbox, despite installation and build succeeding.

Checkpoints and approvals still need application tests

Open issue #7859 reports pending Python state from a failed superstep appearing in a later successful run. That path matters because checkpointing, restartability, time travel, streaming, and human approval are the reasons to choose this framework over a thin model client. A team must choose persistence, make tool calls safe to retry, decide what happens after a partial side effect, and define who may approve an action. Microsoft's transparency FAQ also recommends isolation for code execution, minimal data sharing, monitoring, and evaluation suited to the selected models.

Our 72-second test failure touched async golden scenarios around AG-UI behavior, which makes a targeted acceptance suite especially important. Current issue activity adds another concrete warning. Issue #7866 reports duplicated MCP output when a result contains both ordinary and structured content. Both #7859 and #7866 were open and marked reproduced on August 25, 2026. These reports identify two paths worth testing before launch; they do not establish that every workflow is unsafe.

Twenty-seven CI workflows show active engineering and a wide surface

The repository contained 27 CI workflow files, a tests directory, and no Dockerfile in our measured checkout. GitHub showed a last push on August 25, 2026, with issues and pull requests updated that same day. The latest repository release was .NET 1.19.0, published August 22, and its notes include fixes, hosted-agent work, and a breaking MCP task change. GitHub's combined open count was 611 issues and pull requests, so it describes a busy queue rather than 611 confirmed defects.

That pace cuts both ways for adopters. Fresh releases and active triage reduce abandonment risk, while changes across providers, workflows, hosting, MCP, and two language implementations demand version discipline. The 5,111-file checkout and separate release work are signals to pin packages, read the language-specific notes, and exercise restoration and cancellation whenever upgrading. Documentation helps: the README links progressive samples, Microsoft Learn tutorials, migration guides for AutoGen and Semantic Kernel, design records, hosting examples, and a transparency FAQ.

Choose it for stateful agents across Python and .NET

Our 233-package result gives Agent Framework a clear adoption threshold: graph workflows, human approval, tracing, or Microsoft hosting paths must justify the extra surface. Start with one bounded workflow and test denial, retry, cancellation, checkpoint restore, and provider outage against the exact pinned packages. Our run shows the cost of assuming the quick start describes the whole job: 912 MB on disk and a full test command that did not pass. For one stateless model call, a provider SDK is the cleaner choice.

Alternatives

ProjectWhat it isPick it when
LangGraph gh↗A graph runtime for stateful, long-running agents in Python and JavaScript.pick this instead when graph execution matters more than first-party .NET and Microsoft Foundry integration.
AutoGen gh↗Microsoft's framework for conversational single-agent and multi-agent applications.pick this instead when an existing AutoGen application is stable and migration would solve no current problem.
Semantic KernelA Microsoft SDK for adding model prompts, plugins, and agent features to applications.pick this instead when your application already depends on its plugin model and does not need the newer workflow runtime.
OpenAI Agents SDKA smaller Python SDK for agents, handoffs, guardrails, sessions, and tracing.pick this instead when Python is enough and you want a narrower agent layer without the Microsoft workflow and hosting surface.

What people are saying

  1. [github-trending] microsoft/agent-framework

Sources

  1. Microsoft Agent Framework README
  2. Microsoft Agent Framework .NET 1.19.0 release
  3. Responsible AI Transparency FAQ
  4. Issue #7859: pending state survives a failed superstep
  5. Issue #7866: MCP tool output duplication

More llm tools reviews

rig · open-knowledge · graphiti · cve-mcp-server · minimind · SillyTavern · the whole board →