Heartbeats, Right-Sized — Keeping Background Agents Awake Without Burning the Budget
Treat the heartbeat as its own job with its own requirements — a smaller model, a lighter context, and the slowest cadence the lane can tolerate — and apply that configuration as the default across every channel so no lane drifts back into the expensive shape.
What was getting in the way.
Every always-on agent needs a heartbeat — a recurring background check-in that keeps the lane awake and ready to react. The default is to wire it up on the most capable model with full conversation context attached, because that's what the main lane uses. Multiply one quiet background heartbeat by every channel, every hour, every day, and the single smallest-looking task on the roster becomes the largest line on the bill — four figures a month to do almost nothing.
Context
An operation running many always-on agents in parallel across many channels — where the heartbeat configuration gets copied by default into every new lane, and a single expensive default becomes a recurring tax that only gets noticed when someone reads the whole bill.
How the work runs.
- 01
The heartbeat gets measured.
Actual cost per heartbeat, per lane, per channel is pulled from billing data — not estimated — and the current configuration (model, context, cadence) is read out of the live runtime so there's no guessing.
- 02
The job is defined honestly.
A heartbeat exists to keep the lane warm and reactive, not to think — the configuration is matched to that job: a smaller model, a light context package, and the loosest cadence the lane can tolerate without missing its purpose.
- 03
The change is applied live.
Config is backed up, the new defaults are set against the running system, and the live state is verified — no restart, no change-window ceremony.
- 04
The default travels with every new channel.
The right-sized heartbeat becomes the standing default so every new channel starts in the cheap shape, and the old expensive shape can't be inherited by accident.
- 05
A watchdog keeps it right-sized.
A recurring cost-per-turn check in each channel alerts if the heartbeat (or anything else running in the background) drifts above its expected cost, so the next time a lane creeps back toward the old pattern it gets caught the same way the first one did.
Evidence from the workflow.
Each system has a role.
the live defaults for background lanes (model, context mode, cadence)
Agent runtime config
measured heartbeat cost per lane and per channel (never hand-estimated)
Billing / token-cost pipeline
recurring cost-per-turn check per channel that posts to Slack when a lane drifts
Watchdog scheduler
where the finding, the proposed change, and the applied result show up in the open so a human can question or override
Slack
Why this is Operator.
Owns a workflow end to end, running the process inside the authority you set.
- 01
The proposed change is posted in the channel with the before/after cost stated plainly, applied against a backed-up config, and verified afterward. A human can question, pause, or revert any step. The watchdog alerts to Slack rather than taking autonomous action, so a drift becomes a conversation, not a silent re-tune.
Impact / Outcomes
The background heartbeat drops from the biggest recurring line to a small, predictable one — same uptime, right-sized tool
Every new channel inherits the cheap configuration by default, so the fix doesn't have to be re-applied by hand
A per-channel watchdog catches the next lane that drifts, before it compounds across the roster
Dollar figures in follow-on reports come from measured billing data, not hand-estimates — the number everyone acts on is the real one
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.