Skip to main content

​
What it is

A fleet handles one recurring outcome. It belongs to one workspace and responds to declared triggers. A fleet’s Definition holds its setup. The instructions describe the task. The runtime settings declare 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

Saving a draft creates the fleet. The active workspace owns it, and authorized workspace members control it. The fleet page opens in Chat. Its summary shows status, the latest outcome, tokens, spend, and duration. Dashboard navigation, conversation headings, and billing show your chosen fleet name. Runner lease history uses a stable callsign, such as AGENT ORBIT-BCD3. Billing uses the callsign when the fleet name is unavailable. 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.
  • Activity lists saved activity, outcomes, token use, spend, and duration.
  • Memory shows lessons the fleet can use in later runs.
Choose Edit setup in the fleet header to open a private setup chat beside the conversation. Closing the editor returns to the conversation. Other controls include stop, resume, kill, and delete, according to the fleet’s state. 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. Sending a message moves Chat to the latest turn. A spinner shows that the fleet is working until its reply starts. Open Thought to read the fleet’s reasoning after its answer starts. Tool calls show their names, progress, and duration separately from the answer. New activity leaves your place in older messages alone. Use Jump to latest above the message field to return to the newest turn. On narrow screens, the fleet tabs scroll sideways and the status figures wrap. 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. If live updates stop, Chat reconnects and fetches recent saved activity. Some live reply fragments may be missing. See connection recovery for retry timing and manual recovery. A message that was not delivered leaves the thread, and its text returns to the message field. A refused message shows Message not sent above the field. One with no answer shows Couldn’t confirm this message was sent. Choose Resend to send the message again. The fleet runs it at most once, even if the first send did arrive. Each unsent message keeps its own Resend and Dismiss until you choose one. The list survives a page reload and shows in other tabs. It stays with you: someone who signs in next on the same browser never sees it. An expired session shows Sign in beside Resend, so you can sign in and then resend. Resending the same message is safe; changing the text makes it a new message. A message can be at most 8,192 bytes. The fleet API’s webhook_urls lists each provider webhook address. Choose Edit setup, then Edit instructions manually below the conversation to review declared triggers and their filters. Each schedule’s description states its timing and time zone, such as At 9:00 AM (Asia/Kolkata). Its run_state and nullable next_run_at describe whether it will run: The server works out the state and next run when you request the fleet. Run history stays in Chat and Activity. An improvement runs in a private chat pinned to the fleet’s current setup revision. Choose Save changes to make it the fleet’s next revision. Running work keeps the revision it started with. The fleet keeps its identifier and memory across revisions. Saving changes never publishes them to the Fleet library. If the fleet’s setup changed after the chat loaded it, Save changes is refused with UZ-AUTHOR-003 or UZ-AUTHOR-006. Reload the chat, check the setup, then save 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.

​
What a follow-up message keeps

A message from Chat, from agentsfleet steer, or from a Slack mention reaches the model with the fleet’s recent conversation. The model reads up to 8 earlier turns of the fleet’s chat thread, oldest first. A turn is one message and the fleet’s answer to it. Each message or answer keeps its first 16 KiB, and the oldest turns drop until the rest fit in 64 KiB. A message still waiting, running, or refused before it ran is left out. If the thread cannot be read, the message runs without earlier turns. A failed turn reads as [the run failed: <LABEL>], where <LABEL> names the failure. A turn that ended without a reply reads as [no reply]. On a model that uses the Messages or Responses API, agentsfleet asks the provider to cache the start of the prompt. That start holds the tools, the instructions, and the earlier turns, so a follow-up can read it from the cache. A model on the Chat Completions API gets no cache request. When a run finishes without failing, its runner keeps the fleet’s sandbox for 10 minutes. The fleet’s next run in that window goes to the same runner and continues in that sandbox. It finds the files, installed packages, caches, and repository changes the last run left. Do not rely on a running process. A background process ends when its command ends, and every exec_command session ends when the run ends. A fleet that declares no sandbox tool has no sandbox to keep. The next run starts in a fresh sandbox when any of these is true:
  • More than 10 minutes passed since the last run finished.
  • The last run failed.
  • The fleet’s repositories or network access changed.
  • The fleet was stopped, paused, or killed.
  • The runner restarted, went offline, needed the room for other fleets, or could not resume the sandbox.
A fresh sandbox checks out the fleet’s repositories again and holds none of the last run’s other files. Keep what must last longer in the fleet’s memory.

​
Limits

The fleet receives only declared tools and secrets. Network restrictions depend on the tool and the runner’s network policy. Daily or monthly budgets can block new work. The summary uses the latest saved event. A fleet with no history shows an empty outcome. agentsfleet validates the Definition in every draft, Save, and Apply. An invalid Definition never replaces the active fleet settings.