Sessions

All three agents remember your conversation across platforms. If you start a conversation in Slack, and the agent creates a Jira ticket and a dashboard session from it, all three are linked — follow-ups on any surface have the full context of the original conversation.

How it works

When you interact with an agent, it creates a session to track the conversation. As work progresses across platforms, each new surface (Slack thread, Jira ticket, dashboard session) is linked to the same underlying session.

This means:

• A comment on a Jira ticket that an agent created from Slack gets routed to the same conversation
• Workflow results (plans, PRs, reports, designs) are posted back to the right Slack thread and Jira ticket
• The dashboard shows the full history regardless of where the conversation started

Note

Dolly and Pearl are “inline” agents — they reason and respond directly without dispatching pods. Their sessions track conversation context across Slack and Jira, but they do not have EKS pods, terminal access, or pause/resume capabilities.

Results delivery

When work completes, agents post results back in this priority order:

1. Jira — if the session has a linked ticket, post a comment there
2. Slack — if the session has a linked thread, post a message there

Pause and resume (Buck only)

Buck sessions can pause mid-work. When paused, the pod saves workspace and conversation state to S3. The session record stores a state_key (S3 key for state archive), scrollback_key (terminal scrollback), and last_assistant_message (Claude’s final message before pausing).

To resume, the agent dispatches a new pod that restores the workspace and conversation from S3, then continues with optional follow-up instructions. resume_count tracks how many times a session has been resumed.

Terminal access (Buck only)

While a Buck session pod is running, the dashboard can connect to it via WebSocket for interactive terminal access. This uses the AttachSession bidirectional streaming RPC, which proxies stdin/stdout to the pod’s tmux session.

Session expiration

Sessions expire after 30 days of inactivity across all agents. After that, a new interaction creates a fresh session.

Technical details

Sessions are UUID-based and managed by Google ADK. A SessionIndex table maps platform-specific identifiers to canonical session UUIDs. Index keys are agent-scoped — each agent maintains its own namespace:

Platform	Index key format	Example
Slack	{agent}:slack:{channel}:{thread_ts}	buck:slack:C01ABC:1234567890.123456
Jira	{agent}:jira:{issueKey}	dolly:jira:PROJ-1234
Dashboard	{agent}:dashboard:{session_id}	pearl:dashboard:abc-123

Storage: Aurora PostgreSQL in production (GORM, auto-migrated), in-memory for local development (falls back when DATABASE_HOST is unset).

Pending sessions (Buck only): The run_claude_session tool records a PendingSession mapping the session ID back to the ADK session. When the EKS pod completes and reports back via pod-bound JWT auth, the agent resumes the correct session. Pending sessions expire after 1 hour.

Upsert semantics: The session index uses first-writer-wins (ON CONFLICT DO NOTHING), so the first event to register a platform key owns the mapping.