Google's ADK vs. DNotifier

Part of a series on running AI workflows across model providers — this one's about a real architectural choice, not a hypothetical.

Google's Agent Development Kit has grown fast. What started as a Python toolkit now ships for Java, Go, and — as of a Kotlin release that just reached feature parity with the others — Android and Kotlin Multiplatform too, letting the same agent-building patterns run on a server or directly on a phone. It's open source, it's genuinely capable, and it's worth taking seriously on its own terms before deciding whether a model-agnostic layer makes more sense for what you're building.

What ADK actually gets right

ADK's core idea is hierarchical multi-agent orchestration — parent agents that delegate work to child agents, each scoped to a narrower job. That's a sound pattern for complex agent systems, and ADK builds real infrastructure around it: automatic context compaction and multi-turn history summarization, so long-running agent conversations don't just accumulate tokens forever unmanaged.

The tooling story is genuinely thoughtful, too. Tools get declared with compile-time annotations rather than runtime reflection, which — in the Kotlin and Java versions especially — means type errors in a tool's schema show up when you build, not when an agent tries to call it in production and fails in a way that's annoying to trace back.

Human-in-the-loop isn't an afterthought bolted on top, either. You can mark a specific tool as requiring explicit confirmation before it runs — the example that comes up in Google's own documentation is a bank transfer, which is exactly the kind of action you want a real pause-and-confirm step in front of, not just a logged warning.

And the "SKILL.md" pattern — procedural knowledge that loads dynamically only when an agent actually needs it, instead of sitting in context on every single call — is a genuinely good answer to a real cost and precision problem: context bloat from information that's relevant occasionally, not constantly.

What ADK assumes, by design

Here's the part worth being clear-eyed about: ADK is explicitly framed as model-agnostic — Google's own materials describe it as "completely agnostic to specific model backends" — but the ecosystem it's built inside, the deployment paths it's documented against, and the hosted platform it connects to most naturally all point back toward Google's own Gemini and Google Cloud infrastructure. Nothing stops you from pointing an ADK agent at a different model provider. But the deeper you go — into Google's enterprise agent platform, its Model Garden, its managed deployment tooling — the more the whole stack starts to assume Google is the destination, not just one option among several.

That's not a flaw. It's a specific bet, the same way choosing any framework tied closely to one cloud's ecosystem is a bet. It pays off cleanly if your infrastructure is already Google-centric. It's a cost worth naming if it isn't, or if you don't yet know which providers you'll want to run six months from now.

Where DNotifier sits instead

ADK: strong agent definitions, often assuming Google/Gemini infrastructure underneath
DNotifier: same Workflow/defineAgent patterns, provider chosen per agent in dashboard

ADK's agents are excellent. The question is which infrastructure they're allowed to assume underneath them.

DNotifier starts from a different premise: orchestration, realtime messaging, memory, and retrieval are a layer that shouldn't be tied to any one model vendor's ecosystem, because the model market is still moving fast enough that "we picked our provider forever" is a riskier bet than it looks today. The same defineAgent and Workflow primitives work identically whether Gemini, Claude, OpenAI, or another connected provider is answering a given call — and mixing providers within one workflow, routing different agents to whichever model fits each job best, is a normal pattern rather than a workaround.

DNotifier also isn't trying to be an on-device Android framework, and doesn't need to be — its scope is realtime communication, orchestration, and knowledge retrieval for backend and cross-platform applications, which is a different problem than ADK for Kotlin's specific "run inference directly on a phone" use case.

Side by side

A real use case where the difference shows up

Imagine a field-service company building an agent that helps technicians diagnose equipment issues on-site, sometimes with a spotty connection. If part of that experience genuinely needs to run inference locally on the technician's Android device when connectivity drops, ADK's on-device story — LiteRT-LM, ML Kit, the Kotlin Multiplatform reach — is a real, specific advantage nothing described here replicates. If the same company also wants that agent to escalate to a human dispatcher through a realtime chat channel, log the whole interaction for observability, and potentially route the escalation conversation through a different, more capable model than the on-device one — that's the kind of cross-cutting orchestration DNotifier is built for, and it's not what ADK's core agent-definition layer is trying to solve.

The honest answer for a lot of real systems: these aren't strictly either/or. A team deep in the Android/Google ecosystem might reasonably use ADK for the on-device agent layer and something like DNotifier for the backend orchestration, memory, and cross-provider routing sitting behind it.

Frequently asked questions

Is ADK actually open source?

Yes — google/adk-python and the other language variants are open source on GitHub, which is part of why it's gained traction quickly across Python, Java, Go, and now Kotlin.

Can I use ADK with non-Gemini models?

Google's own documentation describes ADK as model-backend-agnostic, so in principle yes — though the broader ecosystem it's built around (deployment tooling, the enterprise agent platform, Model Garden) is more naturally suited to Gemini and Google Cloud specifically.

Does DNotifier support on-device inference the way ADK for Kotlin does?

No — DNotifier is built for backend and cross-platform application orchestration, not on-device mobile inference. If local, offline inference on a device is a hard requirement, that's a genuine ADK strength worth using directly.

Which one has better multi-agent support?

Both support real multi-agent patterns, built differently — ADK's hierarchical parent/child delegation versus DNotifier's shared-state workflow model. Neither is strictly more capable; they reflect different assumptions about where the rest of your infrastructure lives.

Do I have to choose one exclusively?

No — nothing prevents combining them in a system where different components genuinely call for different tools, as in the field-service example above.

The Bottom Line

Next in this series: an actual hands-on build — a multimodal support agent using Gemini's native image handling, wired up through a real DNotifier workflow.

Read part one: Gemini on DNotifier: Setup Guide. Explore dnotifier.com.