Sling work
Give agents single tasks or multi-step convoys
"Slinging work" is how you give agents something to do. You can sling a single task (a bead) or a structured multi-step plan (a convoy).
Single Tasks
The simplest way to use Hull Fleet, describe what needs to be done, and an agent picks it up.
Ask the Mayor:
"Fix the 404 error on the /settings page, the route is missing from the router config"
Or use Sling Work in the town. Either way, Hull Fleet assigns the bead to an available polecat. The agent reads the relevant code, makes the fix, runs any tests, and pushes a branch.
Writing Good Task Descriptions
The quality of agent output directly correlates with the clarity of your description:
| Approach | Example |
|---|---|
| Vague (avoid) | "Fix the auth" |
| Specific (better) | "Fix the JWT token expiration, tokens should last 24h, not 1h. The constant is in src/auth/config.ts" |
| Contextual (best) | "Fix #142: users are getting logged out after 1 hour. The issue is the JWT expiration in src/auth/config.ts is set to 3600 (1h) but should be 86400 (24h). Add a test to verify." |
Include:
- What needs to change
- Where in the codebase (file paths if you know them)
- Why it's needed (link to issues, error messages)
- How to verify (tests to run, behavior to check)
Convoys
Convoys break larger work into stages where each builds on the last, with review at every step, instead of one agent doing everything in one pass.
Why Convoys?
Single-pass agent output has a quality ceiling. The longer an agent works on one task, the more likely it is to accumulate compounding errors. Convoys solve this by:
- Decomposing complex work into focused, reviewable chunks
- Sequencing so later steps build on reviewed, merged code
- Reviewing each chunk independently before it becomes the foundation for the next step
- Containing failures: if step 3 fails, steps 1 and 2 are already safely merged
Creating a Convoy
Via the Mayor:
"Create a convoy to migrate the database from PostgreSQL to MySQL. Steps: 1) audit current schema and queries, 2) design the new schema with migration plan, 3) implement the migration scripts, 4) update the application layer, 5) add integration tests"
The Mayor converts this into a convoy with proper dependencies.
Convoy Execution
Once you start a convoy, Hull Fleet works through it:
Key behaviors:
- A bead is dispatched only when the beads it depends on are closed
- With Review then land, each polecat starts from the convoy branch, which collects all previously merged work, and the refinery reviews each change against it
- Once all beads close, a landing review checks the combined change before it goes to your default branch
- With Review and merge, each bead gets its own pull request to the target branch instead
Layered review
Convoys give you several review passes:
- Per-bead review: the refinery reviews each change
- Building on reviewed work: each agent starts from code that already passed review
- Landing review: the complete change is reviewed as a whole
- Your review: with the pull request strategy, your team reviews the final pull request, optionally with Hull code review
Problems get caught in the smallest change, where they're cheapest to fix.
Staged Convoys
In new towns, convoys are created staged: the plan exists but agents don't start until you start it. This lets you:
- Review the task breakdown before execution
- Adjust descriptions, add context, reorder
- Ensure the plan makes sense before burning compute
Start it from the convoy detail, or ask the Mayor: "Start the database migration convoy". Change the default with Stage convoys by default in Settings.
Priority
Beads have a priority: low, medium, high or critical. Use it to signal what matters most when you review the board. Set it by editing the bead, or ask the Mayor: "Make the auth fix high priority".
Watching Progress
Rig Page, Convoy Tracker
The best place to observe your town in action is the rig page. At the top, active convoys show their progress as a visual tracker, each bead in the convoy displayed with its current status and dependency relationships. You can see exactly where in the DAG execution has reached and which beads are blocking downstream work.
Rig Page, Kanban Board
Below the convoy tracker, a board shows beads by status (open, in progress, in review, closed) and updates live as agents work.
You can see at a glance:
- What's queued up (open column)
- What agents are actively working on (in progress)
- What's awaiting review (in review)
- What's shipped (closed)
Beads move through the columns on their own as agents pick up and finish work.
Beads Page
For a more detailed, filterable view across all rigs, the beads page shows every bead in your town. Filter by:
- Status (open, in progress, in review, closed, failed)
- Type (issue, merge_request, convoy)
- Rig (if you have multiple repos)
Click any bead to see its full detail, description, event history, agent activity, and review feedback:
Town Overview
The town overview shows a high-level summary:
- Active agents and what they're working on
- Recent completions
- Pending work queue
Feed and observability
The town's feed shows events as they happen: agents picking up beads, reviews submitted, pull requests created. The Observability page gives a more detailed view when you need to see exactly what happened.