# What breaks when a team runs coding agents separately

> Agent sessions default to one laptop, one terminal, one person. Here is what that costs a team, and what has to change structurally to fix it.

- Source: https://consortium.dev/blog/sharing-agent-sessions-across-a-team/
- Published: 2026-08-27
- Author: The Consortium Team
- Tags: teams, workflow, sessions
- Site: Consortium — https://consortium.dev

---
## Why can't a teammate see my agent session?

Because the session lives in your terminal, and your terminal is not a shared surface. The
agent writes to a TTY that exists on one machine, inside one process group, attached to one
window. There is no address anyone else could point at.

This is not a missing feature so much as the default shape of the thing. A CLI agent
inherits the assumptions of a CLI: one user, one shell, one session. Those assumptions are
fine right up until more than one person cares about the outcome.

## What it costs in practice

**Review happens through screenshots.** The reviewer cannot see the run, so the operator
pastes fragments into Slack. Whatever is not pasted is invisible, which usually includes
the part that mattered.

**Only one person can intervene.** If the agent stalls waiting on a permission prompt, it
waits for the person whose laptop it is — regardless of who is awake, free, or better
placed to answer.

**Context dies with the session.** What the agent tried, what it rejected, and why, lived
in a scrollback buffer on one machine. The next person starts from nothing.

**Handoff means starting over.** Passing work to a colleague means re-explaining it,
because there is no artefact to hand over — only a transcript they cannot open.

None of these are agent-quality problems. A better model does not fix any of them, because
none of them are caused by the model.

## What has to change

The session has to stop being a property of a terminal and become a property of a
workspace. Concretely, three things follow from that:

**Sessions outlive the terminal.** If a session dies when a window closes, it cannot be
shared, because the thing you would share is not guaranteed to exist when someone goes
looking for it. Persistence is a prerequisite, not a separate feature.

**Attaching does not require shell access.** A reviewer should be able to see what the
agent has done, and approve or stop it, without credentials on the machine it runs on.
Otherwise sharing a session means handing out a shell, and it will not happen.

**Access is set in one place.** Who can see which sessions belongs to the workspace, not to
whoever happens to have the SSH key.

## How Consortium models it

Sessions live in an organisation workspace rather than on one machine. An agent still runs
on a team member's machine, against their working tree, with their credentials — but it is
reachable inside the shared workspace, so it behaves like a participant rather than a
background process.

In practice that means one person can start a run, a second can review or redirect it from
a phone, and the agent keeps working through both, because the session belongs to a
persistent daemon rather than to whoever opened the terminal.

Your code still executes on your own machine; Consortium is a control surface, not a hosted
runtime. Session content that syncs between devices is encrypted in transit and at rest, and
you choose who holds the key: escrow custody so a lost recovery phrase is not a lost account,
or end-to-end custody so the relay carries ciphertext nobody but your devices can open.

## Is this worth changing for?

If you are one person running one agent on one machine, no. The terminal-shaped default is
a good fit, and adding a workspace buys you nothing.

It starts mattering the moment a second person needs to see what an agent did — during
review, during handoff, or when someone is on-call for a run they did not start. That is
the point at which "it is on my laptop" stops being an implementation detail and starts
being the constraint.
---

## Frequently asked

### Can two people watch the same AI coding agent session?

Not by default. An agent started in a terminal is visible only to that terminal. Sharing requires the session to live somewhere other than one person's shell — a workspace both people can attach to.

### Do I need to give teammates SSH access to review an agent run?

With a plain terminal session, effectively yes, which is why review usually degrades into pasted screenshots. A shared workspace model lets someone read and redirect a session without shell access to the machine it runs on.

### Does sharing a session mean sharing my source code with a server?

Not necessarily. If the agent executes on your own machine and the service is only a control surface, the server relays session content rather than hosting your code. Whether that content is readable by the server depends on whether it is end-to-end encrypted.