Introducing Tower

Mission control for AI agent squads — what Tower is and how the loop works.

Fabric Tower is mission control for squads of AI agents, built as a fabric family vertical. A squad of named specialist agents does the work; Tower is where humans watch, steer, and approve all of it.

Harness builds the agents. Experiments judges them. Runway ships and governs them. Platform keeps everyone honest. Tower is where humans watch, steer, and approve all of it.

The loop

Every unit of work follows the same governed loop:

flowchart LR
    ASK --> TRIAGE --> PLAN --> EXECUTE --> REVIEW --> REPORT
  • Ask — an operator question, a cron heartbeat, or a webhook enters as tower.ask.
  • Triage / plan — the lead agent decomposes the ask into a mission.
  • Execute — specialist agents run tasks. In-workspace work runs autonomously.
  • Review — anything leaving the workspace stops at a ticket: a one-tap human approval enforced by tower.ticket_required.v1, not by a prompt.
  • Report — the deliverable lands with a full runs-ledger entry.

There is no side door: agent decisions, human approvals, cron triggers, and webhooks all enter through Actor → Action → Policy → State Machine → Handler → Adapter → Event → Projection.

Phase 1 — real squad online

Tower ships the governed mission loop, agent registration and messaging, mission and ticket state machines, the durable missionWorkflow, and the missions, squad, runs, and ticket console surfaces. Local work can remain vendor-free against InMemoryTowerStore; production composition uses shared Postgres/Lakebase state, Temporal, and a bounded model through Unity AI Gateway. A failed model call falls back to the offline specialist rather than crashing an active mission.

See ~/techfabric/mission-control-on-fabric-architecture.md for the full architecture and phasing.

On this page