Introducing Tower

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. Squads may combine Fabric Harness agents, Databricks-native agents, Hermes, OpenClaw, and customer-managed HTTP runtimes.

Harness is the recommended way to build portable Fabric agents, but Tower is provider-neutral. 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, provider-neutral 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.

The Squad console can enroll:

• TechFabric Harness agents running in-process, behind HTTP, or as Databricks resources
• Native Databricks Jobs, Model Serving endpoints, Agent Bricks, and Genie spaces
• Gateway-hosted Hermes agents
• OpenClaw WebSocket gateways
• Custom HTTP runtimes that implement tower.agent-task.v1

Enrollment stores provider, transport, resource identity, skills, capabilities, and an optional opaque credential reference. It never accepts a raw token, password, or API key. Registration is governed by tower.register_agent and does not grant approval rights; external effects continue to stop at tower.ticket_required.v1.

Enrollment and activation are separate. Remote and external agents appear as pending activation, and Tower refuses to route tasks to them until the matching provider adapter passes compatibility and health checks. It never silently executes an external assignment through the Harness fallback.

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