Sessions

Sessions is the flight recorder for every agent run from Slack threads, GitHub events, Linear delegations, 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 sessionCopy Anchor Link

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 runCopy Anchor Link

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 transcriptCopy Anchor Link

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 a run asks for permissionCopy Anchor Link

Depending on the agent's permission mode, a runtime can stop in the middle of a turn and ask before it acts. The turn parks until someone decides, and there are three places that decision can be made:

• In the console. Anyone who can edit the agent can decide, including an organization Owner outside its Selected list. Use the agent page, or the session page when its audience allows you to open it. The notification bell raises an unread Approval needed item pointing at the waiting session, and marks it resolved once the wait ends. In a Playground or agent chat API conversation, its owner can also decide among the pending requests above the composer, unless the agent is set to Talk to the agent.
• In a Slack or Teams direct message. When the card is not posted in the conversation, or only editors may answer it there and the person who asked is not one, the agent sends the same card in a direct message to one person who may decide and has linked their Slack or Microsoft account, with a link to the session and, on Slack, to the message that started the work. Deciding there is the same decision as deciding in the console, and the console records who made it.
• In the conversation. When the agent's What people can do in chat includes approving tool calls, as it does by default, Slack, Telegram, Discord, Lark / Feishu, Google Chat and Microsoft Teams post the card where the work is happening: in its thread, or in its Telegram topic or reply chain. The card offers the runtime's own choices, including always allowing the tool where the runtime offers it. On Slack with Follow Slack access on, or Teams with Require Microsoft Teams access on, only the agent's editors can answer it; where permissions are not synced this way, anyone in the conversation can. A refused click is told only to the person who made it, and the card stays as it is for everyone else.

The first answer from any of these places decides, and the card then says who answered and how.

At Talk to the agent, and in a conversation switched Off or answered By decision, the conversation gets a short notice instead: an approval is waiting and an agent editor has to allow it. On a platform with approval cards, the notice changes to how the approval ended once someone decides. QQ has no approval card, so a QQ conversation always gets the notice and its approvals are answered in the console. A conversation shared with another organization gets no card; the approval goes to a member of your organization in a direct message. A Linear session posts the same pointer into the issue's activity feed, with a link into the console.

For Slack and Teams DM notifications, AgentConnect chooses one recipient. It tries the agent's Slack workspaces before its Teams organization, and within each it checks these candidates in order:

1. The person who sent the message that triggered the turn.
2. The session owner.
3. For a Selected agent, its explicitly selected members in their saved order.
4. The agent's creator.

Every candidate must be a current organization member who can edit the agent and has a linked Slack identity in that workspace, or a linked Microsoft account for Teams. Owners qualify even when they are not selected, but being an Owner alone does not add them to the recipient list. An Owner receives the DM only when this order selects them.

AgentConnect rechecks edit permission and the linked account when the recipient clicks. If no eligible recipient can be resolved, the approval stays available in the console and the conversation keeps its waiting notice.

When several agents share a conversationCopy Anchor Link

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 liveCopy Anchor Link

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 cleanupCopy Anchor Link

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 audienceCopy Anchor Link

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 separateCopy Anchor Link

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 Slack-to-Discord example and a reusable agent instruction.

Agent-to-agent handoffsCopy Anchor Link

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 sessionsCopy Anchor Link

Running sessions update in place, and the session page offers a composer for the ones you may continue:

• Playground and webchat sessions are continued in the browser, as they always were.
• A chat-platform session — a Slack thread, a Telegram or Discord chat, a Lark / Feishu conversation — takes your message from the console and mirrors it into the original thread first, so the people there see what changed the agent's context. The agent's reply follows that session's own output mode.
• A session started by a GitHub, GitLab, webhook or schedule event is continued console-only. Nothing is posted to the pull request, the issue, or the event's origin.

Continuing is a write, so a Viewer never can, and a private session stays with the person who owns it. Beyond that it follows the session's audience, and it needs the owning agent to be visible to you and its daemon to be online. When one of those is missing, the composer explains itself instead of appearing.