Feature request: agent_users table to associate sessions with users

[ecanlar]

Feature Request

Problem

Currently, agent_sessions exist independently without a way to associate them with application-level users. When building multi-user applications, there's no built-in mechanism to link a session to a specific user identity, making it difficult to:

• Retrieve all sessions belonging to a particular user
• Manage user-scoped session history
• Implement user-level session lifecycle management (e.g., cleanup, export, limits)

Proposed Solution

Introduce an agent_users table (or equivalent concept) that allows associating sessions with users, similar to how Google's Agent Development Kit (ADK) handles user-session relationships.

The basic schema would look something like:

CREATE TABLE agent_users (
    user_id TEXT PRIMARY KEY,
    metadata JSONB,
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW()
);

-- Add user_id foreign key to agent_sessions
ALTER TABLE agent_sessions ADD COLUMN user_id TEXT REFERENCES agent_users(user_id);

This would enable:

• User-scoped session queries: Fetch all sessions for a given user
• User metadata storage: Store user-level context that persists across sessions
• Session ownership: Clear association between who owns a session
• Multi-tenant support: Easier to build applications serving multiple users

ADK Reference

Google's ADK models this as a User → Session relationship where each session is scoped under a user. This is a natural pattern for agent-based applications where:

1. A user interacts with the agent
2. The user may have multiple sessions (conversations) over time
3. The agent needs to retrieve user-level context across sessions

Additional Context

This is a common need when building production agent applications. Without this, every developer ends up building their own user-session mapping layer on top of the SDK.

[seratch]

Thanks for the suggestion. Since most services typically have their own user tables, we generally recommend using a join table between agent_sessions and your user tables. This approach allows the agent_sessions table to work with different types of user data tables. It may not fit your use case, but we would appreciate your understanding. If you still need an admin_users table, please use your own custom session store implementation.

[ecanlar]

Thanks for the quick response, I appreciate the clarification! That approach makes sense.