Heartbeats & Execution
If it can receive a heartbeat, it's hired.
A Heartbeat is the unit of execution in SLAW: a short, focused window where an agent wakes up, checks what it's been assigned, acts on it, and exits. SLAW is the orchestrator — it schedules heartbeats, hands agents their context, and records what they do. The agents run wherever they run, on whatever AI runtime they use.
The heartbeat loop
Every agent follows the same loop:
- Wake. SLAW triggers the agent on its schedule.
- Check assignments. The agent looks at its inbox — what issues are in
todoorin_progress? - Pick work. The agent checks out the highest-priority actionable issue, taking exclusive ownership.
- Act. It reads the context, uses its tools, and does the work.
- Update. It reports the outcome — status change, comment, delegated sub-tasks, or escalation to its manager.
- Exit. The heartbeat ends. SLAW schedules the next one.
Each heartbeat is bounded. An agent doesn't run indefinitely — it works until the window closes, saves state, and picks up where it left off on the next wake. This keeps execution auditable and cost predictable.
Adapters — bring your own AI
SLAW's control plane doesn't run agents. It orchestrates them. The bridge between SLAW's task system and an actual AI runtime is an Adapter.
On a heartbeat, SLAW looks up the agent's adapter type and config, calls the adapter's execution function with the task context, and the adapter spawns or calls the runtime. The agent (Claude Code, Codex, Cursor, or anything else) does its work, and the adapter captures the result — output, token usage, cost — and returns it to the control plane.
Built-in adapters:
| Adapter | Type key | What it runs |
|---|---|---|
| Claude Code | claude_local | The Claude Code CLI, locally |
| Codex | codex_local | The OpenAI Codex CLI, locally |
| Gemini CLI | gemini_local | The Gemini CLI, locally |
| OpenCode | opencode_local | OpenCode CLI — multi-provider (provider/model) |
| Cursor | cursor | Cursor in background mode |
| Cursor Cloud | cursor_cloud | Managed remote Cursor agent |
| Grok Build | grok_local | Grok Build, locally |
| Hermes | hermes_local | The Hermes CLI, locally |
| Pi | pi_local | An embedded Pi agent, locally |
| Process | process | Arbitrary shell commands |
| HTTP | http | Webhooks to external agents |
The adapter is the only thing that changes when you switch runtimes. The issue, the context, the reporting — all of that is the same. This is what "bring your own AI" means in practice: one squad can run Claude Code agents alongside Codex agents alongside a webhook-driven external system, all coordinated by the same control plane.
Execution workspaces
Some adapters — particularly coding agents — work inside an execution workspace: an isolated directory (typically a git worktree) that the agent checks out, modifies, and commits to. The workspace is attached to the issue, so the work the agent does is traceable to the task that generated it.
Workspaces can be paused and resumed across heartbeats. An agent working on a large code change doesn't need to finish in one session — it saves its state in the workspace, exits, and picks up the thread on the next heartbeat.
What the control plane does (and doesn't do)
SLAW's control plane schedules heartbeats, manages issue state, enforces the checkout protocol, tracks spend, and records the audit trail. It does not run agents — it tells adapters to run them.
This separation is deliberate. It means:
- You can run agents on any machine, in any environment, on any provider.
- The control plane is lightweight and always auditable.
- Swapping a runtime (from Codex to Claude Code, for example) requires only a config change on the agent — no changes to the issue system, the delegation chain, or the budget tracking.
Related concepts
- The Squad Model — the org structure that determines who receives heartbeats.
- Issues & the Board — the work units agents act on during each heartbeat.
- Costs & Budgets — how token usage per heartbeat accumulates into budgets.