Design Philosophy, roadmap and feature parity with ask-python

[SayakMukhopadhyay]

I am moving on from another framework and looking to adopt adk-go going forward. I realise this project is still in its nascent stage compared to adk-python, but I wanted to know what the team's philosophy is regarding feature parity with adk-python. I have read that there's a thought process of making adk-go less magical (which is pretty much the go philosophy), so is there a decision not to bring over some of the adk-python niceties, like a planner or automatic wrapping of a function into a FunctionTool?

I know we can use a Planner Agent instead of the in-built planner, and with all these thoughts, I was essentially looking for information on the direction of adk-go, whether the aim is for feature parity with adk-python or not.

[verdverm]

I have a few comments around the repo now about...

building blocks over batteries included

For example, I can already create a Planner agent or process through

1. The model itself, these things are getting better because they are being RLHF'd for it
2. Prompt / context engineering & management
3. The primitives ADK already gives me (agent-as-tool, workflow-agents, state)

Another I'm skeptical about is Memory, as a primary aspect of the SDK/API surtface. The interesting part of Memory is the creation details, indexing, and search results we use in context engineering.

1. Memory, as seen as a search, seems a better fit for a tool, just like google search and every other external information source. The models have no special training concepts for this (that I'm aware of) like they do for planning
2. Memory, as seen as an external source of context, may be populated from outside as well or just be one source of what a broader "context gathering" tool or subagent might draw on
3. Conceptually, there would seem to be only two triggers for Memory creation, manual or automatic. Manual is a user interface driven event, automatic can be done in the background. Neither seem intertwined with the event/commit flow for a session.
4. From what I can tell, it may not even be used anywhere

What I'm looking for in an agentic framework, ADK is pretty close to. I think of Kubernetes, great abstractions, does all the management work, easy to plug into and weave complex systems together.

As we all share more use cases and experiences, we can hone and polish the API. I'm very curious the philosophy of the maintainers around feature parity. I'm personally OK with deviation, I already maintain a fork with patches and extensions, probably will for quite a while as I build on and contribute back.

Thanks @SayakMukhopadhyay for kicking off this discussion, and glad to meet you, I'm new around here as well

[dpasiukevich]

adk-go less magical

This is the main goal. The public API should be simple and straightforward to use.

Regarding a feature parity with adk-python we're aiming to have it. But also doing it carefully and bringing the features selectively. Planner is a good example -- it's in adk-python. But do we have to implement it in adk-go? I guess not or with a lower priority only if there's a reasonable request for it, because gemini 2.5-flash/pro both already have thinking builtin.

Regarding services implementation (session/artifact service) the implementations should have a proper parity across ADKs. So that for example adk-python agent can share session service with another adk-go agent without breaking.

[verdverm]

Would A2A be the primary means by which agents implemented in different languages/SDKs (even beyond ADK) should communicate?

The sessions sharing would be great, but maybe sounds more like protocol material than SDK material?

[dpasiukevich]

Would A2A be the primary means by which agents implemented in different languages/SDKs (even beyond ADK) should communicate?

100% correct! A2A is the protocol for that.

The sessions sharing would be great, but maybe sounds more like protocol material than SDK material?

Definitely. I've used sessions sharing as example where we must have 100% parity. While SDK feature-wise, while we'd aim for a feature parity but do so mindfully. Generally speaking: if a new functionality in adk-python superseded some other already existing one, there's no need for adk-go to add an old one.

[getoutofhere9971-pixel]

This is the owner go ahead and do what you think is best have parity to ask and kubernetes do management if that's best

[getoutofhere9971-pixel]

Parity to adk