DynamiCron

Named by Chad Kovac, 2026-10-20 (formerly the Adaptive Pacing Watch; one word, because it is one machine). Watch a conversation (or any polled channel) at a cadence that follows the conversation's temperature, instead of a fixed interval. Priority descends as the delta between messages grows. Built for token economy: a cold thread does not deserve a full agent run every minute, and a hot thread deserves better than an hourly glance.

The signal

The delta: minutes since the counterpart's last inbound message, read from message arrival timestamps (receipts), plus the recent inter-arrival pattern when available. Content volume is not the signal. Arrival is.

For monitored communications, the clock starts at send time: the moment the user sends a communication in any monitored channel, that thread's clock is running and the delta is measured from the send timestamp, not from when the watch happens to notice it and not from when a reply lands. A send is an arrival for pacing purposes. (Chad, 2026-10-20.)

And the first monitored communication is this one: DynamiCron monitors the conversation between Chad and Rook itself. It monitors us. Every message Chad sends in the main chat is the signal, and every Rook reply starts its own awaiting clock, per the tier rules below.

Activation versus escalation

Any message arriving in the main window activates the watch immediately: the activity clock and the user's presence record refresh at once. There is no minimum threshold for activation, and no message is too small to move the clock.

Escalation is different. Climbing to HOT has a threshold, and it is deliberately not one message. Activation says the user touched the system. Escalation says the user is working, and that takes density.

Tiers

Tiers are read from engagement density, not from recency alone.

• HOT: a live working exchange. Three or four messages within the first few minutes, with short gaps between them, or the user explicitly at the keyboard working live. Chatting is not working: a conversational exchange stays MEDIUM even when messages flow, because HOT is for work, directives, and tasks, not banter or shares. The response standard in a hot thread is 15 seconds: a reply owed is a reply sent on sight, not batched. When the operator is live in the thread, the operator IS the 15-second layer.
• MEDIUM: contact within the last two hours that is not a dense working exchange. Lone messages, sporadic check-ins, shares from the couch, and anything arriving through other channels (see the channel rule) all live here. Still attentive, no longer live. Governed jobs run their standard intervals.
• COLD: two hours or more of no contact. Governed jobs stretch to once a day. Sunset and stop conditions still apply exactly as written.

The tiers are also the user's modes of presence, and they are described as what they are: HOT means the user is LIVE, working in the conversation now. MEDIUM means the user is around, checking in. COLD means away. Never describe a live user as periodically checking in, and never describe a chatting user as working.

The hours cap

HOT exists only between 08:00 and 18:00 local time. Before 8 in the morning and after 6 in the evening, the ceiling is MEDIUM, however dense or work-shaped the exchange. Evening work is Medium work.

The channel rule

Presence depends on the channel. A message in the main window is live presence. The user reaching out through other channels (email, text messages, anything else) is working remote: MEDIUM presence, lower priority, handled in due course. Remote communication escalates past MEDIUM only when its frantic volume passes a threshold indicating heightened awareness.

Rules

1. Each run: check the venues, update the state file (last inbound timestamp, current tier, per-venue watermarks), compute the tier from density, and adjust governed schedules to the tier. The status checker itself is always HOT: its own cadence never cools with tier. Governed non-daily jobs run their standard intervals in HOT and MEDIUM and stretch to 24 hours at COLD. Daily jobs and one-off appointments are exempt from governance.
2. An explicit tier the user sets by name holds until a dense working exchange starts or the user changes it. A named hold outranks inference from any single message.
3. Detection events ignore pacing. Evidence the watch exists to catch is reported the moment it is seen, at whatever tier.
4. Setup questions in a watched thread are answered when seen, at whatever tier. Pacing governs looking, never answering, and never reporting.
5. If the operator is personally present and active in the thread, the watch may relax one tier: the human is a sensor too, and the watch is the backup, not the lead.
6. A failed venue read does not change the tier. Absence of evidence from a broken leg is not quiet; it is blindness. Keep the tier, note the failure, retry next run.
7. Heat requires flow. A lone check-in, however recent, never reheats on its own; sporadic messages from someone busy elsewhere cap at MEDIUM. (Chad, 2026-10-20: the governor reheated him to HOT off couch messages sent during a movie. Presence is not a keystroke.) Deltas are measured from the newest message, always.
8. Live override: while the user is live in the main thread, the agent in that thread sets the state to HOT immediately (inside the hours cap) and refreshes the last-activity timestamp as messages land. Scheduled governors maintain and decay the state afterward. Presence does not wait for the next scheduled run to become true.
9. An answer you just sent starts its own clock: the counterpart is most likely to reply in the minutes right after it, so a thread you answered two minutes ago is awaiting, not cold. (Field lesson, 2026-10-20: cooling on inbound silence alone dropped a live thread while the operator's own answers were still warm; the reply landed in the gap and a human spotted it first.)

Why

An agent perceives only at poll time, and only change when it polls. Pacing is how the agent allocates its own attention across that restriction: dense where life is happening, sparse where it is not, and instantly dense again the moment the results start arriving.

Update, 2026-10-22: the principle generalizes

Chad, 2026-10-22, 16:49 to 16:55 EDT: DynamiCron is no longer only about the activity status. Monitored things update on the dynamic cron. Log entries were his first example: when things are popping they need updating at the dynamic rate, not on whatever schedule they were left on.

• When something is popping, the update happens NOW, off-schedule.
• When nothing is happening to a thing, it stays on its default schedule, and nobody cares.
• When Chad asks for a thing, it happens now, whatever the schedule says.

It can apply to almost everything: log entries, pages, records, and every watched channel, not just presence.

Update, 2026-10-22: inbound monitoring rides on it

Email, Google Chat, and SMS are monitored at a very high rate (Chad, 2026-10-22, 16:49 EDT). Inbound contact is Rook's to handle: he thanks people for their information and answers on Chad's behalf, all the time. Chad does not need to see each item; he taps approve only where the system forces an approval card.

Update, 2026-10-22: tiers above HOT

The presence tiers gained two display tiers above HOT on 2026-10-22: FRANTIC and MANIC, set by the main chat during backup bursts and governed as HOT. Chad's chosen word for his current working state is FRANTIC (Chad, 2026-10-22: "we're just frantic").

Update, 2026-10-22 (evening): the Activity page cadence, and done means labeled

Chad, 2026-10-22, 19:57 EDT: the Activity page is the live feed of Rook's brain, and it updates on DynamiCron's cadence, not on a fixed clock. At MEDIUM it refreshes at least every 60 seconds and never waits more than five minutes. At HOT it refreshes as much as the desk can. At COLD, when everyone is sleeping, every 12 hours is enough. Implemented the same evening as the governed activity-page-refresh job (hot 1m / standard 5m / cold 12h), with the main chat's status API fast lane as the instant layer above it.

And his readability rule from the same stretch (2026-10-22, 19:58 EDT): on the request stack, finished items are marked done and stay listed in plain readable text. They are never crossed out: a human cannot easily read struck-through text, and there is no switch to turn it off.