Boards & Zones

Boards are 2D spatial canvases for organizing worktrees. Like Figma for AI coding work — drag, group, comment, collaborate in real time.

Instead of linear lists or kanban columns, every worktree lives at an (x, y) coordinate on a board. Sessions appear as a genealogy tree on the worktree card. Multiple users see the same canvas with live cursors.

An Agor board with custom-styled zones forming a pipeline. Each worktree card shows its session tree, env tabs, and PR badge — and the floating PiP preview shows a session live-streaming as it works.

Why spatial?

Your brain remembers space. You remember:

• “The auth worktree is in the top-left corner.”
• “Testing sessions cluster on the right.”
• “That failed experiment is way down there.”

This is location-based memory — the same reason you remember where you parked but forget a shopping list. A 2D board gives every worktree and session a place. Linear lists discard that.

Like Figma did for design, Agor brings spatial collaboration to AI coding:

• Everyone sees the same board.
• Real-time cursors show where teammates are working.
• Drag a worktree, teammates see it move instantly.

See Multiplayer & Social for the full collaboration story (cursors, facepile, comments, attention pulse).

Zones

A zone is a spatial region on a board that triggers a templated prompt when a worktree is dropped into it.

Drag a worktree into “Code Review” → auto-prompts the agent for review. Drag into “Needs Tests” → auto-prompts for test generation. Drag into “Ship It” → auto-prompts for changelog + PR description.

Zones turn your board into a workflow engine. Spatial position means something — it triggers behavior.

How zone triggers work

When you drop a worktree into a zone:

1. Session selection — which session gets the prompt?

   • Always create new session (default) — clean slate for the zone’s task
   • Let me pick — choose which session in the tree has the right context
   • Most recently active — usually the session you were just working in

2. Templated prompt executes — the zone’s Handlebars template renders with dynamic data from the worktree, board, repo, and environment.

Handlebars template variables

Zone prompts have access to:

• Worktree — {{ worktree.name }}, {{ worktree.issue_url }}, {{ worktree.pull_request_url }}, {{ worktree.unique_id }}
• Board — {{ board.name }}, {{ board.description }}
• Session — {{ session.title }}, {{ session.description }}
• Environment — {{ environment.url }}, {{ environment.status }}
• Repo — {{ repo.name }}, {{ repo.default_branch }}

Example zone prompt

Review the implementation of {{ worktree.issue_url }}.

Check if:
1. All acceptance criteria from the issue are met
2. Edge cases are handled
3. Error messages are user-friendly

If approved, comment on {{ worktree.pull_request_url }} with summary.

Drop a worktree → auto-prompts with issue and PR links pre-filled. No copy-paste, no forgetting which ticket this was for.

The zone trigger modal — pick an action, override session config, and edit the templated prompt before firing.

Kanban-style flows

The classic pattern: chain zones into a pipeline.

[ Triage ]  →  [ Analyze ]  →  [ Build ]  →  [ Review ]  →  [ Ship ]
   issue          plan           code        cross-agent      PR + notes
                                              review

Each zone has a different prompt template. Drag a worktree across the board and it walks through the workflow, picking up context at every step.

You can also build asymmetric pipelines: a “Stuck” zone that escalates to a different model, a “Spawn 5 reviewers” zone that fans out to multiple agents, a “Generate tests” zone wired to a Codex template.

Multiple boards, one workspace

A workspace can have many boards — one per team, one per project, one per long-running initiative. Boards are independent canvases with their own worktrees, zones, and members.

Common patterns:

• Per-project boards — One board per major product, each with its own zones and team.
• Per-pipeline boards — A “PR review” board, a “Bug triage” board, a “Roadmap” board.
• Solo vs team boards — Personal scratch board for experiments, team board for shipped work.

Cards (Beta)

Worktrees aren’t the only thing that can live on a board. Cards are generic workflow entities — support tickets, sales leads, content pieces — that an assistant creates and manages via MCP. Same spatial canvas, same zones, same multiplayer presence — just not git-bound.

Related

• Worktrees — The primary primitive that lives on boards
• Sessions & Trees — The genealogy rendered on each worktree card
• Multiplayer & Social — Cursors, facepile, comments
• Cards — Non-worktree entities on boards
• Assistants — Agents that orchestrate worktrees and zones