Hey!

We tried to create an ADK agent that will act as a chatbot, that will use SQL tools to basically answer to human based on informations it will find in BigQuery.

We deploy in GKE but we use the session and memory features from VertexAI Agent Engine.

It works fine on our tests and when we try it “by hand”. But when it comes to load tests, everything breaks.

We set a memory limit to 1Gi by pod, but we noticed that at startup the pod use 500Mi, then we consume ~14Mb (RSS) per call to /run_sse (they will never be recovered. (We are talking about “Hello” prompts we don’t have a full context there).

It completely breaks the feature since it will never scale. Yes we can deploy it in Cloud Run or Agent Engine but we will have a cost issue after some time (We don’t want to pay big instances for a service that basically just do some HTTP calls, the agent is not the pod that does the SQL query, we use an MCP for that).

I guess we’re doing something wrong but I have no clue what exactly. We can use some workaround with Kube’s probes to make it restart when the memory pressure is too high but we’d like to address the root issue.

Hey folks, sharing an update that may be relevant if you’re investing a lot of effort in the UI layer. I'm a Developer Advocate at CopilotKit and I'm pretty excited about the ADK integration and I'd love to get your feedback.

If you don't know, CopilotKit is the open source infrastructure for building a "Cursor for X" experience.

For ADK builders, we released a brand new version (v1.50) that is heavily focused on making it easier to connect agent runtimes to a real, stateful frontend especially around conversation lifecycle, persistence, and streaming agent activity in real time within your UI.

I'll go through a quick rundown.

What’s new in v1.50

1) New useAgent()hook (v2 API)
The new useAgent hook provides a clearer model for connecting a frontend to an agent runtime. It handles:

• Streaming agent messages and intermediate outputs

• Sending user input back to the agent

• Synchronizing UI state with agent execution

This reduces the amount of custom development required to keep the UI and agent aligned.

2) First-class threads and persistence
v1.50 introduces a built-in thread model so conversations can be stored, resumed, and reloaded reliably. This directly supports:

• Reconnecting after refresh

• Resuming previous conversations

• More predictable agent/UI synchronization

3) Shared state and message control
The release expands support for:

• Shared structured state between agent and UI

• Overriding or restoring message history (useful for recovery and testing)

• Coordinating multiple agents within the same UI context

4) Multi-agent awareness
Agents can now access and respond to each other’s messages, which makes collaborative or role-based agent setups easier to represent in the UI.

5) Updated UI components and customization
CopilotKit ships refreshed UI components with more flexible customization, making it easier to adapt agent interfaces to an existing product design rather than a fixed chat layout.

6) Expanded type safety with Zod
Zod support has been extended across more hooks and APIs, improving validation and consistency between tools, actions, and frontend state.

Migration notes

This is still part of the CopilotKit 1.x line and remains backwards compatible. Teams can upgrade first and adopt the newer APIs incrementally.

Question for the community

For those building with ADK, what part of the agent-to-UI connection tends to require the most effort today?

• Conversation persistence?

• Reconnection handling?

• Tool execution feedback?

• Multi-agent coordination?

Would be interested to hear how others are approaching this.

Getting Started docs:
Overview of 1.50 updates and code snippets:

Right now there is only 2 options to have a memory service, in memory and vertex ai, can I use some sort of local db or store?