# First-class sessions

This is a vision of how software teams work with coding agents: an idea
held apart from any particular tool or project.

Teams collaborate on agent work through the pull request today, and the
pull request arrives too late: by the time anyone else can look, the
intent, the conversation, and the dead ends have already evaporated,
leaving a diff and a description of it. Collaboration does reach earlier
than that: an agent working a chat thread already has people steering it
together, but a thread stands apart from the changes it produces, and it
fades as the channel scrolls on.

The central claim is that the session is first-class, the primary
component of agent-driven software work. A session is the whole unit: who
asked for what, the conversation that steered the work, the actions agents
and people took along the way, and the changes that came out of it. It is
durable and addressable, at a URL that works while the work is happening
and keeps working after. Everything else derives from the session. A pull
request is one export of it, not the frame around it.

## What changes when this works

- Collaboration moves earlier, until review stops being a separate stage.
  People join, watch, and steer work while it happens, and the session
  absorbs review: by the time the work is done, the people who needed to
  look already have.
- Agent work becomes legible. A session keeps the wrong turns along with
  the result, so a team can learn from how the work went, not only from
  what landed.
- Sessions feed the system's own improvement. A durable record of real work
  is an eval corpus nobody had to construct: replay a past session against
  a new agent, prompt, or policy and compare how the work goes, or mine
  sessions for where agents stalled and where people had to step in. The
  same record that makes work legible to the team lets the tooling study
  and improve itself.
- Work forks. A session is a starting point as well as a record. A new
  session branched off an existing one carries its context and its
  changes, so exploring an alternative does not mean starting over.
- Sessions are context for other sessions. Anything in the ecosystem can
  reach the session that produced a change, so reviewing agents can examine
  work with the exact history of how it came to be, or deliberately without
  it — blind review becomes a choice rather than the default. The
  examination is itself a session, one the original work can consult in
  turn.
- Every participant is a peer on one record. Humans, agents, and channels
  (a chat thread can be a participant) act through attributed turns, and
  the session's own log of who did what is the shared truth.
- Capability flows through the session. An agent holds nothing of its own;
  it asks the session for what it needs (a repository, a pull request, a
  build) and the grant carries the authority of the person behind the ask.
  Shared sessions make this necessary: once several people are present,
  "who may do this" has to have an answer.

## What this is not

- An agent framework. Agents are built elsewhere and reason however they
  reason; the session decides what they may do.
- A pipeline runner. A schedule, an alert, or a failing build can open a
  session, but what opens is a session like any other, one that people can
  join and steer. Work nobody could join is a different tool.
- A hosted product. It runs where the team runs, inside the team's own
  trust boundary.

_Composed by Claude_