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.