Always-On vs Heartbeat: Designing Agents That Wake on a Schedule

The naive solution is the antipattern that haunts every multi-agent demo: a loop that polls. The agent wakes, asks the same question, finds nothing, sleeps for a minute, wakes again. Multiply that by a hundred agents and you have burned a thousand dollars of LLM tokens before lunch — and you still missed the event that mattered because the poll interval was too coarse.

The right answer is a heartbeat: a cron schedule managed by infrastructure, not by the agent itself.

How AACFlow Splits the Two

AACFlow runs two distinct schedulers because they solve different problems:

• BullMQ holds the schedule queue for repeatable jobs created via the platform's UI. When you set a workflow to run every weekday at 09:00, the schedule is stored in workflowSchedule, BullMQ's repeatable job feature owns the cron, and the worker tier picks the job up when it fires.
• Trigger.dev v4 owns the longer-running, declarative side: 16 background tasks defined in background/ for things like dunning retries, GDPR exports, lifecycle emails, and Mothership inbox sweeps. These are not user-configurable — they are platform behaviors that need durable execution with retries, checkpoints, and timeout policies.

The split is intentional. BullMQ is great at "run this user-defined workflow at this user-defined time." Trigger.dev v4 is great at "execute this complex platform routine durably, with retries and observability, regardless of which worker happens to be alive." Forcing one to do the other's job ends in tears.

Idempotency Is the Other Half of the Story

A schedule without idempotency is a foot-gun. The first time your daily-report agent fires at 09:00 and the worker is slow, the platform retries — and your customers get two identical reports. Production-grade scheduled agents need a key that the work can be deduplicated against.

AACFlow attaches an idempotency key to every scheduled execution, derived from the schedule id plus the firing timestamp window. The executor checks workflowExecutionSnapshots for a snapshot under that key before doing the work. If one exists, the job exits without re-running. If not, it claims the key first, then executes.

This is the difference between a heartbeat that can be safely retried and a heartbeat that compounds errors every time the worker hiccups. Skipping idempotency is the most common reason "we have scheduled agents" silently means "we send duplicate emails."

The Always-On Antipattern, Concretely

The pattern I keep finding in audits looks like this: a developer wraps an agent in while (true) { await checkInbox(); await sleep(60_000); }. It works in the demo. It runs for three weeks in production. Then a deploy restarts the process, the loop is gone, nobody notices for two days, and the customer escalation that was sitting in that inbox the whole time goes from a warning to a contract loss.

The fix is mechanical:

• Replace the loop with a workflowSchedule row.
• Let BullMQ's repeatable jobs hold the cron.
• Let the worker tier scale horizontally without each instance polling.
• Let the platform's audit trail prove the agent actually fired on time, every time.

This is the architecture you cannot retrofit easily — it has to be there before the first scheduled agent ships, because every shortcut compounds.

Wake the Agents the Right Way

Event-driven agents are reactive citizens of a system you already understand. Time-driven agents are different beasts — they need infrastructure that holds the schedule, dedupes the work, retries on failure, and proves it happened. Building that infrastructure yourself per agent is how you discover, two quarters in, that your platform is held together by setInterval and prayer.

Stop building polling loops. Open a workflowSchedule. Attach an idempotency key. Let BullMQ and Trigger.dev v4 do the boring durable parts. The agents that wake up on time and only on time are the ones a real business can run on.