Skip to main content
A session is the record of one conversation or task an agent or harness worked on, linking its runs, traces, and transcript. Use sessions to follow what an agent did across several runs and to compare Atlan’s record with the runtime.

How sessions are recorded

A session is created by whatever reports the work:
  • SDK tracing: Runs that share a session_id belong to one session. With ATLAN_AGENT_ID set, the SDK also writes a session record per run and counts the run’s model calls as its turns. See Group runs into sessions.
  • Session API: A runtime you cannot instrument can create sessions and post their messages directly. See Record completed run by hand.
Creating a session records work; it never runs the agent.

Sessions tab

Open the agent’s profile and select Sessions. Each session lists its turns and, when the runtime uploaded one, its transcript. No turns recorded or This session has no messages stored against it means nothing was reported for that part, not that nothing happened. An agent that runs outside Atlan and only sends traces has no sessions, however busy it is. The tab then shows No sessions run through Atlan and offers View runs, which opens the agent’s Performance tab where those runs are. A session appears here only when the agent’s runs are sent with its own API key.

Example

A support agent sets session_id to the ticket ID. A customer’s three messages produce three runs, which appear as one session on Sessions with three turns. The team compares the session’s last turn and timestamp with the ticketing system to confirm the ticket closed.

What sessions do not prove

  • That the work finished. An accepted session upload does not prove the external execution completed; compare the final events and timestamps with the runtime.
  • That runs belong to the agent. Sessions appear under the agent only for runs sent with its own API key. See How trace attribution works.

See also