Maximem Synap's Agent Memory Now Available for Google ADK
The Google Agent Development Kit is Google's official framework for building agents on GCP. Native Vertex AI integration. Type-safe workflows. Enterprise deployment patterns. If you are building agents inside the Google Cloud ecosystem, the ADK is where you start.
Today, Maximem Synap extends the Google ADK with persistent per-user memory. Native session state stores conversation data within a single process. Synap makes that state survive restarts, resolve entities across sessions, and retrieve relevant context without manual wiring.
Where Google ADK Excels
The Google ADK gives GCP developers a framework that feels native to the stack. Vertex AI model routing. Built-in tool integrations for Google APIs. Structured agent definitions with type validation. If your agent needs to call BigQuery, search Google Cloud Storage, or deploy on Cloud Run, the ADK handles the GCP plumbing well.
The problem emerges when your user returns after a day or a week. The ADK's session state handles the current run. It does not persist across process restarts. Native GCP integration does not help if the agent forgets what the user told it yesterday.
How Google ADK Memory Works Today
The Google ADK ships session state patterns for conversation tracking. All store data within a single process lifetime unless you wire external storage yourself. For a deeper look at how each works, see the Google ADK documentation.
In-Memory Session State stores every message in a dictionary attached to the agent run. This scratchpad grows with each turn. After twenty exchanges, your context window fills with accumulated noise. The agent struggles to find your actual instructions. When the process restarts, the dictionary clears. Every session begins at zero.
Firestore Session State persists to Google Cloud Firestore. Data survives restarts. But it stores raw messages without entity resolution. It has no concept of semantic retrieval. Cross-session queries are manual. Compaction does not exist. You pay for storage growth without accuracy guarantees.
Both options solve in-session state management. Cross-session persistence with per-user scoping, entity resolution, semantic retrieval, and automatic compaction fall outside their scope. These are memory-layer problems, not SDK-level concerns.
What Synap Adds
Synap is agentic context management. It does not replace the ADK's session state. It extends the framework with persistent memory the agent can call as needed.
We ship one factory that produces two FunctionTool objects:
create_synap_tools returns search_memory and store_memory. Drop them into the tools argument of any ADK Agent. The agent decides when to recall context and when to save new facts. search_memory accepts a query and optional max_results. store_memory takes content and an optional memory type. Both return structured results the model can reason over.
Scope is embedded in the tool closures, not passed to the model. Supply user_id and optional customer_id at initialization. The agent only sees query and content arguments.
The integration is a native package. Add two tools. Your agent starts remembering without a rewrite.
We built this because GCP agents kept stalling in production. The problem was not bad cloud integration. It was missing context that lived in a different session last Tuesday. Production testing hit 90.2% on LongMemEval. Typical retrieval returns in under 100ms.
For why context management is infrastructure and not a feature, read What Is Agentic Context Management?. For build-versus-buy numbers, see The Real Cost of DIY Agent Memory.
Technical Deep Dive
LongMemEval Benchmark
LongMemEval tests whether agents recall facts across long, multi-turn conversations spanning multiple sessions. The benchmark simulates production conditions where users return days apart and expect the agent to remember prior context. Synap scores 90.2% on this benchmark. Baseline vector-only approaches typically score 60-70%. The gap comes from entity resolution and temporal awareness that pure vector search lacks.
Entity Resolution Mechanism
Synap tracks identity across 15 reference patterns: names, emails, phone numbers, account IDs, session IDs, device IDs, and more. When an agent encounters "John" in one session and "[email protected]" in another, the resolution engine runs deterministic matching on structured fields, then probabilistic matching on unstructured references. Conflicts are resolved using temporal recency and source confidence scores. The result is a single canonical entity that accumulates context across all identifiers.
Accuracy-Preserving Compaction
Compaction identifies which facts are critical versus redundant. Critical facts include user preferences, constraints, commitments, and entity relationships. Redundant facts include repeated greetings, acknowledged statements, and intermediate reasoning steps. The compaction engine uses a classifier trained on conversation data to distinguish these categories. In Maximem's internal production testing, most integrations see 60 to 70% fewer tokens shipped to the LLM per turn after compaction kicks in. The accuracy preservation comes from never dropping classified-critical facts, even under aggressive token budgets.
Graph Traversal in Accurate Mode
Fast mode retrieves by vector similarity alone. Accurate mode adds a graph layer that traverses relationships between entities. If you ask about "the project John mentioned," the graph finds John, traverses to projects linked to John, and returns the relevant context. This adds latency but catches connections that vector similarity misses. Reranking then scores results by recency, confidence, and query relevance.
Multi-Tenant Scoping
Memory is scoped by three keys: user_id identifies the person, conversation_id isolates individual sessions, and customer_id enables multi-tenant deployments. A SaaS deploying agents for multiple customers uses customer_id to ensure tenant A never sees tenant B's memory. This scoping is enforced at the storage layer, not just in application logic.
For the Google ADK integration, scoping lives in the tool closures. Generate a fresh tool set per request so concurrent users cannot view one another's memories. Construct a dedicated Agent and Runner for each scoped interaction. This pairs Synap's storage-level scoping with ADK's process-level isolation.
What Synap Adds to Google ADK
Persistence
Google ADK Native. In-process or Firestore only. State does not resolve entities or compact automatically. With Synap. Per-user memory survives across sessions and restarts with entity resolution built in.
Entity Resolution
Google ADK Native. Raw identifiers. No linking across sessions. With Synap. "John" and "[email protected]" resolve to one canonical entity across every session.
Compaction
Google ADK Native. Manual summarization or no compaction. Lossy. With Synap. Automatic and configurable. Accuracy-preserving compaction that does not drop critical facts.
Retrieval Latency
Google ADK Native. Depends on Firestore setup. With Synap. Typical recall via search_memory returns in under 100ms.
Long-Term Recall
Google ADK Native. Not benchmarked for cross-session recall. With Synap. 90.2% on LongMemEval.
Failure Handling
Google ADK Native. Firestore retrieval throws catchable exceptions; unhandled errors abort the run. With Synap. Read failures return empty results and a logged error. Write failures raise SynapIntegrationError so you know persistence missed. Your agent keeps running.
User Scoping
Google ADK Native. Session-scoped only. With Synap. user_id and customer_id embedded in tool closures. Fresh tool set per request for multi-tenant isolation.
What Production Teams Gain
Cross-session continuity. Your user chats on Monday, returns on Wednesday. SynapHistory replays prior context. SynapRetriever surfaces relevant facts from last week. The agent treats every session as one continuous conversation. Native memory treats every session as a fresh start.
Accuracy that ships. 90.2% on LongMemEval measures whether agents recall facts across long, multi-turn conversations spanning multiple sessions. This benchmark tests the specific failure mode that breaks production agents: accurate recall over distance and time.
Token efficiency. Synap's compaction trims conversation history without dropping critical context. Most teams see 60 to 70% fewer tokens shipped to the LLM per turn. At scale, that is the difference between profit and burn.
Latency that does not block. Fast retrieval: 50 to 100ms. Accurate mode with graph traversal and reranking: 200 to 500ms. Both degrade without crashing. A failure returns empty results and a log line, not a broken agent.
Entity resolution. "John from Acme," "[email protected]," and "user_4829" resolve to one person across every session. Synap handles this at the memory layer so your agent does not have to.
Production resilience. Read failures return empty results and a logged error instead of crashing the agent. Write failures raise SynapIntegrationError so you know if persistence missed. Both tools implement standard ADK FunctionTool interfaces.
How to Get Started
Three steps. No rearchitecture.
Step 1: Install
pip install maximem-synap-google-adk google-adkStep 2: Initialize and wire
import os from google.adk import Agent, Runner from maximem_synap_google_adk import MaximemSynapSDK, create_synap_tools
sdk = MaximemSynapSDK(api_key=os.getenv("SYNAP_API_KEY")) await sdk.initialize()
Create scoped memory tools for this user
memory_tools = create_synap_tools( sdk=sdk, user_id="user_123", customer_id="acme_corp" # optional, for multi-tenant )
Wire tools into your agent
agent = Agent( name="support_agent", model="gemini-2.0-flash", tools=memory_tools, instruction=""" Use search_memory to recall prior context before answering. Use store_memory to save new facts the user provides. """ )
runner = Runner(agent=agent)
Step 3: Deploy
For multi-tenant production, construct a fresh Agent and Runner per request with user-scoped tools. This ensures tenant isolation at the process level. Synap handles persistence, compaction, and retrieval. Your agent handles GCP orchestration.
Full config, scoping rules, and error handling: https://docs.maximem.ai/integrations/google-adk
Memory Is Infrastructure
The Google ADK gave GCP developers a native framework for building agents. The session state it ships handles in-session data well. Giving that state persistence, entity resolution, and intelligent retrieval is a different layer of the stack.
The teams that ship production agents discover this around month three. They either build memory infrastructure themselves, or they plug in a system built for the problem.
Memory is infrastructure, not a feature.
Start building Google ADK agents that remember across sessions → (https://synap.maximem.ai)
Synap pricing is usage-based. You pay for memory operations: storage, retrieval, compaction. No per-seat or per-framework surcharge. The $49/month starter plan includes a base allocation; usage beyond that is metered by operation. Every new account gets $25 in free credits to test before committing. See full pricing at https://synap.maximem.ai/pricing.
Related Posts
