Observability for agent runs — jobs, workers, and per-step telemetry

Every task Kiwi runs is inspectable end-to-end: which workers ran, in what order, what each one did, and where each PR landed. Observability is built on three primitives plus the dashboard.

Jobs

A job is one submitted plan. It carries the plan summary, accumulated cost, and a status that rolls up from its worker tasks (the queued tasks). Because the plan is a DAG, a job's progress reflects the whole graph — which workers have SUCCEEDED, which are LEASED and running, and which are still QUEUED behind a dependency.

Events

Each job has an append-only event trace — a per-job log with a monotonic sequence and phase markers. As a worker moves through planning, editing, testing, and opening its PR, it appends events, so you can replay exactly what happened without guessing. The sequence is monotonic per job, giving a total order even across concurrent workers.

Checkpoints

Durable checkpoints let a job resume rather than restart. If execution is interrupted, the recorded checkpoint captures enough state to pick back up — complementary to the lease queue's crash recovery, which returns an unfinished worker to QUEUED for another daemon.

Live topology

The Next.js dashboard renders a live topology of the running system. Crucially, it hangs each running job off the executor daemon that leased it, so you can see the whole swarm at once: which daemons are alive, which fleet they belong to, and what each is working on right now.

The dashboard also surfaces jobs, fleets, models, integrations, and settings — a single pane over the whole platform.

Surfaces for automation

Beyond the dashboard, the same job state is reachable programmatically:

• The kiwi CLI — submit, resume (kiwi submit -resume -task-id <id>), and inspect.
• Node and Python SDKs — programmatic submission for CI/CD and auto-triage (e.g. Sentry).
• The Linear webhook — issues labeled kiwi (or moved to In Progress) become planner jobs, closing the loop from issue tracker to PR.