adk-python vs agent-framework: a Google agent stack in Python against a Microsoft one across two languages

Two vendor-anchored frameworks, two centres of gravity

adk-python calls itself an open-source, code-first Python toolkit for building, evaluating and deploying agents. Its structure is two classes: Agent, which holds an AI's instructions, tools and behaviour, and Workflow, which orchestrates agents and tasks in a graph-based flow. The emphasis in its own documentation is deterministic orchestration rather than prompt chaining.

agent-framework calls itself an open, multi-language framework for production-grade agents and multi-agent workflows in .NET and Python, with a consistent foundation across Python, .NET and Go. Its own README stresses durability: restartability, observability, governance and human-in-the-loop control.

The centres of gravity differ more than the feature lists suggest. adk-python's deployment story runs through Google Cloud, and its model story starts at Gemini while staying model-agnostic. agent-framework's deployment story runs through Microsoft Foundry, and its provider story spans Microsoft Foundry, Azure OpenAI, OpenAI and the GitHub Copilot SDK. So the real question is which cloud you have already committed to, and which languages your organisation actually maintains.

What the graph engine actually gives you

adk-python's Workflow Runtime is a graph-based execution engine with routing, fan-out and fan-in, loops, retry, state management, dynamic nodes, human-in-the-loop and nested workflows. On top of it the Task API adds structured agent-to-agent delegation: multi-turn task mode, single-turn controlled output and mixed delegation patterns, with task agents usable as workflow nodes.

agent-framework's graph layer is organised around patterns rather than primitives: sequential, concurrent, handoff and group collaboration, with checkpointing, streaming, human-in-the-loop and time-travel listed alongside them. A middleware system sits on top for request and response processing, exception handling and custom pipelines.

Here the two are close enough that the deciding factor is the shape of your workload. If you need a fan-out where ten agents look at one input and a fan-in that joins their answers, adk-python names that directly. If you need to stop a long workflow and resume from a checkpoint, agent-framework names that directly. Both offer a way to pause for a person: adk-python calls it a tool confirmation flow that guards tool execution with explicit confirmation and custom input, while agent-framework lists human-in-the-loop among the workflow features.

Language reach and the cost of two release lines

adk-python's repository is Python, and Python 3.10 or newer is the requirement. The README points at adk-java, adk-kotlin, adk-go and adk-js for the other languages, which means each language carries its own release line and its own compatibility story.

agent-framework keeps the Python and the .NET implementations in one repository, under python/ and dotnet/, described as full framework support for both with consistent APIs. The .NET install is a set of NuGet packages: Microsoft.Agents.AI for the core, Microsoft.Agents.AI.Foundry for the Foundry integration and Azure.AI.Projects beside it. The Go SDK lives in its own repository, microsoft/agent-framework-go, with its own documentation and samples.

The practical difference shows up when a team is not pure Python. With adk-python, a .NET service that needs an agent has to call the Python service or wait for a separate SDK to catch up. With agent-framework, the same graph is available on both sides of a polyglot boundary, at the cost of two release lines, since the Python and .NET packages are versioned separately and a feature arriving in one does not arrive in the other on the same day.

Where the agents run

adk-python's deployment story is containerization plus a Google Cloud target: agents can be containerized and deployed on Cloud Run, or scaled on Vertex AI Agent Engine. Our analysis of adk-python tells you to verify that your chosen model and your deployment target are supported before committing.

agent-framework's hosting story is Microsoft Foundry, and the claim is unusually concrete: Foundry Hosted Agents deploy your agents to Foundry-hosted infrastructure with just two additional lines of code. Our analysis of agent-framework flags the caveat, which is that the README does not document what those two lines assume about your Foundry setup. That is the sentence to read twice, because a hosting path that assumes an existing project, identity, model deployments and networking is not two lines for a team that has none of it.

Above local development, where both frameworks let you run an agent from a local Python process, adk-python hands you a container and a managed scale-out path, while agent-framework hands you a managed agent runtime plus samples under python/samples/04-hosting/foundry-hosted-agents/ showing what the hosting call looks like.

Release rhythms and the upgrade cliff

adk-python releases roughly every two weeks, and the current line is 2.x: v2.8.0 was published on 2026-08-26, v2.7.1 on 2026-08-17, and a v1.39.1 on 2026-08-27. The 2.0 release carries breaking changes to the agent API, the event model and the session schema, and the README spells out the compatibility rule: sessions generated by ADK 2.0 are readable by ADK 1.28 and later, but are incompatible with older 1.x versions. If you have sessions stored from a 1.x deployment, that is a migration with a deadline rather than a routine upgrade.

agent-framework versions its packages by language, and here that is a feature rather than a problem. python-1.17.0 landed on 2026-09-03 and python-1.18.0 on 2026-09-10, while the .NET line moved on its own with dotnet-1.20.0 on 2026-08-31. Because the lines are numbered independently, a .NET team is not forced onto the cadence of the Python one.

Both projects pushed to their repositories on 2026-10-21. The thing to compare is not activity but the shape of change: one project has a major boundary that breaks stored sessions, and the other has parallel release lines that break the assumption that Python and .NET features arrive together.

Where each one falls short

adk-python's weakness is its code-first commitment, and it is explicit. Our analysis of adk-python says not to adopt it if you need stable 1.x session compatibility, or if you want a no-code visual designer, since the Agent Config feature exists but code is the primary path. The session schema change is the other sharp edge: because sessions written by 2.0 cannot be read by older 1.x releases, rolling back to a 1.x binary after a 2.0 deployment is not a simple revert. Its deployment options also anchor on Google Cloud, so a team committed elsewhere inherits the work of packaging and running the container itself.

agent-framework's weakness is that its most valuable pieces sit behind a Microsoft dependency, and that its breadth is a documentation burden. The providers you can rely on are the ones with samples under python/samples/02-agents/providers/, so an unsupported provider means writing that integration yourself, and Foundry hosting assumes a Foundry environment you already have. A framework that offers middleware, checkpointing, time-travel, a DevUI, declarative YAML agents, agent skills and an experimental labs package is also a larger surface to learn than a short quickstart.

Apache-2.0 against MIT, and the choice by scenario

The licences differ but neither is restrictive. adk-python is Apache-2.0 and agent-framework is MIT, so both allow commercial use, modification and redistribution with no copyleft obligation. Apache-2.0 adds an express patent grant and a patent-retaliation clause, which is occasionally what a legal reviewer asks about, and MIT carries no such clause.

Everything else comes down to which organisation you are already building on. A Python team on Google Cloud, with Gemini as the default model and Cloud Run or Vertex AI Agent Engine as the target, gets the shortest path with adk-python, and the Task API and Workflow Runtime give it the deterministic multi-agent orchestration the framework is built around. Its constraints are real but narrow: plan the 1.x session migration and accept that code is the primary authoring path.

A team with .NET services, or one that wants checkpointing, time-travel and OpenTelemetry wired in from the start, belongs with agent-framework. Verify two things before you commit, in this order: that your provider appears under python/samples/02-agents/providers/, and that the Foundry hosting sample runs against your own subscription.

Bottom line

Choose adk-python for a Python team deploying to Google Cloud and willing to plan the 2.0 session migration, and agent-framework when .NET parity or built-in durability is the deciding factor. Verify your model, your deployment target and your provider appear in the framework's own sample directories before writing the first workflow.

Sources

1. google/adk-python repository
2. google/adk-python README
3. microsoft/agent-framework repository
4. microsoft/agent-framework README