Response from ADK Answering Agent (experimental, answer may be inaccurate)

TLDR: You can absolutely implement a custom MemoryService and deploy it with your agent to Cloud Run. For more complex, structured data like tool usage patterns, consider using session.state which persists across turns in a session. The after_tool_callback is the perfect place to integrate your custom memory logic, and you can apply it globally using a plugin.

Hi @enxilium,

Thank you for your detailed questions. Here’s some information that might help you build your proactive agent with a custom memory system.

1. Custom Memory Service Integration

Yes, you can implement a custom MemoryService and deploy it with your agent. The ADK is designed to be deployment-agnostic, allowing you to run the same agent logic locally or in the cloud. [1] When deploying to Cloud Run, you can use the --memory_service_uri flag to specify the endpoint of your custom memory service. [2]

You can also instantiate your custom memory service directly in your code and pass it to the Runner, similar to how VertexAiMemoryBankService is used in the documentation. [3]

2. Vertex AI Memory Customization

The built-in VertexAiMemoryBankService is primarily designed for conversational memory and automatically extracts memories from conversations. [3]

• Focusing on specific interactions: The service automatically processes conversations. You would need to implement custom logic in your agent to filter or select the types of interactions you want to store.
• Custom confidence scoring and proactive triggers: These features are not available out-of-the-box in the VertexAiMemoryBankService. You would need to implement this logic within your agent or your custom memory service.
• Storing structured data: For structured data like tool execution logs, session.state is a great option. It can store any Python dictionary and persists across turns within a session. [4]

3. Deployment Constraints

• Cloud Run: As mentioned, you can deploy a custom memory service and use the --memory_service_uri flag to connect it to your agent. [2]
• Agent Engine: When deploying to Agent Engine, your application will automatically use VertexAiSessionService. [5] The documentation does not explicitly state whether a custom memory service can be used in this environment.

4. Local vs. Cloud

You do not need to stay local to have full control over memory management. You can build and deploy a custom memory service to the cloud, giving you the same level of control as you would have in a local environment. [1]

5. Tool Integration

The after_tool_callback is an excellent choice for integrating your custom memory logic. It is executed after a tool runs and provides access to the tool, its arguments, and the result. [6] This is the ideal place to log tool executions to your custom memory service. To apply this logic globally to all your agents and tools, you can use a plugin. [7]

While the documentation does not explicitly mention after_tool_callback in the context of MCP tools, it is very likely to work as expected, since MCP tools are integrated as standard ADK tools. [8]

I hope this helps!

References

[1] https://google.github.io/adk-docs/get-started/about/
[2] https://github.com/google/adk-python/blob/main/src/google/adk/cli/cli_deploy.py
[3] https://google.github.io/adk-docs/sessions/memory/
[4] https://google.github.io/adk-docs/sessions/
[5] https://google.github.io/adk-docs/deploy/agent-engine/
[6] https://google.github.io/adk-docs/callbacks/
[7] https://google.github.io/adk-docs/tutorials/agent-team/
[8] https://google.github.io/adk-docs/tools/mcp-tools/

Bumping this as the issue is urgent.