ActionBoxBlog

SREPlatformBackendAutomation

Actionbox 0.1.4: Watches, Agent Runs, outcomes, and MCP Gate

Actionbox 0.1.4 adds heartbeat and progress Watches, immutable execution outcomes, Agent Runs, and a fail-closed local MCP Gate preview.

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.

bash
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.

python
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.

python
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.

Actionbox Gate is a deliberately narrow MCP preview

The local actionbox-gate executable wraps one stdio MCP server. Exact tool-name rules choose ALLOW, ASK, or DENY, with DENY as the default.

plaintext
MCP client → Actionbox Gate → ALLOW | ASK | DENY → downstream MCP server

Gate pins the downstream server identity and tool-schema fingerprint. ASK binds the reviewed call digest to a signed Action decision, waits before the side effect, then records the execution outcome. Unexpected tools, changed schemas, missing receipt keys, or a missing outcome API fail closed.

This is not a hosted gateway, policy builder, credential vault, or reusable delegation system. The preview is intentionally one local server and static exact-name policy so teams can evaluate the boundary before Actionbox grows it.

What stays simple

The new objects all feed the existing Action lifecycle:

Architecture Flow
Missed heartbeat Stalled progress Risky MCP call Action Human decision Execution Immutable outcome

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.

Try this workflow in minutes

Create a free Source, then run the exact commands from this post against the live API — no approval infrastructure to build.

S
Suson Sapkota

Founder, Actionbox