Multi-Session Agent Board

Some jobs are too much for a single AI — backend, frontend, and a DB migration at once, or one big refactor split by area. The Multi-Session Agent Board puts multiple AI agents on one screen (a board), lets them work as a team, and keeps you in safe control with a run queue and unified approvals.

Blyck’s angle isn’t “a place to run agents” — every major tool can do that now. It’s “a place to run them, then trust and merge the result.” Three layers make that real: orchestration (see and relay across sessions), governance (ChangeSet + unified approvals to review while they run), and an operations workbench (DB, SSH, terminal, and preview right next to the agents, with environment isolation).

What it is

Lay out multiple AI chat sessions (a mix of Claude and Codex) as cards on one board.
Visualize agent relationships and work flow in real time as a node/edge graph.
Agents hand work to each other (relay) and run in parallel, while the run queue prevents conflicts.
Every approval request is gathered in one place — the unified inbox at the bottom.

Opening the board

Click the 🤖 button in the header to open an Agent Board panel (in a new tab or split, like any other panel). Cards on the board are AI Chat sessions that are parked in the background — you manage many of them from the board while only a few actually stream at once.

The card list

The board is a vertical card list (chosen over a grid, which cropped information and scaled poorly). At the top sits a fixed status rail; below it, cards you can scroll, expand, and reorder.

Status rail

A single fixed line summarizing the whole board:

6 agents · 2 streaming · 1 awaiting approval · total $2.14 · today $0.42

Live count of agents, how many are streaming, and how many await approval.
Running cost total plus a concurrent-streaming warning when many agents run at once (cost governance).

Card anatomy

Each collapsed card shows 3 lines by default — folder, summary, progress — plus a compact toggle that squeezes it to one line for dense boards.

Line	Shows
Header	Status dot · agent name · provider/model · 📁 project folder · mode badge (chat/plan/act × instant/review) · ⏹ stop / ⤢ expand / 📌 stow controls
Summary	Recent-activity summary (or the last user/AI utterance), ChangeSet chip, running cost
Progress	Streaming tail, current tool, and step N/M when a step budget is set

Card states

The status dot reflects the session in real time:

State	Meaning
idle	Nothing running
thinking / streaming / tool	Actively responding, or running a tool
queued	Waiting on a run-queue gate (see below)
awaiting approval	Blocked on an approval card in the unified inbox
error	Last turn failed (e.g. out of credits) — pinned to the top

Sort is by activity, with awaiting-approval and error cards pinned to the top so nothing urgent scrolls out of view.

Collapse ↔ expand

Collapsed (default, 3 lines) — folder, summary, progress, ChangeSet, cost. The compact toggle drops it to one line.
Inline expand (accordion) — click a card to expand it in place: a condensed transcript + streaming tail + approval card + a mini composer. You never leave the list, and multiple cards can be expanded at once for side-by-side comparison.
⤢ Expand to a panel — pull the session out into a real panel (the full “cockpit”) for deep work. It’s the same chat, so nothing diverges.

This is the control tower / cockpit split: the board scans and steers; a full AI Chat panel is for deep work. Both project the same session.

Orchestration graph

Toggle the header [List ⇄ Graph] to switch from the card list to a 🕸 orchestration graph — a hierarchical DAG that draws each agent as a node and each delegation (agent_send) as an edge, with pan and zoom. You see at a glance who handed what to whom and where things are stuck.

Real-time status per node: streaming, waiting, awaiting approval, done.
Flow routing: the path work takes along a relay chain.

Connection visualization

The board makes agent relationships visible so a busy board stays legible.

Edge	Meaning	Color
→ pipe	A’s result handed to B	blue
↩ ref	B references A’s chat	gray
⑃ subchat	A spawned sub-agent B (`ai_subchat`)	purple
⚙ task	A spawned a background task (`task_spawn`)	green
◱ team	Shared note topic / project folder	derived band

Connection lane (left gutter) — a Git-graph-style lane with curved links between cards, colored per edge type, with arrows for direction.
Badges on each card — → pipe: B, C / ↩ refs: A / ⑃ subs: 2. Click to scroll to and highlight the target.
Live flow animation — when a pipe fires, a dot travels the line A→B and the target flashes.
Group bands — cards sharing a folder or team topic get a colored band on the left.
Focus mode — click 🔗 to dim unrelated cards and highlight only a card’s in/out edges.

Team mode

Agents are made peer-aware so they collaborate rather than work blind.

Tool	Role
`agent_send(targetChatId, message)`	Hand work/results to another agent (relay). If the target is busy, it’s delivered automatically after that agent’s turn ends
`agent_create(title, provider?, projectRoot?, mode?)`	Create a role-based teammate; send to it via the returned chatId

