openviking long-term memory backend writes conversation messages to OpenViking user memory and retrieves entities, events, and preferences by user identity. It is available in VeADK 1.0.3 and later.
Runner.user_id is the end-user identifier that VeADK uses as the OpenViking peer_id for memory isolation. openviking_user_id is the OpenViking owner/context used to isolate memories for different applications or tenants within the same OpenViking service. The two are distinct concepts.Example
Parameters
LongTermMemory parameters
OpenViking backend parameters
By default,
user_id becomes the peer ID and may contain only letters, digits, periods, underscores, @, and hyphens. Pass peer_id_resolver to customize this mapping.
When openviking_user_id is not configured, VeADK checks DATABASE_OPENVIKING_USER_ID and falls back to default, emitting a warning. Set it explicitly for each application or tenant to avoid mixing memories from different applications under the same default path.
When memory_policy is unset, VeADK sends no policy to OpenViking and the OpenViking service applies its official default. To explicitly control the extraction scope and isolation, pass a valid memory_policy whose structure follows the OpenViking session API. For example:
Environment variables
Customize user mapping
Multi-tenant applications can providepeer_id_resolver to combine the application and user into one isolation key:
@, and hyphens, and cannot be . or ... Changing the mapping after deployment leaves existing memories under the old peer path, so later retrievals may no longer find them.