Multiplayer AI for companies and teams

Your company’s AI work,
in one room.

TerminalX turns every agent session into shared team work — one live terminal, real roles, clean handoff, and a record your company keeps. Contained in an isolated sandbox, so you can actually authorize it.

Isolated cloud sandboxScoped, revocable authoritySecrets the agent never sees
payments-api · migrate-stripe-webhooks1 of 6 livePRARAT
$ pytest tests/webhooks -q
..................... 21 passed in 4.18s
$ git diff --stat
src/webhooks/stripe.py | 84 ++++++++---
src/webhooks/verify.py | 31 ++++
2 files changed, 98 insertions(+), 17 deletions(-)
 
⟳ run goal 3/4 — retry + idempotency keys
⚠ approval required deploy to staging
waiting on a steerer…
Conversation3 present
PRPareshassignee

Take it through staging when the retry tests are green.

AGAgentrun 04

Retries and idempotency keys are in. 21 tests green. Staging deploy needs approval.

ARArtisupervisor

Paresh is offline. Taking control — I’ll approve staging.

run 04mode supervisedsandbox gen 7

The problem

Single-player AI doesn’t scale to a company.

Every AI coding tool assumes one engineer, one chat window, one laptop. That works for an individual. At company scale it produces four predictable failures.

Silos

Everyone has a private chat

Dozens of separate conversations, none of them visible to anyone else. The company accumulates isolated context instead of compounding knowledge.

Attention

Runs outlive the operator

A task that works for hours will pass the point where the person who started it is still watching. The run stalls at the first decision.

Continuity

Nobody can take over

A colleague can’t pick up the thread without losing the reasoning, the goals and the history that got the work there.

Visibility

Leadership sees nothing

No view of what agents are doing across teams, what they touched, or who authorized it — until something breaks.

The workspace

Every session your teams are running, in one place.

Not one shared terminal — as many concurrent sessions as your teams have work. Each one is its own durable Team Session with its own participants, roles and run. The workspace is where an engineering lead sees all of them at once, and where anything waiting on a human surfaces immediately.

Acme · workspace6 live2 need a human
platform / payments-api
migrate-stripe-webhooks
PRARAT3 present
run 04 · supervised
approval
web / checkout
flaky-e2e-triage
SLTN2 present
run 11 · autonomous
running
infra / terraform
drift-cleanup-eu-west
MORBKDHL4 present
run 02 · supervised
running
data / orders-pipeline
backfill-2025-q4
EV1 present
run 07 · autonomous
blocked
mobile / android
release-4.2-regression-sweep
ATARZRPRFT5 present
run 09 · supervised
running
billing / dunning
retry-schedule-rewrite
SLDV1 member · 1 guest
run 03 · supervised
running

People move between sessions; sessions don’t belong to people. The same engineer can be assignee on one, supervisor on another, and merely present on a third — with different steering authority in each.

Inside one of them.

Open any session and it’s the same durable object: live terminal, threaded conversation, who is present, artifacts, and the current run state — in one frame everyone authorized is looking at simultaneously.

Team Session · platform / payments-apilive
14:02:11 sandbox gen 7 attached · isolated · egress brokered
14:02:12 Paresh started run 04 — supervised
14:02:12 Arti added as supervisor
$ alembic upgrade head
INFO running upgrade a41f → c92b, webhook_events
INFO 3 migrations applied
$ pytest tests/webhooks -q
..................... 21 passed in 4.18s
requesting approval: deploy staging (destructive)
bound to session 8f2a · policy p-14 · sandbox gen 7
expires in 09:41
Participants4
PRPareshassigneeARArtisupervisorATAtharvasteererDVDev (Northwind)guest
Artifacts
Ddiff · 2 filesTtest reportMmigration plan
run 04goals 3/4mode supervised

Roles

The structure your organization already has.

Access is granted through the team, and steering authority is separate from presence. Being in the room does not mean being able to drive.

TTeam

The organizational unit. Members belong to it, and access to sessions is granted through it.

MMember

Full access within the team, not restricted to individually invited sessions.

GGuest

A contractor, agency or partner with access only through explicit, revocable session shares.

AAssignee

The single participant currently responsible for carrying a session forward.

