Why We Migrated from Google ADK to Microsoft MARA

The philosophy, trade-offs, and what we learned converting 18+ agents in 3 months.

Part 1 of 8 ADK to MAF Migration

The Story

In early 2025, our multi-agent platform (Genie: a financial advisor, Bodh: a medical AI) lived on Google’s Application Development Kit (ADK). It worked. The agents were fast, the orchestration patterns were clear, and Gemini was powerful.

But we hit a fork in the road:

  1. ADK’s vision: Tightly coupled to Google Cloud. Vertex AI, Gemini models, Google’s tool ecosystem.
  2. Our vision: Platform-agnostic multi-agent systems. Swap LLM providers (OpenAI, Azure, local Ollama). Run on any cloud (GCP, Azure, on-prem). Keep agent logic pure; LLM choice should be a config knob.

So we chose Microsoft’s Agent Framework (MAF) — the reference architecture, not the vendor lock-in.

What Changed (The Mapping)

Agents: Minimal friction

Orchestration: New builders

Tools: Decorator pattern

Memory & State

Why It Matters

Provider portability: On day 90, we swapped PROVIDER=openai (cost reason) without touching agent code. Try that with ADK.

Clarity: MAF separates concerns. An agent is logic. A builder is orchestration. A client is provider. Test each independently.

Open source credibility: MAF isn’t a Google project. It’s Microsoft’s reference architecture. We can talk about it, teach it, share examples without vendor politics.

The Cost

The Thesis

If your agents are truly portable (they should be), your orchestration is declarative (it should be), and your tools are pure functions (they should be), then the LLM framework is plumbing. Pick the one that lets you swap plumbing without rewriting your house.

That’s why we chose MAF.


Next: The Executor Pattern

Sources & References

Official MAF patterns and best practices
ADK orchestration patterns and limitations
Design pattern for portable agent implementations