Clarifying the roadmap and support commitment for adk-js relative to adk-python / adk-go

[tSte]

I'd like to ask about the current status of this repository and Google's longer-term plans for it, because the signals coming out of the three official ADK repos are noticeably inconsistent and it's making it hard to commit to adk-js for production work.

To make the question concrete, here is what I am seeing across the three repos as of May 25, 2026

Release cadence over the last ~10 weeks (mid-March -> May 25, 2026)

• adk-python: 10 releases, including a v2.0.0 GA on May 19 and a v2.1.0 four days later
• adk-go: 4 releases, monthly-ish cadence, currently at v1.3.0 (May 19)
• adk-js: 4 releases, last one v1.1.0 on April 28 -- nothing in ~4 weeks

Lifetime commit volume

• adk-python: ~2,700 commits
• adk-go: ~430 commits
• adk-js: ~330 commits

README / status framing

• adk-python: shipped a v2.0 GA introducing a graph-based execution engine
• adk-go: no preview disclaimers; behaves as a supported product (?)
• adk-js: still carries the "Pre-GA Offerings Terms" clause and a "Coming soon..." note for evaluation features

The pattern is hard to read. Python is obviously the flagship. Go appears to be tracked as a supported product with a stable cadence. adk-js seems to sit noticeably below both.

My questions:

1. Does Google plan to bring adk-js to full feature parity with adk-python (and at least adk-go), with a comparable release cadence and support guarantees? Or is the long-term expectation that adk-js will trail behind by design?
2. Is this repository best understood as a fully supported product, a "let's see if we can grow a JS/TS community" experiment, or something in between? A direct answer here would help teams budget risk correctly.
3. For a team building a production agent system today on Node/TypeScript, what is the official recommendation - adopt adk-js as-is, wait for a specific milestone, or use adk-python / adk-go behind a service boundary until adk-js reaches a stated bar? Or rather use Vercel?
4. Is there a published roadmap, an internal staffing commitment that can be shared, or a target date at which the Pre-GA language is expected to be removed from the README?

I am not asking this to criticise the work that has been done (it's genuinely useful and I'd like to use it even more) I just need to make an architecture decision and the current signals make it hard to justify standardising on adk-js without an explicit answer from the maintainers.

Thanks.

[Varun-S10]

Hi @tSte, Thank you for your feedback. We appreciate you taking the time to share your thoughts with us. We are escalating this issue to team.

Hi @kalenkevich, I would like to escalate this issue. could you please review the user's concerns?

[ScottMansfield]

1. Does Google plan to bring adk-js to full feature parity with adk-python (and at least adk-go), with a comparable release cadence and support guarantees? Or is the long-term expectation that adk-js will trail behind by design?

Yes, this is absolutely the intent. All ADK languages will be brought to parity and stay in parity within a small time window. This is an ongoing effort and will take some time to get there but once we do it should stay in line.

2. Is this repository best understood as a fully supported product, a "let's see if we can grow a JS/TS community" experiment, or something in between? A direct answer here would help teams budget risk correctly.

ADK TS is not experimental and is a fully supported product. The simple fact is that Google itself does not use TS as much as the other languages but we know the outside world is actually the opposite, with TS taking top spot in GitHub’s languages survey.

3. For a team building a production agent system today on Node/TypeScript, what is the official recommendation - adopt adk-js as-is, wait for a specific milestone, or use adk-python / adk-go behind a service boundary until adk-js reaches a stated bar? Or rather use Vercel?

We recommend using ADK TS unless it is lacking something you need. Even if it is, please bring it to our attention and we can prioritize implementing missing features based on that feedback. It’s really critical and does affect the order of operations on our side.

4. Is there a published roadmap, an internal staffing commitment that can be shared, or a target date at which the Pre-GA language is expected to be removed from the README?

The Pre-GA language was intended to be removed from the README at 1.0.0 release. We have published a new README in #379 that addresses this.

[tSte]

@ScottMansfield thanks for response.

1. Does Google plan to bring adk-js to full feature parity with adk-python (and at least adk-go), with a comparable release cadence and support guarantees? Or is the long-term expectation that adk-js will trail behind by design?

Yes, this is absolutely the intent. All ADK languages will be brought to parity and stay in parity within a small time window. This is an ongoing effort and will take some time to get there but once we do it should stay in line.

Great to hear! Any timeline (even rough estimates) would be great, so we can make decisions. I know that this is not a weekend hobby project, but any boards / commitments / plans you can share for this project would be much appreciated. For example, when do you intent to shift focus to other languages or have ~N% feature parity with other Python?

3. For a team building a production agent system today on Node/TypeScript, what is the official recommendation - adopt adk-js as-is, wait for a specific milestone, or use adk-python / adk-go behind a service boundary until adk-js reaches a stated bar? Or rather use Vercel?

We recommend using ADK TS unless it is lacking something you need. Even if it is, please bring it to our attention and we can prioritize implementing missing features based on that feedback. It’s really critical and does affect the order of operations on our side.

I think there are. For example #239 (reported ~7 weeks ago, went silent). We are using my fork #325 - I don't really mind that and I realize it's a large PR, but at least feedback that Google aims to go this way (and not do something completely different that would force us to re-write logic) would help.

TY.