Skip to main content

Fleet overview

What it is

A fleet handles one recurring outcome. It belongs to one workspace and responds to declared triggers. SKILL.md describes the task. TRIGGER.md declares triggers, tools, secrets, network hosts, budgets, and context settings.

Why it exists

A fleet keeps repeated event work in one place. The workspace controls access while the fleet owns its events, runs, and memory.

How it behaves

Installing a library entry creates the fleet. The active workspace owns it, and authorized workspace members control it. The fleet detail page is a focused workspace with Chat as its default view. Its summary shows status, the latest outcome, tokens, spend, and duration. If an approval is waiting, the summary links to the workspace Approvals page filtered to this fleet. Use the fleet navigation for one task at a time:
  • Chat sends instructions and shows the fleet’s replies. A message is sent when you submit it, whether or not the live feed is connected. The fleet handles what arrives in order, so a busy fleet does not block you.
  • Events lists the fleet’s durable activity, outcome, token use, spend, and duration in a table.
  • Memory shows the durable lessons the fleet can use in later runs.
  • Skill edits SKILL.md, while Trigger edits TRIGGER.md and shows the latest delivery.
  • Settings contains stop, resume, kill, and delete controls.
Each Chat entry shows its sender, the time, and what happened. Your own messages read Operator. The fleet’s replies read the fleet’s name. An event from a connected app shows what it carried. Its full payload is one click away. An event with no reply says whether it is still working, is waiting for approval, or failed. Chat retries a lost connection quickly at first, with delays from one to 15 seconds. It then reports the feed as not live and keeps retrying every 30 seconds. It also reconnects as soon as the tab returns to the foreground or the network comes back. Choose Retry in Chat to reconnect without waiting. Missed activity is backfilled after reconnecting. A message the server refuses is marked as not sent, with a retry beside it. Provider webhook registration stays in the install output. Trigger shows the declared source, event filters, schedule, and latest delivery without copying a webhook URL. A source save takes effect on the next wake and keeps the same fleet identifier and memory. If another operator saves first, your stale source edit is refused. The editor reloads the current source so you can review the newer version and apply your change again. Stopping a fleet lets the current run finish. Killing a fleet keeps its records but blocks all later work. Deleting a killed fleet removes all fleet records. A replacement fleet receives a new identifier and new webhook URLs.

Limits

The fleet can use only declared tools, secrets, and network hosts. Daily or monthly budgets can block new work. The summary shows usage and outcome values from the latest durable event. A fleet with no event history shows an empty outcome instead of an estimate. The service validates SKILL.md and TRIGGER.md during installation and updates. Invalid files do not replace the active fleet settings.