Squads

A squad (/api/squads) is a team of agents plus a pipeline of tasks and an execution strategy. Use a squad when a job is too large or nuanced for a single agent — each member has a role, tasks are assigned and ordered, and everyone shares a blackboard to pass results. To build one hands-on, see Build a squad.

Configuration

A squad is created with POST /squads (body wrapped in data, like all Strapi resources). These are the fields that shape execution:

Field	Type	Notes
`name`	string · required	Human-readable name.
`slug`	string	Auto-generated, unique; used nowhere in kickoff (kick off by numeric `id`).
`description`	text	Optional.
`process`	`sequential` \| `hierarchical`	Execution strategy. Default `sequential`.
`manager_agent`	relation → agent	Required for `hierarchical`; ignored for `sequential`.
`agents`	JSON array	Squad members — `{ "agent_slug", "role" }` per entry.
`tasks`	JSON array	The task pipeline (see below).
`max_total_iterations`	integer	Global budget across all tasks. Default 30.
`active`	boolean	Default `true`. Inactive squads can't be kicked off.

The `tasks` pipeline

Each task is one JSON object. The platform validates the pipeline — duplicate IDs, dependencies on unknown tasks, circular dependencies, and assignments to non-member agents are rejected before a run.

Field	Required	Meaning
`id`	yes	Unique task ID, e.g. `"research"`.
`description`	yes	What the assigned agent should accomplish. Supports `{{context}}`.
`agent_slug`	yes	Which squad member runs this task. Must be in `agents[]`.
`depends_on`	no	Array of upstream task IDs. Omit (or `[]`) for a root task.
`output_key`	no	Blackboard key the result is written under. Defaults to the task `id`.
`expected_output`	no	Guidance appended to the agent's goal to shape the answer.

A task's per-agent iteration cap is the smaller of the agent's own max_iterations and the squad's remaining max_total_iterations budget — so a long pipeline can exhaust the budget and later tasks are skipped (see Build a squad → Troubleshooting).

The blackboard

The blackboard is shared state. Each task writes its result to a named output_key; downstream tasks read only from the keys their depends_on produced (unrelated parallel branches stay isolated). Root tasks receive the raw user inputs. Agents build on each other's work without talking directly.

The kickoff inputs are seeded onto the blackboard first under their own keys (task ID _input, agent _system), so a root task whose description references {{context}} resolves against the user's query.

Audit trail

Every write is appended to an audit trail — one entry per write, in order:

"audit_trail": [
  { "task_id": "_input",  "agent_slug": "_system",    "key": "topic",    "timestamp": 1710859200.12 },
  { "task_id": "research", "agent_slug": "researcher", "key": "research", "timestamp": 1710859231.74 },
  { "task_id": "write",    "agent_slug": "writer",     "key": "draft",    "timestamp": 1710859258.30 },
  { "task_id": "edit",     "agent_slug": "editor",     "key": "final",    "timestamp": 1710859275.91 }
]

The matching blackboard snapshot is the final value of every key:

"blackboard": {
  "topic": "AI in healthcare",
  "research": "Key findings: …",
  "draft": "A first-draft report …",
  "final": "A polished report …"
}

timestamp is epoch seconds. Together these give full traceability of who produced what, under which key, and when.

Sequential vs hierarchical

	Sequential	Hierarchical
Order	Fixed — tasks topologically sorted by `depends_on`	Decided at runtime by a manager agent
Who drives	The platform, task by task	The `manager_agent` via a `delegate` tool
Needs	`tasks[]` with dependencies	`manager_agent` + `agents[]` (tasks are hints)
`final_output`	Concatenation of each task's answer	The manager's synthesized answer
Best for	Predictable pipelines: research → write → review	Dynamic work where order can't be fixed up front

Pick sequential when you can draw the dependency graph yourself — it's deterministic, cheaper, and each step is independently auditable. Pick hierarchical when the work is exploratory and the right order depends on intermediate findings.

How each executes

Sequential — tasks are topologically sorted, then run one at a time. Each task gets the blackboard summary of its depends_on keys, runs its agent, and writes the answer to its output_key. final_output concatenates the per-task answers.
Hierarchical — the manager_agent is given the member list and the task descriptions, plus a delegate tool. It calls delegate(agent_slug, …) to dispatch work in whatever order it reasons is best, then synthesizes the results. task_results reports a single manager entry.

Both strategies share the same max_total_iterations budget (default 30) — a guardrail against runaway delegation or a stuck pipeline.

Reference

Full schema and endpoints: Squad API. Member agents: Agents. To build one hands-on, see Build a squad.