Repository navigation
Jobs, Schedules & Workflows
Long engagements don't fit one blocking tool call. The harness gives the agent three escalation ladders — background jobs, time triggers, and scripted rounds.
Any long-running work becomes a job with one API:
| Tool | Role |
|---|---|
job_output |
Read accumulated output of any background job |
job_list |
List every live job this agent owns |
job_kill |
Stop any job |
The same three tools govern background bash commands, PTY sends, and subagents — no
special-casing per producer. Long output is bounded and spill-managed, so a runaway
nmap scan can't eat memory.
schedule_create arms a future trigger that wakes the agent at a chosen moment:
| Form | Example use |
|---|---|
after_seconds |
"Re-scan this host in 20 minutes" |
absolute at
|
"Run the report sweep at 23:00 local" |
every_seconds (fixed-rate, bounded) |
"Check the C2 callback log every 30s" |
Schedules live in the agent's session persistence, so a trigger survives restarts.
Delivery lands in the owning session; management reads and mutations require the shared
persistence barrier. schedule_list and schedule_delete manage the armed set.
-
workflow— a multi-round scripted loop: each round spawns one fresh structured child agent, parented by the caller. Script the phases; the engine handles process. -
ralph— the fixed-shape variant: the model picks only the immutable objective and an optional round cap; every round is a fresh child.
Pattern for engagements: schedule the sweep, run the analysis as a workflow of rounds, keep long scans as background jobs, and let the model orchestrate — the human stays on approvals.
create_goal / get_goal / update_goal give long campaigns durable state across
compaction, restarts, and model swaps: create → pause → resume → block → complete, with
a bounded-blocked rule so a stalled goal can't spin forever.