Introducing slake for Autonomous Workflows
A durable automation system must know when to pause. slake exists to keep repeated commands from collapsing into bursts and to keep autonomous loops from learning the wrong operating pattern under pressure.
Renamed, October 5, 2026: cooldown-guard is now slake, with the same commands and the same ledger. This article introduced the tool when it was released as cooldown-guard in April 2026.
Cooldown logic is not a throttle for its own sake. It is a policy boundary that protects your stack from your own throughput.
Every command path in an automation system can overrun a dependency or upstream queue. slake keeps the blast radius bounded.
Why this project started from failure points
Repetitive control loops are often written as if every environment is always healthy. In real operations, retries stack, windows overlap, and a single burst can push a stable system into sustained pressure.
Existing ad hoc methods usually track cooldown in memory or in brittle shell scripts. They do not persist state across restarts, and they hide why an action was blocked. That makes incident investigation slower and policy adjustments inconsistent.
Design decisions
- Declare policy before execution and keep it stable in one schema.
- Track state transitions in SQLite so repeat checks are deterministic and replayable.
- Expose clear reasons for each blocked action and support structured output for automation owners.
- Use one boundary module to protect every automation loop from becoming a hotspot.
The first release focuses on operational boundaries: one command to check cooldown, one schema to define action identity, and one durable store. No external dependency model is required to run the default flow.
Execution before optimization
slake is intentionally narrow. It does one thing: decide if an action may proceed. The first version ships with clear status output for automation owners and deterministic behavior so automation state is auditable.
The broader release plan includes richer reporting and scheduling helpers, but the core contract is already in place: define policy, check state, return explicit outcome.
This chronicle supports the OpenForge launch path for slake. It is now represented on the OpenForge page with direct repository access and status tracking.