Actionbox 0.1.4: Watches, Agent Runs, and Outcomes

Actionbox 0.1.4 extends the same durable Action inbox in two directions: software can now report that scheduled or autonomous work has gone silent, and approved work can report what happened after execution. The release keeps each primitive small and optional.

Heartbeat Watches turn silence into an Action

A Watch stores one interval or cron expectation for a Source. A missed deadline, explicit failure, or maximum-runtime overrun creates one ordinary deduplicated Action. A later ping or success resolves that incident automatically.

actionbox watch create "Nightly backup" \
  --source-id src_123 \
  --interval-seconds 86400 \
  --grace 15m \
  --max-runtime 1h

actionbox run --watch-url "$ACTIONBOX_WATCH_URL" -- /opt/jobs/backup.sh

There is no second alert inbox. The incident uses the existing Action history, routing, mobile review, and resolution model. Heartbeat capability URLs are shown once, hashed at rest, and kept out of normal responses and telemetry.

Execution outcomes close the decision loop

A human approval says an operation may run; it does not say the operation succeeded. A Source can now attach one immutable success or failed outcome to the exact resolved Action version and fingerprint.

resolved = client.actions.get("act_123")
resolved.report_outcome(
    status="success",
    duration_ms=48312,
    rollback=False,
)

Exact retries are idempotent, while conflicting rewrites fail. Keeping decisions and execution results separate makes later delegation analysis possible without pretending that every approval had a good result.

Agent Runs add bounded context, not another framework

An Agent Run groups one autonomous task, small progress checkpoints, and related Actions. It does not store transcripts or tool logs, and standalone Actions still work as before.

run = client.runs.start(
    external_id="checkout-fix-42",
    agent_name="codex",
    title="Fix checkout deadlock",
    stall_after_seconds=900,
)
run.progress(stage="tests", checkpoint="test-184")
run.complete()

When stall_after_seconds is set, repeated liveness with unchanged bounded progress does not hide a stall. The existing worker creates one linked Action after the deterministic deadline; changed progress or completion resolves it. No LLM decides whether the agent is stuck.

What stays simple

The new objects all feed the existing Action lifecycle:

There is no general event-rule engine, workflow canvas, LLM stall judge, or automatic delegation in 0.1.4. The release establishes the minimum trustworthy data needed for those decisions later.

Create a free Source and start with one heartbeat Watch or one test-environment Agent Run.