SSupervisor

Can oversee, take control, and delegate steering when the assignee is unavailable.

StSteerer

Authorized to send directives or terminal input under the current steering fence.

Revoking one relationship never silently preserves another. Remove a guest and their access to sessions, connections and standing authority goes with them — in one action, not six.

Handoff

Across people, shifts and timezones.

End of shift. On-call rotation. A holiday. Someone leaving the company. The work continues under the same goals, and every control transfer is recorded.

14:02
Paresh starts run 04, adds Arti as supervisor

The session is shared from the first second — not escalated into sharing after something goes wrong.

14:02 — 17:38
The agent works autonomously in the sandbox

Migrations, retries, idempotency keys, 21 tests green. The team can watch or ignore it.

17:38
A staging deploy needs a decision

Destructive operation. The run pauses at the fence rather than proceeding on a blanket permission.

17:39
Paresh is offline — Arti takes control

Arti steers directly, or assigns Atharva as an additional steerer. No credentials change hands, and nothing is re-explained.

17:41
The run continues under the same goals

Same session, same history, same evidence. The transfer itself is part of the record.

Work never depends on one person being awake.

The record

A record your company keeps.

Session history, decisions, goals, blockers, approvals and evidence survive disconnects and restarts. Every control transfer and material effect is version-fenced and recorded — reviewable long after the run ends.

TimeActorEventBound to
17:38:04AGAgentRequested approval — deploy stagingsession 8f2a · policy p-14 · gen 7
17:39:12ARArtiTook control from assigneesupervisor fence · run 04
17:39:48ARArtiGranted approval — expires 09:41one-use · gen 7
17:40:02ARArtiAssigned Atharva as steererrun 04 · revocable
17:41:30AGAgentDeploy staging — receipt recordedgen 7 · receipt r-2291
18:04:19DVDev (guest)Access revoked at session closeshare s-77 · all connections

Institutional memory, not vanished chat logs

The reasoning behind a change stays attached to the change. Six months later, the session still explains why.

Juniors learn by watching seniors steer

Real runs, real decisions, real fences — observable without handing anyone production access.

Containment

Contained enough to authorize.

The reason a company can say yes. Autonomy here is scoped authority with a defined edge — not a blanket permission bypass on somebody’s laptop.

Execution is isolated. Runs happen in a hosted sandbox, not on a developer’s machine sitting next to everything else they can reach.

Authority expires and is bound. Approvals are tied to the exact user, policy, session and sandbox generation. Change the sandbox and prior authority is invalid.

Dangerous operations are explicit. A prominent, expiring, one-use confirmation — never a mode somebody leaves switched on.

Secrets stay behind a broker. Raw credentials are never visible to the agent, terminal, logs, artifacts or model output.

Recovery doesn’t need the operator. Emergency stop, quarantine and grant revocation work without the person who started the run.

Everywhere your team is

Same sessions, whichever screen you pick up.

Cloud-hosted and reachable from the browser, phone, tablet and desktop — plus Telegram and Slack. Same history, same authority, no separate mobile compromise. The person who needs to approve something at 11pm is on their phone.

──────────────────
$ pytest -q
21 passed
⚠ approval required
──────────────────
3 present

Browser & desktop

The full workspace — every session, plus terminal, thread, participants, artifacts and run state inside each one.

⚠ Approval
deploy staging
expires 09:41
[ Approve ] [ Deny ]

Phone & tablet

Watch a run, take control, approve or deny at the fence — from anywhere.

TerminalX · payments-api
run 04 needs approval
deploy staging
↳ reply to steer

Telegram & Slack

Brokered, revocable identities. Steer from chat without exposing raw tokens.

Book a demo

See a real workspace.

A live walkthrough against your own workflow — terminal, roles, handoff and the sandbox boundary, across several sessions at once. Not a slide deck.

  • 30 minutes, screen-shared. Nothing to install to see it.
  • We start from what your engineers are actually running agents on today.
  • You’ll see a handoff and a revocation performed live, not described.
  • Someone from the team replies within one business day.

TerminalX is early and works closely with the first teams that adopt it — which means direct access to the roadmap and real influence over what ships next.

This is a design preview — no form backend is connected yet.