Adk-Go: Code-First Go Toolkit for Building, Evaluating, and Deploying AI Agents

In also interested in n8n. From what I gathered it’s a everything baked in app, not a lib. Meaning that unless you re doing upstream contributions you don’t actually code anything. Just manage big configs. How are you planning to use this toolkit with it?

I was surprised a native typescript style agent wasn't a core initial offering.

Remind me the another recent post: You should write an agent https://news.ycombinator.com/item?id=45840088

Agree. I've first used the Responses endpoint, and besides context like questions - it made me realize I did not want to build or self host in a lot of the gaps AI agents really needed. Eg: context, security, controls, external data source connection management, interaction mapping, etc.

Maybe also consider pocketflow, it's even more simple and verbose.

Go is pretty fantastic to write agents in; it has a very good and expansive standard library and a huge mess of third-party libraries. A lot of very basic things agents tend to want to do (make HTTP requests, manage SQLite databases) are very idiomatic in Go already. It's easy to express concurrency in Go, which is nice if you're running multiple context windows and don't want to serialize your whole agent on slow model calls. It's very fast and it compiles to binaries, which, depending on how you're deploying your agent, might be a big win or might not be.

Why not Go ? AI agents are not just scripts, they are the same as any other application that needs to scale. Java or Go, if application can perform better then it is always good to have an option.

Because Go has stronger compile-time type safety than Python. And of course concurrency.

Fwiiw I noticed that colleagues using other languages like Java and JS with Claude Code sometimes get compile errors. I never get compile errors (anymore) with Go. The language is ideal for LLMs. Cant tell how CC is doing lately for Python.

> 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.

100%, I don’t really get the justification for golang, today. But. Looking forward we can imagine a world of agents, agents everywhere , including embedded into systems that are built in go. So I guess it would be more suitable for that.

Concurrency. Unless you’re happy stopping the world on llm io… Go excels at handling network calls and the like. It’s basically what agents are.

There are Python bindings for the framework as well.

Personally I could see Go being quite nice to use if you want to deploy something as eg a compiled serverless function.

I'm assuming the framework behaves the same way regardless of language so you could test using Python first if you want and then move over to eg Go if needed.

This is a golang variant of the already released “agent development kit” in Java and python.

And… none of them are Gemini specific. You can use them with any model you like, including Gemini.

I’m not an expert but comparing it to langgraph, it’s more opinionated , less flexible. But, easier to get started for basic agent apps.

Worth a spin.

fwiw it says it is gemini optimized on readme. Unsure to what extent