What breaks when a team runs coding agents separately

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.