Peer-aware prompts — each agent’s system prompt names its teammates, their ownership, and where artifacts live, and tells it to record shared decisions in a team note (workspace_note).
Sequential relay vs. parallel fan-out — dependent work (C needs B’s result) is relayed sequentially; only independent work fans out in parallel. Don’t hand the same file to two agents at once.
Reporting protocol — when an agent finishes delegated work, it reports back to the delegator via agent_send, so the orchestrator can drive the next step.
agent_create limits — new teammates default to Act + Review mode (every change needs your approval); autonomous mode is opt-in. Creation is capped at 5 agents per 15-minute window.
Loop guard — if the same pair keeps bouncing work back and forth, relays are blocked. The guard uses a 15-minute window (per-direction ~3, round-trip ~4, total ~8) to stop infinite relay and cost runaway.

Run queue — parallel, safely

When several agents move at once, conflicts arise. The run queue serializes and coordinates them with gates, so the number “5” is a concurrency limit, not a cap on how many agents you can manage — parked cards cost nothing.

Own-turn gate — waits if the agent itself is already responding or preparing (one turn owner per chat, always).
Provider budget — a concurrency cap per provider; Claude (a process pool, up to 5 LRU with idle cleanup) and Codex (thread-based) are budgeted separately, so their limits don’t steal from each other.
File-conflict guard — same-folder agents run in parallel by default; only when two turns touch the same file does one wait (~90s) to prevent overwrites.
⚡ Parallel toggle — on by default. Turn it off to fall back to strict same-folder serialization.

File isolation — git + ChangeSet

Instead of git worktrees, Blyck isolates file work with turn-boundary git checkpoints + ChangeSet attribution + the run queue’s file-conflict guard.

Each turn is checkpointed (a recovery point); when a board shares one repo, each agent commits separately so changes stay attributable and individually revertible.
Worktrees were deliberately not used: per-card folders are the common pattern (so conflicts only happen within one folder), worktrees are costly on Windows, and they’re structurally impossible on remote SFTP project roots — which is exactly where Blyck’s workbench shines.

Environment isolation

Each agent gets an isolated SSH/DB scope. A remote host or database one agent connected to doesn’t leak into another’s context — preventing accidents during team work. This is the layer competing tools structurally can’t match, because the agents live inside the same workbench as the DB, SSH, and terminal panels.

Unified approval inbox

With multiple agents — several of them parked in the background — approval requests would otherwise pop up in hidden DOM you can’t see. The board gathers them all into one place at the bottom, matching the inline approval-card position.

Compact cards grouped per agent: command preview + reason / working directory + Allow / Deny.
An accordion expands the full command.
Capped to about a third of the screen with internal scroll, so it never buries the session view.

See AI Chat → Tool approval gate for how individual approval cards work.

Board serialization — restore on restart

The board layout, each session’s conversation, and progress are serialized and saved (the same mechanism as named panel layouts). Restart the app and the board comes back intact — cards, conversations, and edges included.

Broadcast composer

A fixed composer at the bottom sends to all, some, or a single agent at once. Attach a shared preamble (common context) and every selected agent receives it, each running through its own run-queue gate and its own approval mode — never a raw parallel launch that bypasses ownership.

Recommended workflow

Give the lead agent the overall goal.
The lead creates role-based teammates with agent_create (or attaches existing sessions).
Fan out independent work in parallel with agent_send; relay dependent work sequentially.
Handle approvals from the unified inbox.
The lead consolidates and verifies artifacts — prefer delegating verification to a peer that didn’t build them.

FAQ

What if agents call each other endlessly? The loop guard detects back-and-forth repetition and fan-out within a 15-minute window and blocks further relays.

What if two agents edit the same file? Same-folder agents run in parallel, but the run queue’s file-conflict guard makes one wait (~90s) when their turns touch the same file, preventing overwrites. Turn off the ⚡ Parallel toggle for strict serialization.

How many agents can run at once? Concurrency is capped per provider (Claude ~5, Codex separately), but you can manage far more — parked cards cost nothing and the run queue waves the rest through as slots free up.

Does the board disappear on restart? No. Board layout, conversations, edges, and progress are serialized and restored.

Why not git worktrees for isolation? Per-card folders make conflicts rare (same-folder only), worktrees are costly on Windows, and they can’t exist on remote SFTP roots. Blyck uses git checkpoints + ChangeSet + the file-conflict guard instead — which also works on remote folders.

Can one agent’s SSH/DB connection affect another? No. Each agent has an isolated environment scope, so a remote host or database doesn’t leak between agents.