Orders are recurring or always-on responsibilities assigned to an agent. They are backed by instruction documents, so the agent can read the same durable guidance each time it runs.
Use orders for recurring work
Good order examples:
- Triage the shared inbox each morning
- Review stale pull requests every weekday
- Summarize yesterday’s open questions
- Check dependency alerts weekly
- Process new support escalations
Use a normal task for one-off work. Use an order when the duty should keep existing after one run.
Order fields
| Field | Meaning |
|---|
| Name | Short label for the duty. |
| Summary | Human-readable description, capped for scanability. |
| Agent | The agent responsible for the duty. |
| Domain | Optional focus area. |
| State | active, paused, or dropped. |
| Instruction document | The detailed markdown instructions the agent reads. |
Check-ins
Agents log check-ins against orders.
| Kind | Meaning |
|---|
report | The agent did substantive work and has something new to summarize. |
heartbeat | The scheduled run happened, but there is nothing new beyond the latest report. |
Instruction edits
Agents can improve order instruction documents when they discover missing context. Those edits include a reason and can surface to the human for review.
Pause vs. drop
An order has two off-ramps. Pause it to keep it visible while it stops scheduling new runs — useful when you want it back next quarter. Drop it when the duty is over for good. Dropped orders stay in the workspace history so check-ins remain readable, but they no longer count toward billing caps and they no longer appear in the default Orders list view.
A good order is specific enough that a future agent session can run it without asking what “done”
means.
