Panopticon — A Fleet of Agents. One Operator. | Unsupervised

A fleet of agents. One operator. Without giving up control.

Juggling raw terminal sessions, most people top out at six or eight concurrent agents. Panopticon runs each agent in its own container and tmux session, sorts the ones waiting on your judgment to the top, and lets one person run 3× as many.

$ pipx install panopticon-app

Watch everything. Touch only what needs you.

Every row is one agent, in its own container and tmux session. The turn column is the whole discipline: amber means an agent came back with something only you can decide (red ⚠ if it's hard-blocked); green means it's working; leave it alone. Press t to attach to a session, decide, detach. Two rows need you; the other twenty-four keep working.

 ⭘                                                        panopticon
 state          turn    container  repo    slug[memo]
 ITERATING      user ⚠  live       webapp  slow-dashboard-query[investigate slow query]
 PLANNING       user    live       webapp  api-rate-limiting[add rate limiting to API]
 ORCHESTRATING  agent   live       webapp  billing-refactor[split refactor into tasks]
 REVIEW         agent   live       webapp  fix-checkout-flake[fix flaky checkout test]
 MERGING        agent   live       webapp  payment-retry-logic[babysitting merge queue]
 ITERATING      agent   live       docs    update-getting-started[refresh setup guide]
 PLANNING       agent   live       infra   rotate-stale-tokens[rotate expiring tokens]
 REVIEW         agent   live       webapp  search-index-rebuild[rebuild stale index]

t Attach  n New task  x Drop  / Search  d Detail  ? Help    active agents 23/26

How it works

01 Isolation by default

Every task gets its own Docker container and its own git branch. Agents cannot step on each other, or on you.

02 Supervision by exception

Tasks whose turn flips to you rise to the top of the dashboard in amber. One keystroke attaches you to that agent’s live tmux session; detach and you’re back over the fleet.

03 Built-in workflows: PRs, orchestration, open research

Each task declares a lifecycle. PR workflows walk plan → iterate → review → merge (peer-reviewed, self-reviewed, or local-only): you approve each stage and the agent babysits CI and the merge. Spikes run ungated for open-ended research. The orchestrator turns one goal into a batch of new Panopticon tasks, each arriving pre-planned — you review plans instead of writing tasks.

04 A control plane that never calls a model

The runner, task service, and dashboard are deterministic. Every LLM token is spent inside an isolated, per-repo-credentialed task container.

Quickstart

Install it, point it at a repo, start the fleet.

$ pipx install panopticon-app
$ cd ~/code/my-project         # the repo you want agents to work on
$ panopticon quickstart        # checks prereqs, mints a repo token, opens the dashboard

Runs locally with Docker and tmux. Drives Claude Code today; other agent CLIs are on the roadmap.

Or let your agent run the fleet.

The dashboard is one client of Panopticon's HTTP API; the agent you already work in can be another. The easiest first run is to ask your harness to farm its next batch of subtasks out to Panopticon: you watch each delegated task on the dashboard instead of losing them in one agent's transcript, and the agent gets a system for organizing its own work.