Council
Four synthesis oracles frame the mission and challenge assumptions before work fans out.
How it works
A real chain of command
for AI agents.
FORCE takes work that would normally live inside one context window and turns it into a visible 44-agent triad with delegation, execution, oversight, and memory.
Five tiers
44 agents, one triad.
The main production fleet is triangular: council at the top, APEX in the middle, three squadrons below it, and worker triads at the edge. That default is real, but the fleet geometry itself is configurable.
APEX
A single fleet admiral delegates work, tracks status, and adapts the mission in motion.
Squadrons
Three squadron leaders own the main workstreams inside the production triad.
Teams
Nine team leads manage narrower slices of work and keep handoffs structured.
Workers
Twenty-seven workers execute, test, search, edit, and report back through the same chain.
Execution loop
Work enters once, then the fleet takes over.
The key difference is not simply that many agents exist. It is that work decomposes through a persistent command structure with visible handoffs and rollups.
Intent enters at the top
Requests arrive into a command structure instead of a flat prompt queue. The work is framed before it is expanded.
The hierarchy fans out
APEX and the three squadron leads decompose the mission into teams and concurrent worker tasks that can move simultaneously.
Independent lanes cross-check each other
Different providers, local models, and specialist roles can be assigned into the fleet so verification is structural rather than dependent on one vendor.
Progress rolls back up
Results, blockers, and evidence move back through the hierarchy so the operator sees real-time status instead of partial fragments.
Production geometry
The main fleet is a triad, not a limit.
The production fleet is not a generic cloud of agents. It is a 3-squadron structure today, but the important thing is that the hierarchy can be reshaped around the mission rather than locked to one static array.
Production default
The main fleet currently runs as a 44-agent triad because it is the cleanest production geometry for how FORCE operates today.
YAML fleet design
Squadron count, team depth, worker lanes, specialist droids, and provider mix are defined in configuration rather than frozen in code.
Mission-specific arrays
You can run lean councils, deep build fleets, domain-specific squadrons, or specialist formations depending on mission, hardware, and cost envelope.
Operator surface
The UI is not a sidecar.
The FORCE surface exposes the hierarchy itself: live terminals, delegation state, current tools, progress, and the ability to inspect what is happening while the fleet runs.
Each pane is an actual running agent with its own working context and task progression.
The left rail exposes the chain of command so execution is always visible in organizational terms.
Read, edit, execute, todos, reports, and coordination all appear as part of the working surface.
Completion state and active work are visible at the team and worker levels rather than hidden in logs.
Runtime depth
What keeps the hierarchy coherent.
A hierarchy only matters if the runtime underneath it can preserve context, route work, expose operations, and survive real execution pressure.
Shared fleet memory
Context survives across sessions and projects, so the system can continue longer-running work without resetting to zero.
Message bus and typed routing
The runtime coordinates directives, reports, and peer messages as structured traffic rather than ad hoc text alone.
Tool gateway
Agents can search, read, edit, validate, and inspect through structured tools instead of pretending everything fits in one completion.
Replayable operations
When the fleet needs to be inspected or explained, work can be traced and replayed because the runtime keeps a coherent record.