π§΅ Sessions
Review agent runs, inspect transcripts, and understand where session data lives.
Sessions is the flight recorder for every agent run from Slack threads, GitHub events, webhooks, schedules, or the Playground. The list contains the work allowed by each session audience. An Agent's Team visibility separately controls access to that Agent and does not hide a session you are allowed to read.
Find a session
Use the session list to find work by agent or source and follow scheduled runs back to the schedule that created them. When a readable session belongs to an Agent you cannot otherwise see, its Agent name remains available as a plain filter label rather than a link. When several agents participate in the same supported conversation, the list groups their sessions into one row.
Review a run
Each session records its source, agent, participants, daemon, runtime and model, along with duration, token usage, cost when available, and tool activity. Where the provider supplies it, the session links back to the original conversation.
Sessions snapshot their execution config: the header reflects what the run actually used, even if you've reconfigured the agent since.
The transcript
The transcript separates messages, reasoning, plans, tool calls, and file edits. Tool activity includes the available input and output, with diffs for file changes, so you can understand how the agent reached its result.
When several agents share a conversation
Each agent still runs in its own session with its own configuration and permissions. In a multi-agent Playground or supported IM conversation, the console presents those participant sessions as one conversation with attributed activity and combined current usage. This applies to Slack, Telegram, Discord, Lark, and Feishu conversations.
This grouping is a view over the sessions, not a new permission boundary. You see only the participant work allowed by each session's audience, including readable work from an Agent whose page is hidden from you. See Multi-agent work modes for ways to bring agents together.
Where transcripts live
The Control Plane stores session metadata such as title, status, timestamps, and token totals. Transcript messages and tool bodies remain on the daemon that ran the session.
When an authorized person opens a transcript, the console reads it from the owning daemon without persisting the body in the Control Plane. Metadata can remain visible while a daemon is offline, but its transcript cannot load until the daemon returns.
Retention and cleanup
Each daemon keeps finished session content for 7 days by default. When adding or editing a daemon, use Expire sessions to choose a common window, enter a custom number of days, or keep sessions indefinitely.
After the retention period, the daemon deletes the transcript, tool details and any Git worktree created for that session. Session metadata remains in the Control Plane, so the session stays in the list and clearly shows that its content was deleted by the retention policy.
Active sessions are not removed. AgentConnect also keeps a session worktree when it contains uncommitted work or commits that have not reached a remote.
Session audience
For a directly managed session, the header shows Everyone / Private when its matched owner may change the audience. A provider-bound session can instead follow Slack members, Feishu / Lark members, or GitHub members after the organization enables the corresponding setting under Settings β Session access. Making a session private hides the transcript immediately and can also change future memory capture; review Session visibility before tightening it.
Cross-platform handoffs stay separate
Conversation grouping does not merge different platforms or threads. A cross-platform handoff keeps one session on the source platform and starts a linked session on the destination. Replies stay where they were written unless the agent deliberately carries a result back.
See Hand off conversations between trusted workspaces for a Telegram-to-Slack example and a reusable agent instruction.
Agent-to-agent handoffs
Delegated work runs in a linked child session and inherits the parent session's audience. If you can read that audience, you can open the child session even when you cannot open the target Agent. The Agent name is shown only as non-clickable session context, and no Agent configuration or workspace access is added.
Live sessions
Running sessions update in place. Sessions started in the Playground can also be continued from the browser.
Updated 5 days ago