TOWER

The control tower for coding agents

Turn “make it work” into merged. Delegate the building. Keep the discipline.

Tower runs pi coding-agent sessions across all your projects from one board — the whole life cycle, idea to merged. Hand it an idea and it scaffolds the project from an engineering archetype. Hand it a question and research maps the unknowns before a plan exists. Then a strong model plans against a living model of your system, a cheap one builds in its own worktree, gates you write in a sentence decide what is worth testing, and reviewers who never saw the work try to break it — while the system model itself keeps learning: every finished card proposes what it discovered, and you confirm what the graph keeps. The agents fly; you work the tower: every decision that is yours lands on one amber row, one click each.

pi install git:github.com/rahult/tower

Then type /tower in any pi session. The board opens at 127.0.0.1:4700.

Live from the tower: what needs you is amber, and this simulation answers itself.

Needs you these decisions block an agent

    In flight agents at work; step in only if you must

      Landed today

        Fig.01 — The stream The Tower board. A projects rail lists repositories with amber and indigo counts. The stream holds four amber rows under Needs you — two review approvals with Approve & merge buttons, a plan approval, and a card asking three questions — above In flight, where a building and a planning row carry progress bars and Abort buttons. A docked inspector shows the open card's Decision tab: three questions with options, two marked Suggested, and a Send answers and continue button.
        The board opens on this: a rail of projects, a stream where amber means you, and an inspector docked beside it. The questions came from the agent mid-plan; the suggested answers are one click each.

        Retired

        The toolchain it replaces

        The software life cycle used to be a dozen tabs: a tracker for the work, a board for the status, a queue for the tests, a rota for review, a dashboard for CI. Tower collapses that pipeline — the agents do the stages, the board does the chasing, and your test suite stays the judge.

        Ticket tracker and sprint board
        The queue. Cards carry a brief, a branch and a spend ceiling; global and per-project caps decide what runs.
        Planning meetings
        A planner that models the work before writing a step — domains, actors, invariants — and asks you the questions only you can answer.
        Scaffolding by hand
        “Create a todo app” becomes a project: pick an archetype — web app, CLI tool, JSON API — and Tower lays down the toolchain, the tests and the acceptance harness, then files your idea as the first card. Card one plans the app, not the toolchain.
        The codebase briefing
        A read-only pass maps an existing repository — domains, actors, state, invariants as built, with sources — into a system model the planner starts from, not guesswork. And it no longer goes stale: finished cards propose what they learned — a gotcha, a new coupling, a failure mode — as changes to the model's memory graph. You confirm each proposal; the doc the planner reads is a projection of the graph, so it can never drift from what the work actually found.
        Spec-to-tickets grooming
        Paste a plan — or point at a card's — and a work-breakdown agent cuts it into self-contained backlog cards. You pick the ones you want; Tower files them in order. A spec becomes a night's queue.
        Branch handoffs
        A git worktree per card. Two cards build in one project at once; your checkout is never touched. Dependent work branches from another card's branch and lands in order.
        The test cycle
        Your verify command judges every build. A failure goes back to a builder with the output; the same failure twice is information, not a third blind retry.
        The review rota
        An adversarial review and a SOLID design review in fresh sessions with no edit access — run at once when you opt in, since they never see each other anyway. Findings wait for you beside the diff.
        CI you write in a sentence
        Flows compose agents and shell gates — a lint command, a size check, a reviewer role — and attach them to the plan, the build or the tests, or fire on an interval. A failed gate sends its own output back to the builder; no model decides whether your checks passed.
        The spike, before the plan
        A deep-research flow maps an unfamiliar question with sources fetched over the network and writes a cited brief — options, trade-offs, what it means for this repository. It runs on a backlog card, and the planner reads the brief.
        Watching CI
        Tower watches the pull request it opened. Failing CI goes back to a builder on its own; a merge settles the card.
        The standup
        The stream is the status: Needs you, In flight, Queued, Landed today — with tokens and cost counted in the strip above.
        Fig.02 — The decision A card's Decision tab over the stream. A red banner reads 1 review found something blocking; the checks line reads Clear, and the adversarial review is marked Blocking with one finding — Retries are not capped on a non-idempotent request — with severity blocking and the file and line. Below it, a feedback box and the buttons Approve and merge locally and Send back to the builder.
        Review findings wait with the diff, severity and file. Approving past a blocking finding is a decision the panel records, not a slip — and Tower merges: locally when the repository has no remote, by pull request when it has one.
        Fig.03 — The brief A backlog card's inspector, Files tab, showing a research brief rendered as Markdown: a TL;DR comparing a CRDT, event-sourced sync and last-write-wins for a notes app, a recommendation, and a Sources list. The card still rests in the backlog — Idle, no worktree — with a Delete button beside it.
        Research happens before the lifecycle, on the backlog card itself: a survey fetched the evidence, a synthesizer wrote the cited brief, and both wait in the card's files for the planner — and for you.

        Flight plan

        How a card moves

        Tell Tower what you want done — or just tell it the idea. From there the card drives itself through the stages and stops twice, both times for you.

        1. An idea becomes a project

          On an empty board, create a habit tracker in the command box — or open New from idea and pick an archetype: a web app, a CLI tool, a JSON API. The archetype is a versioned engineering baseline — layout, toolchain, tests, acceptance harness — and Tower scaffolds it into a fresh repository, files your idea as card one, and starts planning. The practices ship with the scaffold; archetypes can turn the acceptance gates on from birth.

        2. Unknown ground gets researched first

          Not every card starts with a task; some start with a question. An exploring line in the command box — research local-first sync @notes — files the card and runs the deep-research flow on it, right where it rests in the backlog: a survey fetches evidence over the network (docs, repositories, package registries), and a synthesizer writes a cited brief — options with trade-offs, a recommendation, what it means for this codebase. Nothing starts until you say so.

        3. A strong model plans, grounded in the system

          The planner explores your repository and writes plan.md. A research brief on the card is read first — its recommendation is context, not command. So is the project's system model: a living memory of the codebase as built — domains, actors, state, invariants with sources — that finished cards keep current and that is rebuilt before planning whenever it goes stale and the project asks. The constraints you wrote on the project bind: they reach the builder, the reviewer and the coach. It changes nothing. Planning defaults to anthropic/claude-fable-5-1, because a wrong plan is the costliest mistake a cheap builder can inherit.

        4. You approve, with advice beside the decision

          The card turns amber in Needs you. A rubric pass runs beside the verdict — what the plan leaves unanswered: behavior, contract, failure modes, verification — as advice you can pin as a margin note or ignore; it never approves for you. Pin notes on the plan itself: they highlight inline, a rejection always carries them, and open ones ride along with every stage until resolved. If the planner hit a decision that is yours, it asks first — with suggested answers you can click. And if the plan is really a quarter's work, cut it into a queue of backlog cards in one click and file the ones you want.

        5. A cheap model builds from the plan alone

          Building is a fresh pi session that sees the plan and nothing of the planner's conversation. It works in the card's own git worktree and commits on the card's branch — or on top of another card's branch when the work depends on unmerged land. The drawer meters the card's spend against its budget while it runs, and the pipeline pauses for you at the line. When the plan splits cleanly — and only then — the planner says so, and a crew takes over: scouts answer open questions in parallel, each stream is built by its own agent in its own worktree, and an integrator merges the branches before your tests run.

        6. Gates and tests decide, not opinions

          Before testing runs, the gates you declared run: flows attach shell commands to the plan, the build or the tests — pnpm lint, a size budget, a security skill — mixed freely with agent steps. A gate that fails stops the card with its own output, and a retry hands that output to a fresh builder; no model decides whether your checks passed. With acceptance gates on, the lifecycle turns test-first: the plan ends with test targets, a red harness proves they fail, the builder inherits them as a contract it may not weaken, and the green gate only passes when every spec does — an empty harness never counts as a pass, and a card with no behavior can declare the red gate not applicable, deterministically. Then Tower runs the project's verify command, reads its exit code, and a failure goes to a fresh builder with the output; the same failure twice stops the loop and asks for you.

        7. Reviewers who never saw the work

          Review flows run in fresh sessions with no edit access: an adversarial review that tries to break the change, and a SOLID design review — at the same time, when you opt in, because reviewers who never see each other are order-blind anyway. A reviewer that hits a question stops and asks it, answerable like any stage's. On demand, any resting card can also run an invariant simulation — the plan's model, reasoned through scenarios before your tests catch what it missed.

        8. You approve; it lands

          Approve from the row. With an origin remote, Tower opens the pull request with gh and watches it: failing CI goes back to a builder, a merge finishes the card. Without one, Tower merges the card's branch into your default branch itself — after checking your checkout is clean — and the card settles, quietly, into Landed today. Done cards delete from the board when you are done reading them.

        9. The card remembers what it learned

          A card's discoveries used to evaporate when it closed. Now the builder files what it learned — a gotcha it hit, coupling only visible under change, a failure mode it provoked, an invariant the code actually enforces — as a structured proposal with its evidence: file and line, test output. Nothing enters the graph on the agent's word: each proposal waits in the project's Memory for you, one Accept or Reject each. Confirmed changes join the graph with their provenance, and the system model the next planner reads is re-rendered from the graph — derived, never hand-edited, so it cannot drift. A proposal the evidence doesn't support is refused, not invented: the graph stays honest even when a model is not.

        Fig.04 — The memory A project's settings, scrolled to the Memory section. The line reads 10 nodes, 0 edges — 2 proposals waiting. Two proposals from a finished card sit with their evidence: Add flow: Toggle command (src/cli.js:6 adds the toggle branch to run()) and Add entity: Todo done state (src/store.js:16 mutates todo.done in place — subscribers see the same object change), each with Accept and Reject buttons.
        The system model is a living memory graph. A finished card proposed what it learned; each proposal carries its evidence and waits for your word — nothing enters the graph without it, and the model the next planner reads is re-rendered from what you confirmed.
        Fig.05 — The coached gate A card at its plan gate. The inspector shows the plan-coach report — What the plan doesn't answer — with numbered findings, the first highlighted and underlined where a margin note was pinned. The rail note reads: 1 open note — pinned to the plan and sent with a rejection until you resolve them. Buttons: Approve plan and build, Send back to planner.
        The plan gate, coached: a rubric pass lists what the plan leaves unanswered, as advice — it never approves for you. Select text to pin a margin note; the note rides back to the agents until you resolve it.
        Fig.06 — The crew rail A running card in the docked inspector, Session tab. The sessions rail reads planning, crew, scout auth shape, builder… — the crew that built it, each session with its own model and verdict. The planning transcript is selected, showing Plan and streams ready.
        Every session streams to the board — and a card built by a crew keeps the whole crew in its rail: planning, scouts, stream builders, integrator, then your checks and the reviews. Steer a live run mid-flight, or read the diff under Changes.
        Fig.07 — The gate A card's Session tab with the change-audit run selected: the summary shows the shell command git log -1 --stat --oneline piped to tail -4, a green pass chip, and the words Recorded, exit 0 — informational, it never fails the flow, with the command's output below.
        Gates you write in a sentence run inside the lifecycle, between the build and the tests. This one records the shape of every build; a lint or size gate would stop the card and send its own output back to the builder.
        Fig.08 — Modeling, on demand An invariant simulation run on a resting backlog card. The sessions rail shows the simulation run; the verdict line reads pass, Nothing blocking, with the model and token count above.
        Any resting card can run an invariant simulation — domains, actors, scenarios — and report what would break before your tests do.

        Systems

        What it takes care of

        Attention, not alarms
        Everything that needs you gathers in one amber group, ordered by what blocks an agent. Answer in place, or open the card for the whole story. Away from the tab? One bell per card, a badge in the title, and the favicon wears the count.
        Keyboard-first
        j/k walk the cards, a approves the open one, / or ⌘K opens the command box, n adds work, ⌘1–4 switch views. The ordinary path never needs the mouse; the footer keeps the keys written down.
        From idea to project
        Describe the app, pick an archetype — web app, CLI tool, JSON API — and Tower scaffolds the baseline into a new repository, files the idea as the first card and starts planning. The command box understands “create a…” on an empty board.
        It reads the system first
        A read-only pass maps an existing codebase — domains, actors, state, invariants as built, with sources — into a system model the planner reads. The editor shows fresh or stale; when it is stale and the project asks, Tower rebuilds it before planning.
        A memory that outlives the card
        The system model is a living graph, and finished cards write to it: each proposes what it learned — gotchas, coupling, failure modes — with evidence, as pending changes you confirm one by one. The model the next planner reads is a projection of the graph, so the docs never drift from the work.
        Test-first, enforced
        Acceptance gates turn a card TDD: test targets at the end of the plan, a red harness before the build, a green gate after it. The builder inherits the specs as a contract it may not weaken, and an empty harness never counts as a pass.
        A budget on every card
        Set a spend ceiling per card; the drawer meters cost while the card runs and the pipeline pauses for you at the line. Card-less sessions — the ask box, command drafts, model checks — cost money too, and Usage counts them.
        Notes that ride back
        Select text on the plan, a review or any card file and pin a margin note. Notes highlight inline, a gate rejection always carries the open ones, and they enter every stage prompt until you resolve them.
        No dead ends
        Every state in the card machine has a way out — retry, answer, approve, delete, resume — proven by a reachability walk over the machine, not by hope. A finished card deletes from the board without database surgery.
        Cards that stack
        A card can branch from another card's branch, so dependent work builds before the base lands and merges cleanly after — a queue that respects its own order.
        Scheduled agents
        A flow can fire itself on a carrier card, on an interval — nightly drift checks, dependency audits, cost reports — the same pipeline, on a clock.
        It checks its own plumbing
        Before real work hangs on a model, Tower probes each configured stage's model. A preview URL is proven to be serving this app by a check command, not asserted. A busy port fails fast instead of haunting the run.
        No remote? It still lands
        A repository without an origin never sees a pull request: approved work merges straight into the default branch, guarded against a dirty checkout, and the card settles as merged locally.
        Parallel, when the plan allows it
        A plan that splits into independent streams is built by a crew of sub-agents: scouts research the open questions first, each stream gets its own agent and worktree, and an integrator merges the branches so testing still judges one change. The reviews fan out the same way, on a per-project toggle.
        Flows, not plugins
        Your agents are JSON files in ~/.tower/flows/: a step can be a prompt file, a pi skill, one of your agent roles — or a shell command whose exit code is the verdict. Declare when — manual, after the plan, after the build, after tests, on a schedule — and the lifecycle runs them there.
        A fresh session per stage
        Stages hand off through files such as plan.md, never through a shared conversation. The builder starts with a clean context, and a reviewer never inherits the author's reasoning.
        Questions, not guesses
        An agent that hits a decision that is yours stops and asks, with options you answer by clicking — and so does a reviewer, now. Its session continues with your answers, so nothing it learned is thrown away.
        Modeled before it is built
        Planning derives the domains, the actors and the invariants — what must hold when the work is done. Testing answers each invariant with a verdict, and a full simulation runs on demand from any resting card's Run tab. Off per project, if you prefer.
        Where the tokens go
        The strip counts running pips, tokens and cost today, live. Usage breaks every session out by day, project, model and card — including the card-less ones, and failed runs keep their spend.
        A queue that survives restarts
        Global and per-project caps decide how much runs at once. The queue is stored; sessions cut off by a restart resume where they stopped.
        Locked-down sessions
        pi has no tool-approval step, so stages start with --no-extensions and without project trust. Both are opt-in per project.
        Fig.09 — The project's settings, one page A project's editor modal: toggles for running the reviews at the same time, invariant simulation and parallel sub-agents; a System model section reading Fresh, built 9/26/2026 with a Rebuild the model button; Understand before plan; and Acceptance gates — test-first, enforced.
        Each project carries its own judgement calls: whether reviews fan out, whether planning rebuilds a stale system model first, whether cards are gated test-first. An agent drafts the verify, test, setup and preview commands if you ask.
        Fig.10 — From an idea The New from idea dialog. It explains: the archetype is the engineering baseline — layout, toolchain, tests, acceptance harness; your idea becomes the first card. Fields for a name, the idea, and an archetype select showing Web app with its description. A Scaffold and plan button.
        New projects start from an idea and an archetype, not a blank repository: web app, CLI tool or JSON API today. Tower scaffolds the baseline, files the idea as card one, and planning begins.
        Fig.11 — The command box The command box open over the board. A typed line — research offline-first sync for remembero — matches an ASK TOWER action: an agent reads this and acts. Keyboard hints line the bottom: arrows move, enter runs, j/k cards, a approve, n add.
        One box reaches everything: add work, jump to a card, filter, theme — and anything that reads like a question goes to an agent that files the card and starts the right flow. An @tag names the project.
        Fig.12 — The matrix The Board view: a matrix with a column per stage from Backlog to Pull request and a row per project. Amber-tinted mini cards mark where work needs you — plan approvals, questions, review work — while the rest stay quiet, and each lane reads main · merges locally.
        Prefer the whole picture? The matrix keeps a column per stage and a row per project, with foldable columns and done folded away until you want it.
        Fig.13 — The ledger The Usage view: stat cards for tokens and sessions today and all time, a by-day bar, and tables breaking spend down by project, model and costliest card.
        Where the money goes, counted to the cent: by day, by project, by model, by card — the ask box and every card-less session included.

        Pre-flight

        Install

        You need pi, git, npm and Node 22.18 or newer.

        pi install git:github.com/rahult/tower

        Start pi from a shell that has your provider API keys, then type /tower. The first run builds the board, starts Tower in the background and opens it at 127.0.0.1:4700. Tower keeps running after you quit pi.

        /tower Start Tower if needed and open the board
        /tower add <title> Add a card for the repository you are in. It becomes a project the first time
        /tower run <title> Add a card and start planning it
        /tower status What is running, and what is waiting for you
        /tower settings Show or change which model runs each stage
        /tower update Fast-forward the install, rebuild the board, and say what needs a restart
        /tower rebuild-ui Rebuild the board after pulling updates — no daemon restart needed
        /tower restart Stop and start the daemon — the update that changes daemon code
        /tower stop Stop Tower. Running sessions can be resumed next time

        pi packages run with full access to your machine, and Tower runs agents that execute shell commands in your repositories. Read the source before you install it.

        Yours to change

        The opinions are yours to change

        Four small functions hold Tower's judgement calls. Each ships with a deliberately plain default and a comment that lays out the trade-off. The concurrency caps are enforced outside them, so a policy can only choose among cards that are allowed to start. 

        // packages/core/src/policy/scheduler.ts
