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.

