Skip to main content

Agent teams

A team here is specified, validated and compiled, not assembled at run time by a model deciding who should help. The specification is checked before anything runs, and what runs is derived from it deterministically.

Four objects​

ObjectWhat it is
SkillAn executable capability, held in the catalog like any other asset
BlueprintAn agent archetype: role, system prompt, model preference, and the skills it requires
BilletA seat on a team: what kind of principal must fill it, its authority cap, whether it is standing or ephemeral, and who it reports to
FormationA team definition: ordered billets, the management tree between them, and one coordination policy

The billet is the idea worth pausing on, because it is what makes a team specifiable in advance.

A billet holds no key material, no entity identifier and no delegation. It is a recruitment specification, not a member. It describes the seat: what capability a principal needs to fill it, the ceiling on the authority that seat may hold, and its position in the management tree. Filling it is a separate act.

The authority contract, enforced at author time​

A formation is validated when it is written and again when it is instantiated, and the checks are the ones that matter:

CheckWhat it prevents
Exactly one leadA team with no apex, or two
The management graph is a treeReporting cycles
Spawn permission and depth budget never increase down the treeA junior seat quietly holding more fan-out than its manager
A child seat's authority cap is a subset of its parent'sA seat that can do things its manager cannot

The last one has a deliberate design choice behind it. Each seat's credential is minted as the intersection of what was requested and what the parent holds, so a seat asking for too much would be silently attenuated into something that cannot do its job, and the failure would surface much later as a confusing refusal mid-run.

So a formation whose child seat asks for more than its manager holds is rejected when it is written. The author finds out immediately, at the point where the mistake is cheap.

Compiling a team into a run​

A formation compiles into an execution graph. The compilation is pure: no I/O, no model calls, same input, same output.

  • Each billet becomes one or more graph nodes: an agent node when the seat acts, a skill node when it invokes one bound capability.
  • The reporting edges become data edges; the lead is wired from the start, and the terminal seats to the end.
  • The coordination policy chooses the expansion. Sequential and manager-delegates produce plain edges. Parallel produces a fan-out with a join. Consensus adds a gate after the join.

Node identifiers are derived, never random, from the billet key. That matters for two reasons: the graph's content hash is deterministic, so the same team compiles to the same identity every time; and the billet is recoverable from the node, so a run can be read back against the team that produced it.

Cycles are a compile-time rejection. "Keep going until it is done" is expressed as a bounded iteration node, never as a loop in the graph, because a graph cycle has no bound and a bounded node does.

Standing and ephemeral members​

A seat is filled one of two ways.

Standing members are durable directory agents, resolved to a real entity when the team is built. They persist across runs and are untouched at teardown.

Ephemeral members start as placeholders. When the lead executes, it spawns children under its own grant, and the minted child is recorded in an overlay keyed by node.

The detail worth noting: the frozen graph's placeholder is never mutated. The binding lives beside the graph, so the graph's content hash, and therefore its replay identity, stays stable while the actual workers change from run to run.

At teardown, ephemeral grants are revoked and the overlay is cleared. Standing members are left alone.

Filling a seat​

Filling a billet is a search before it is a mint. Candidate principals are discovered against the seat's requirements and scored; below a quality floor the system mints a purpose-built agent instead of seating a poor match.

That ordering, recruit then mint, is what stops an estate accumulating a near-duplicate agent for every team that ever needed one.

The spawn gate, inside the lead​

When an ephemeral lead spawns its team, four checks run in order, all fail-closed:

  1. Structural attenuation. Budget fits within the parent, authority axes are a subset, clearance non-increasing, permission mode no more permissive, lineage depth within bound.
  2. Capacity ceiling, derived from the current operating band.
  3. The net-potential-gain gate, on the spawn itself.
  4. A growth screen. A team that grows every time it is asked, without ever consolidating, trips a runaway-growth signal. Growth within the expected step is fine at any size; it is the pattern of always growing that is flagged.

Every admission and every denial is recorded symmetrically on a hash-chained ledger, so "we allowed this" and "we refused this" are equally visible.

Running, resuming and stopping​

A crew run compiles the formation, wires the executors it needs for that run specifically, and drives the workflow runtime.

On restart, a run is restored with graph-hash enforcement: if the formation has been edited since the run started, the resume is refused. A re-wired team cannot silently continue someone else's run under a different program.

Each node executes as its bound member, so the journal entry for a step is signed by the actor that actually did the work rather than by the run's owner.

Skills, resolved through one path​

A skill node resolves through a single sanctioned bridge:

  1. Require the acting agent's identity.
  2. Resolve the skill definition from the catalog, enforce visibility scope, and require it to be active.
  3. Resolve the binding to this agent, and require it to be enabled.
  4. Merge configuration, with the binding winning over the definition.
  5. Dispatch by skill type, and record the invocation.

Definition and binding are separate on purpose: a published, vetted skill existing in the catalog is not the same statement as this agent may use it.

External tools reached over an outbound connector are projected into the same catalog as skills, so a team requires a remote tool exactly the way it requires a local one. There is no second binding mechanism.