I have not test-driven adk-go.
But if you - like me - have not toyed around with agents until now, there is a readable, nice example in [1] which explains itself.
A reminder that, while this is pretty neat and also probably offers a lot of convenient tooling for GCloud resources already built, an "agent" is simply an LLM call in a loop, each call presenting some number of available tools. If you're building your first agent, I'd recommend coding to an LLM API (probably the OpenAI Responses API, which is sort of a lingua franca of LLMs now) directly.
This is one of those cases where it's really helpful to code, at least once, at one layer of abstraction below the one that seems most natural to you.
Having tried a few of these agent frameworks now, ADK-Python has easily been my favorite.
- It’s conceptually simple. An agent is just an object, you assign it tools that are just functions, and agents can call other agents.
- It’s "batteries included". You get a built-in code execution environment for doing math, session management, and web-server mode for debugging with a front-end.
- Optional callbacks provide clean hooks into the magic (for example, anonymizing or de-anonymizing data before and after LLM calls).
- It integrates with any model, supports MCP servers, and easy enough to hack in your existing session management system.
I'm working on a course in agent development and it's the framework I plan to teach with.
I would absolutely take this for a spin if I didn't hate Go so much :)
Python is way more ergonomic when dealing with text than go. Go's performance advantages are basically irrelevant in an AI agent, as execution time is dominated by inference time.
> Go's performance advantages are basically irrelevant in an AI agent, as execution time is dominated by inference time
Inference time is only the bottleneck if you are running a single agent loop, for a single consumer, with a single inference call being made at a time.
If you are serving a bunch of users, handling a bunch of requests, not all of which result in inference calls, some of which may result in multiple inference calls being made in parallel in independent contexts, you start to understand that concurrency matters a lot.
Might as well start with a language that helps you handle that concurrency instead of a language that treats it (asyncio) as a bastard edge case undeserving of first-class support.
8 comments
[ 3.4 ms ] story [ 29.6 ms ] thread[1] https://github.com/google/adk-go/tree/main/examples/web
This is one of those cases where it's really helpful to code, at least once, at one layer of abstraction below the one that seems most natural to you.
Gonna point Claude at our repo and see if I can do an easy conversion, makes the amount of reviews I have to do a bit more bearable.
- It’s conceptually simple. An agent is just an object, you assign it tools that are just functions, and agents can call other agents.
- It’s "batteries included". You get a built-in code execution environment for doing math, session management, and web-server mode for debugging with a front-end.
- Optional callbacks provide clean hooks into the magic (for example, anonymizing or de-anonymizing data before and after LLM calls).
- It integrates with any model, supports MCP servers, and easy enough to hack in your existing session management system.
I'm working on a course in agent development and it's the framework I plan to teach with.
I would absolutely take this for a spin if I didn't hate Go so much :)
Python is way more ergonomic when dealing with text than go. Go's performance advantages are basically irrelevant in an AI agent, as execution time is dominated by inference time.
Inference time is only the bottleneck if you are running a single agent loop, for a single consumer, with a single inference call being made at a time.
If you are serving a bunch of users, handling a bunch of requests, not all of which result in inference calls, some of which may result in multiple inference calls being made in parallel in independent contexts, you start to understand that concurrency matters a lot.
Might as well start with a language that helps you handle that concurrency instead of a language that treats it (asyncio) as a bastard edge case undeserving of first-class support.