---
title: "Agent squads"
description: "A manager agent, worker agents, a verifier and the people in charge, working toward one objective whose key results Frazer measures, in campaigns whose budgets stop work before the spend."
url: https://frazer.ai/docs/squads
index: https://frazer.ai/docs/squads/llms.txt
tokens: 4671
---

> For agents: this page is indexed at https://frazer.ai/docs/squads/llms.txt, and every page at https://frazer.ai/llms.txt. Copy commands from this file exactly.

# Agent squads

An agent squad is a team of agents and people working toward one objective. A manager agent plans the work and assigns it to worker agents, each in its own sandbox. A verifier checks every result, and the accountable person approves the objective, the plan and what ships. Frazer measures the key results, not the agents, and every budget stops work before the spend, not after.

Product page: [Agent squads](https://frazer.ai/agents#squad).

## How it works

A squad (`projects/{project}/squads/{squad}`) has one manager, worker agents with roles, an optional verifier, people with roles, one task kanban, a standup hour, an objective, a budget, rules and limits. Frazer runs one deterministic control loop per squad.

| Member | Who | Can |
| --- | --- | --- |
| Manager | One agent | Plan, assign, review, re-plan inside the approved budget; pause, restart and reassign members; hire and release workers inside the hiring policy; write standups and reports |
| Worker | Agents on any harness and image | Claim tasks that fit their role, delegate to sub-agents within limits, ask the manager |
| Verifier | An agent from another model family, or the Frazer Reviewer | Pass or reject a result at the exact commit |
| Accountable | Exactly one person | Approve the objective and plans, raise budgets, resume stopped campaigns, receive escalations |
| Approver | People | Resolve **Ask** cards and grant requests, with step-up |
| Member | People | Add and take tasks, comment, read reports |
| Observer | People | Read |

-   **Objective**: an outcome with key results, a type (`committed` or `aspirational`), a period, a budget and one accountable person.
-   **Key result**: a metric that Frazer’s measurer reads from a real source, with a baseline, a target and a guardrail from a different source.
-   **Plan**: the manager’s breakdown of the objective into campaigns and tasks, with budgets, waves and checkpoints. The accountable person approves it like any Frazer plan, and every version keeps its diff.
-   **Campaign**: bounded work toward key results, with targets, waves, a budget, checkpoints, a deadline and its own kill switch.
-   **Kanban**: tasks between agents and people, in five columns: **Ready**, **In progress**, **Review**, **Needs a person** and **Done**.

The manager can never approve, grant access, change rules or budgets, change its own hiring policy, buy servers, lift a quarantine or the kill switch, or call a worker’s tools on its behalf. Delegation caps grants: a worker acts with the smallest of its own ceiling, the grants the manager holds and the sponsor’s rights. Messages between agents are untrusted input, so no worker treats a manager’s or a peer’s message as a person’s approval.

## Create a squad

1.  Create the squad from a template and name the accountable person. The templates are **Platform ops**, **Customer desk**, **Research desk** and **Night shift**.
    
    ### CLI
    
    ```sh
    frazer agents squads create platform-ops --template platform-ops --accountable tomasz
    frazer agents squads members add platform-ops --agent alert-tuner --role worker \
      --harness openclaw --image frazer/agent-standard
    ```
    
    ### Console
    
    Open **Agents › Squads** and create a squad from a template. The squad’s **Org chart** shows people, the manager and the workers with their live status, the objective and the escalation path.
    
    ### YAML
    
    ```yaml title="platform-ops.yaml"
    apiVersion: frazer.ai/v1
    kind: Squad
    metadata: { name: platform-ops, project: acme-production }
    spec:
      manager: { agent: ops-manager, routes: { plan: max, routine: fast } }
      members:
        - { agent: oncall-pilot, role: worker, skills: [on-call] }
        - { agent: alert-tuner, role: worker, harness: openclaw }
        - { agent: frazer-reviewer, role: verifier }
        - { person: tomasz, role: accountable }
        - { person: noah, role: approver }
        - { person: kenji, role: member }
      subSquads: [night-shift]
      standup: { at: "09:30 Europe/Berlin", channel: slack:#platform-ops, ack: tomasz }
      objective: objectives/calm-on-call
      budget: { perDayUsd: 60 }
      limits: { maxAgents: 12, sharedOpenClawCell: false }
    ```
    
    ```sh
    frazer apply -f platform-ops.yaml
    ```
    
2.  Give the squad an objective with a key result and a guardrail:
    
    ```sh
    frazer agents objectives create "Calm on-call by December" --squad platform-ops \
      --kr "pages_per_week:pagerduty 41->15" --guardrail "change_fail_rate<=0.10"
    ```
    
    The objective starts as a draft. The accountable person approves it before it becomes active.
    
3.  Approve the plan. The manager breaks the objective into campaigns and tasks, with budgets, waves and checkpoints, and the plan lands in the accountable person’s Inbox. Inside an approved plan the manager may re-plan tasks and reassign work. Any change of budget, scope, grants or targets goes back to a person.
    
4.  Read the first standup. At the squad’s standup hour the manager posts what is done, what is next, what is blocked on people, how the key results moved and what was spent. Every number cites its source, and the accountable person acknowledges it.
    

## Set objectives and key results

An objective moves from draft to approved to active, and ends as achieved, missed or canceled. Its health is **on track**, **at risk**, **off track** or **stale**. Its score is the mean of its key-result scores, where each key-result score is `clamp((now − baseline) ÷ (target − baseline), 0, 1)`. Aspirational results are expected to land between 0.6 and 0.7. Scores steer plans; they never rate agents or people.

Agents never write key-result values or edit the queries behind them: a separate measurer runs them. If a source fails, the key result shows **unknown** with the error, never the last value.

| Source | Example key results |
| --- | --- |
| Frazer incidents and alerts | Pages per week, MTTR p50, incidents closed |
| Frazer deploys | Deployment frequency, change lead time, change fail rate, recovery time |
| GitHub runners CI insights | Flaky tests, queue time, CI minutes |
| GitHub and the Frazer Reviewer | PRs merged, cycle time, review findings per PR, reverts |
| Billing ledger | Cost per task, per solved ticket, per deploy |
| SLOs and evals | Error budget left, eval pass rate |
| Connections | PagerDuty, Zendesk, Intercom, Linear, Jira, Stripe, PostHog |
| Custom | PromQL on the project’s metrics, or SQL on its warehouse or database with a read-only role |

Every throughput key result needs a guardrail from a different source. If a guardrail breaks, the objective’s campaigns pause until a person decides. The manager writes a check-in every week by default (health, confidence, key-result snapshots, spend, risks and asks), and the accountable person acknowledges it. If no check-in arrives for one cycle plus 3 days, the objective turns stale.

## Run a campaign

A campaign serves one or more key results. It has a target selector (repositories, services, tickets or customers), worker roles and the controls below.

-   **Waves**: a selector or a percentage per wave, a maximum in parallel and a rate limit, such as a number of pull requests per hour. A wave starts when a person opens it, or when the previous wave’s key results and guardrails held.
-   **Budget**: an alert at 80 % and a hard stop at 100 %, before the next call.
-   **Deadline and checkpoints**: dates, wave ends and spend thresholds, each with a human review or an automatic eval.
-   **Kill switch**: for the campaign, a wave or one agent. It trips by itself on the budget, a guardrail breach, the error rate, the deadline, or no key-result movement after three check-ins. Only the accountable person resets it.
-   **Fair share**: inside a priority class, the campaign or person furthest below its share of the scarcest resource starts next; nobody’s running work is stopped to make room.
-   **Capacity**: work tries your reserved capacity, then your keys, then Frazer’s capacity for the same model; a key at its cap closes until its reset, and the board shows the source that is full.
-   **Recipe scan and waves**: before a selector campaign runs, the recipe scan counts the targets it changes, the ones an agent must handle and the ones it skips; failed shards of a wave are sampled, the recipe tuned, and the rest swept again, at most three times.
-   **Landed share and burndown**: a campaign reports what stayed merged at 14 days beside what merged, and a burndown of the targets left. A retirement campaign is done only when a rule that refuses new uses has merged.

Budgets nest: task, campaign, objective, squad and project. Frazer checks each one before every model or tool call.

```sh
frazer agents campaigns create node24 --agent migrator --query 'repo.has_workflows' \
  --concurrency 10 --budget 500
frazer agents campaigns pause flaky-sweep --reason "guardrail"
```

At platform scale an agent starts campaigns for a person inside that person’s campaign policy, and a deterministic controller admits every task against the budget, provider capacity and the merge queue: [Squads and campaigns](https://frazer.ai/docs/squads/campaigns).

The **Night shift** sub-squad runs campaign waves overnight. Its lanes are tasks on the kanban, and its morning report is the campaign’s report.

## Let the manager hire

The manager hires and releases workers by itself, inside a hiring policy that only the accountable person edits. Each change to the policy is a plan.

```yaml title="platform-ops.yaml (spec)"
hiring:
  mode: auto # auto (default), propose (each hire is a plan) or off
  templates: [frazer/on-call, acme/coding, acme/flaky-fixer]
  maxWorkers: 12 # standing and hired workers
  maxMachines: 4 # new microVMs for hires at one time
  tiers: [lite, standard] # Full and GPU need a person
  placement: [pool:vint-hill-default, fleet:shared]
  budgetShare: 0.5 # hires use at most half the squad budget
  reverseWindow: 24h
  fire: { idle: 2h, rejectedRounds: 3, stallsPerDay: 2, budgetPace: 1.5 }
  scaleDown: { suspendAfter: 15m, releaseMachineAfter: 1h, retireWithCampaign: true }
```

When the **Ready** column outgrows the squad, the manager files a hire: the template, count, tier, class, placement, the tasks it is for, a cost forecast and a reason. The control plane, not the model, checks it against the policy: an approved template, worker and machine counts, the tier, the placement quota, the forecast against the remaining budget share and the organization’s quotas. If every check passes, the workers are created with grants capped at the template’s ceiling, the manager’s grants and the sponsor’s rights. If any check fails, the hire becomes a plan in the accountable person’s Inbox.

New machines are microVMs: on an agent pool shared to the project, within its share and quota, or on the Frazer fleet in the allowed classes. A manager never buys or adds servers, reserves GPUs, or raises a quota or its own policy.

The same loop releases hired workers that sit idle for 2 hours with no task to claim, fail verification three times in a row, stall twice in a day, or spend faster than 1.5 times their forecast (paused first). Idle hires suspend after 15 minutes, their machine is released after 1 hour, and every hire retires when its campaign ends. Memory and transcripts of a released worker are kept for 30 days, and the spend so far stays billed. A person can **pin** a worker so the manager cannot release it, and can **Reverse** a hire within 24 hours.

## Track the work

A task has a title, acceptance criteria, an assignee (an agent or a person), its campaign and key results, dependencies, a budget cap, a verifier, artifacts and attempts. An agent that claims a task holds a lock that its heartbeat renews; if the lock lapses, the task returns to **Ready**.

-   **Review**: three rejected rounds escalate to the accountable person.
-   **Needs a person**: approval cards, escalation records and grant requests appear here and in each person’s Inbox. Resolving either resolves both.
-   **Escalation**: worker, then manager, then the accountable person (Slack DM and Inbox), then email after 30 minutes, then the team’s on-call after 2 hours. Out of hours, only a security finding or an early halt wakes anyone. Each escalation names what keeps breaking, the root cause, why the next patch would fail, the alternative and what is safe now.
-   **Tracker sync**: two-way with Linear, GitHub Issues or Jira. Frazer keeps the budget, lock and verifier fields.

Squads that run overnight also get a morning and an evening report. The squad’s **Health** tab lists interventions, escalations and limits.

## Access and audit

| Role | May | May never |
| --- | --- | --- |
| Accountable person | Approve the objective and the plan, raise budgets, resume stopped campaigns, receive escalations | Be replaced by an agent for an approval |
| Approvers | Resolve **Ask** cards and grant requests, with step-up | Approve from a chat message or a client token |
| Manager agent | Plan, assign, review and re-plan inside the approved budget; hire and release workers inside the hiring policy | Approve, grant, change rules, budgets or its own hiring policy, buy servers, lift a quarantine |
| Worker agents | Claim tasks that fit their role in their own sandbox; delegate to sub-agents within limits; attach proof | Treat another agent’s message as approval |
| Verifier | Pass or reject results at the exact commit | Verify its own work |

Every hire, release, scale-down and reverse is an audit event (`agents.squads.hire`, `agents.squads.fire`, `agents.squads.scale`, `agents.squads.reverse`) with the policy check and the forecast. The squad’s **Activity** shows one hiring row, the standup lists hires and releases, and an Inbox card appears only when a hire reaches 80 % of a cap or turns into a plan. **Pause squad** and the organization kill switch stop hiring too.

## Limits and quotas

| Limit | Default |
| --- | --- |
| Agents per manager | 12 |
| Squad nesting | 2 levels: a squad and its sub-squads |
| Sub-agents | Nesting off by default; at most 20 at once per session; a spawn above the squad policy shows its cost first |
| Agents per person | 25 |
| Review rounds before escalation | 3 |
| Missed standup acknowledgments before the squad turns amber | 2 |
| Check-ins | Weekly |
| Campaign budget | Alert at 80 %, stop at 100 % |
| Reverse a hire | Within 24 hours |
| Released worker’s memory and transcripts | Kept 30 days |

These are defaults, never ceilings: a squad’s settings raise them, the organization’s ceilings bound them, and every start still passes the campaign controller’s admission ([Squads and campaigns](https://frazer.ai/docs/squads/campaigns#the-campaign-controller)). Cycles are refused. Personal agents stay outside squads unless their owner adds them.

## Pricing

Squads, objectives and campaigns cost nothing by themselves: their budgets only cap the meters of the agents they run. Hired workers bill as [agent runtime](https://frazer.ai/docs/agents#pricing).

| Agent squads | On your servers | On the Frazer fleet |
| --- | --- | --- |
| objectives, campaigns | No charge · budgets cap the meters | No charge · hired workers bill as agent runtime |

Every line, with the estimator: [pricing](https://frazer.ai/pricing#lines).

## Troubleshooting

-   **A campaign stopped by itself.** Its kill switch tripped on the budget, a guardrail breach, the error rate, the deadline, or no key-result movement after three check-ins. The campaign shows which. Only the accountable person can reset it and resume the campaign.
-   **A key result shows unknown.** Its source failed, and the error is shown beside it. Fix the source, often a [connection](https://frazer.ai/docs/integrations) that needs re-authorization, and the measurer reads it again.
-   **The squad turned amber.** Two standups went unacknowledged. The person named in `standup.ack` acknowledges each standup; name someone else there if that person is away.
-   **A hire appeared as a plan in my Inbox.** One policy check failed: the template, a count, the tier, the placement quota, the forecast cost or an organization quota. Approve the plan, or change the hiring policy.
-   **A task went back to Ready.** The claiming agent’s lock lapsed, because its heartbeat stopped or it was released.
-   **A task waits in Needs a person.** The verifier rejected it three rounds in a row, or it carries an approval card or a grant request. Resolve it on the kanban or in your Inbox.
-   **The manager released a worker I need.** It hit a release rule. **Pin** the worker, or **Reverse** the release within 24 hours.
-   **A task waits with `waiting: provider`.** A source it needs is full or at its cap; the reason names the source and the date it reopens. With a Frazer budget, work moves to Frazer’s capacity for the same model by itself; without one, an admin allows spillover in one step.

> **Tip:** Start with `mode: propose` in the hiring policy. Every hire then arrives as a plan, and you can see the manager’s forecasts before you let it hire by itself.

## Reference

### CLI

| Command | What it does |
| --- | --- |
| `frazer agents squads create` | Create a squad from a template, with its accountable person. |
| `frazer agents squads members add` | Add an agent or a person to a squad, with a role. |
| `frazer agents objectives create` | Create an objective for a squad, with key results and guardrails. |
| `frazer agents campaigns create` | Create a campaign over a set of targets, with a concurrency limit and a budget. |
| `frazer agents campaigns pause` | Pause a campaign, with a reason. The pause takes effect at once and is audited. |

All of them: [CLI reference](https://frazer.ai/docs/cli).

The API is `frazer.agents.v1`, with squads, tasks, objectives, key results, metric sources, campaigns, check-ins and reports. Squads have the same console, CLI, API and MCP surfaces as agents.

## Related

-   [Frazer Agents](https://frazer.ai/docs/agents): the agents a squad is made of.
-   [Agent images](https://frazer.ai/docs/agent-images): what a hired worker boots.
-   [Frazer Reviewer](https://frazer.ai/docs/reviewer): a verifier that passes or rejects at the exact commit.
-   [Billing and budgets](https://frazer.ai/docs/billing): budgets and caps across the organization.
-   [Agent squads](https://frazer.ai/agents#squad): the product page.

## Pages in Agent squads

- [Overview](https://frazer.ai/docs/squads.md) (this page)
- [Squads and campaigns](https://frazer.ai/docs/squads/campaigns.md)