Monitoring multiple AI agent sessions from one screen

AR Labs runs many AI agent sessions at once: coding agents such as Claude Code and Codex in terminal windows on a laptop, and longer-running agents on a server. An AI agent is a language model run in a loop with tools, so it can act, not only reply, and each session is one running conversation with an agent. Beyond a handful, a person loses track: terminal windows stay open as bookmarks, work waiting for a decision goes unnoticed, and a finished conversation is hard to find again. This page sets out what we think a person needs in order to see and steer many sessions from one place, and the rules we follow for returning to a conversation without opening the wrong one. It is the problem-and-requirements page; the views we built to meet it are described in AI agent operations dashboards and goal maps.

What a person needs on one screen

The table lists the needs in the order a person meets them, and where our tools stand on each.

Need	Why it matters	Where we stand
Which sessions exist, in every agent program and on every machine	Work cannot be steered if its session cannot be found	Built as a snapshot: a background sweep lists running and recent sessions for the goal map
What each session is working on	A list of session names says little; grouping by project and purpose says what the work is for	Built: the goal map groups sessions around the projects they serve
What is waiting for a person	Agents that need a decision stop, and nothing tells the person unless the view does	Built in VOX Torch, our terminal view over tracked work, as a "Needs you" screen across all lines of work
How old each fact is	A view opened days later must not show stale sessions as active	Built for the current snapshot: ages are measured from the viewer's clock and the page warns once its data is a day old
A route back into any conversation	Returning to work should not depend on remembering which window held it	Partly built: an open session's terminal tab can be brought to the front. Reopening a closed conversation from the map is designed, not built
A durable list that outlives the sweep	A conversation that drops out of the sweep should not vanish from the person's view	Designed, not built
What the view showed at an earlier time	A person sometimes needs to see which sessions were on which work last week	Designed, not built

Three facts that must stay apart

A session view mixes facts that change at different speeds, and conflating them makes the view mislead. Our design keeps three apart, each with its own timestamp; the current goal map already shows the sweep's observation and a timed live check of the process separately.

• When the session was last observed. A sweep is a snapshot. Its age is shown, and a partial refresh says what it covered rather than implying the whole fleet is current.
• Whether its process is running. Running, stopped, launching, unavailable or unknown. Running does not mean working: a session is shown as busy or idle only when there is evidence for it.
• The state of the work. Whether the work waits on a person, and how its project stands, come from the task tracker and the project's own records, not from the process.

Missing evidence stays "unknown". It is never filled in with a guess, and an unknown process state blocks any automatic action until it is resolved.

Linking sessions to the work and its record

A session is easier to return to when it is tied to the task it serves. We track work in Beads, Steve Yegge's open-source issue tracker for coding agents; one tracked task is a bead. A skill (packaged instructions an agent loads only when a task needs them) records on the bead the session's name, its identifier and the terminal it ran in, so the exact conversation can later be resumed by name. How this works, with the event logs and history search behind it, is on session history and memory.

The conversations themselves stay where each agent program keeps them. Our designed session list stores references to those records (the agent program, the session identifier, the working folder and where the transcript lives), never a second copy of the conversation, the task state or anyone's permissions. When a conversation moves from one agent program to another, the list keeps the earlier reference beside the current one, so the history of where the work lived is not lost.

Rules for returning to a conversation safely

Reopening the wrong conversation is worse than reopening none, because work then continues in the wrong context. The design follows a fixed decision for every request:

flowchart TD
  R["Request: return to entry"] --> I{"Process found by session identity?"}
  I -->|"Running"| F["Bring its window to the front"]
  I -->|"Unknown or conflicting"| X["Report it; do nothing"]
  I -->|"Stopped"| W{"Workspace still exists?"}
  W -->|"No"| X
  W -->|"Yes"| L["Resume that exact conversation"]
  L --> V{"Attached to the expected session?"}
  V -->|"Yes"| OK["Report success"]
  V -->|"No"| X

The rules behind it:

1. Identify a session by its own identity, never by a name or a process number. Process numbers are reused and titles repeat. A session is matched by the identifier its agent program gives it and, for a running process, by when that process started. Two sessions with the same title are reported, never chosen between.
2. Never fall back. If the exact conversation cannot be resumed, the action fails and says why. It does not start a new conversation, a copy, or an older version of the session.
3. One launch at a time per conversation. Repeated clicks or simultaneous requests produce at most one launch, and a launch attempt is recorded before it starts.
4. Check the result, not the request. A terminal reporting that it opened is not success. Success is reported only once the expected session is confirmed attached.
5. Accept only what the view should send. The local helper accepts a list entry and an action: no commands, programs or folders from the page, and no requests from other machines.
6. Leave security settings alone. Resuming never adds flags that bypass the agent program's permission prompts and never changes trust settings to make a launch succeed.
7. Hiding is not stopping. Archiving an entry removes it from the drawing but keeps it searchable; it does not touch the process or the conversation. Closing a process is a separate, later step, which refuses when the session is busy or its state is unknown and never forces it to quit.

What exists today

Part of this runs and part is design. The goal map, a private working page, shows a snapshot of sessions across our agent programs grouped by project, measures freshness from the viewer's clock, and can bring an open session's terminal tab to the front. Its helper finds sessions by their own identifiers, refuses a saved process number now owned by a different session, and reports duplicate titles instead of picking one; tests cover these identity rules. VOX Torch's "Needs you" screen lists what waits on a person across all lines of tracked work, and sessions are linked to tasks with a skill.

The durable session list, reopening a closed conversation from the map, discovering closed sessions, rewinding the map to an earlier snapshot, and closing an idle session safely are designed and not built. Sessions on the server are shown for observation only. These pieces sit within VOX OS, our design for an operating layer over agent work, whose aim is that a person finds and steers agents from one interface rather than by switching windows.