// Keep every lane moving, or finish what is started?
export function pickNext(candidates, state) {
  const [first] = [...candidates].sort((a, b) => a.queuedAt - b.queuedAt);
  return first?.cardId ?? null;
}
        requiredGates
        When may a small plan skip your approval?
        decideAfterFailure
        Stop early when the same error repeats? How much output does the builder get?
        pickNext
        Which waiting card gets the next free slot?
        pickModel
        Move to a stronger model after a failed build?

        Logbook

        Where it stands

        Tower is early, and complete from idea to merged. Three archetypes scaffold new projects from one line; a system-model pass grounds planning in the codebase as built — and it is now a living memory: finished cards propose what they learned, gotchas, coupling, failure modes, as pending changes you confirm one by one, and the model the next planner reads is re-rendered from the graph, never hand-edited. Acceptance gates make a card test-first; six opt-in workflows cover the road from idea to production — research, a coached plan, a threat model, reviews, a production bar, a dependency watch — and flows are state machines you can draw on a canvas. Deep research runs on the backlog before any of it. The pipeline itself: planning, the plan gate with its coach and margin notes, building — single-session, a parallel crew, or stacked on another card — testing with the retry loop and your own deterministic gates, adversarial and SOLID reviews that fan out in parallel, the feedback gate, a spend budget that stops the line, and two ways to land: pull requests with CI repair, or a local merge when there is no remote. Plans cut into queues of cards; schedules fire flows on a clock; model checks and honest previews keep the plumbing true; a reachability walk proves the card machine has no stuck states. Tests run the whole daemon end to end — and the discipline thesis was measured three ways, not argued: on a free-tier model Tower's pipeline amplified the builder's failures and shipped nothing, while stock pi worked; on paid coding models the pipeline won the deliverable on most tasks — documented, review-screened, tested — and an independent third-party judge agreed on three of four head-to-heads, all of it in benchmarks/se-bench with the full verdict, per-task cost ledger, and every incident on record. What the measuring exposed is now built in: the merge refuses empty branches and uncommitted work, stalled flows abort themselves, reviews probe encapsulation, mutation atomicity and over-strictness, build prompts carry DFMA design constraints (fewest parts, no duplicated logic paths), planners may not forbid documentation the brief left open, and every run shows its cost with the provider-cache savings beside it — the whole three-model benchmark, judges included, cost $2.55. The charts and per-task tables live on the benchmark page. Cards can now be archived off the board and brought back; pi's environment discovery is a per-project opt-in; and review fan-out runs in parallel. Planning, building, testing and questions have been run against real pi sessions.

        Not yet proven against the real thing: the pull request stage has only met a stand-in for GitHub. Expect rough edges there, and say so when you find one. The design is in the repository.