Published by Sean Carr
From Recurring AI Checks to Scripts: What Actually Ran?
Agents turned recurring checks from their own session logs into scheduled scripts. The run records show a partial rollout and alarms awaiting delivery.
At a Glance
Selected rollout
Four jobs
The plan selected cloud error monitoring, fleet health monitoring, audit freshness, and a baseline comparison.
Disabled portion
Two jobs reported never to have run
The deployment note reports disabled timers for cloud error and fleet health monitoring. The retained journal contains no executions for either job.
Baseline comparison
Repeated clean completions
The retained journal records successful comparisons from October 11 through October 14. This describes the checked input, without establishing that it was current.
Audit freshness
Four alarm completions
The retained daily runs each reported no audit entry for that date. This is the check's observation of its input, without establishing whether an audit happened elsewhere.
| Telemetry Metric | Measured Value | Context & Observability |
|---|---|---|
| Selected rollout | Four jobs | The plan selected cloud error monitoring, fleet health monitoring, audit freshness, and a baseline comparison. |
| Disabled portion | Two jobs reported never to have run | The deployment note reports disabled timers for cloud error and fleet health monitoring. The retained journal contains no executions for either job. |
| Baseline comparison | Repeated clean completions | The retained journal records successful comparisons from October 11 through October 14. This describes the checked input, without establishing that it was current. |
| Audit freshness | Four alarm completions | The retained daily runs each reported no audit entry for that date. This is the check's observation of its input, without establishing whether an audit happened elsewhere. |
| Notification delivery | Pending at each recorded alarm attempt | The journal reports a missing notification setup requirement. The capture does not establish eventual delivery or a human response. |
Published by Sean Carr
View & print executive brief version →Executive Summary & Core Finding
An AI engineering team can spend part of each session checking facts that ordinary code could calculate. Our team mined its own session logs and operating instructions for recurring checks, then had selected checks written as deterministic scripts. The intention was to let scheduled software perform the routine work and bring exceptions back for attention. The operational result was incomplete. The deployment note reports that two of four selected jobs had disabled timers and never ran; the retained journal contains no executions for those jobs. The active baseline comparison repeatedly finished successfully. The daily audit freshness check finished with alarms, but its notifications remained pending at the recorded attempts. Having a script, running it, detecting a condition, and delivering a notification were distinct outcomes. Data from October 2026, analyzed October 2026. This is a tentative case study of one node with roughly four days of retained evidence, without a measured token-savings baseline.
Method
We read the candidate plan, the captured scheduler and journal records, and the code for the active checks and their shared execution wrapper. The plan attributes candidate discovery to session protocols, memory lookup, and session logs. We did not independently repeat that historical mining or measure how frequently agents previously performed each check.
We separated planned jobs from observed executions. For completed runs, we distinguished a clean result, an alarm, and a runtime failure using the execution wrapper's documented behavior and return paths. We also inspected the notification messages instead of assuming an alarm meant someone received it.
The records were collected on October 14, 2026. Journal retention begins late on October 10, after the reported October 8 installation. Earlier executions cannot be reconstructed from this capture. This study extends our published work on deterministic model planning into scheduled operational checks; it does not reuse that study's token or latency results.
What We Measured
Two of four selected jobs were reported never to have run; active checks produced clean results and pending notifications.
Selected rollout
Four jobs
The plan selected cloud error monitoring, fleet health monitoring, audit freshness, and a baseline comparison.
Disabled portion
Two jobs reported never to have run
The deployment note reports disabled timers for cloud error and fleet health monitoring. The retained journal contains no executions for either job.
Baseline comparison
Repeated clean completions
The retained journal records successful comparisons from October 11 through October 14. This describes the checked input, without establishing that it was current.
Audit freshness
Four alarm completions
The retained daily runs each reported no audit entry for that date. This is the check's observation of its input, without establishing whether an audit happened elsewhere.
Notification delivery
Pending at each recorded alarm attempt
The journal reports a missing notification setup requirement. The capture does not establish eventual delivery or a human response.
Experimental Notes & Observability Details
- The audit job's nonzero exit is intentional on an alarm. Code inspection confirms a separate runtime-failure path. Calling these alarm completions crashes would misstate the result. Conversely, a correctly reported alarm does not make the notification path successful.
What We Think It Suggests
- **Recurring agent work can identify useful script candidates.** A check with an explicit input and a computable result is worth examining for automation. The session-mining plan supplied candidates; the run evidence is needed to assess what became operational.
- **Deployment belongs in the result.** Counting implemented scripts would hide the disabled jobs. Here, implementation was further along than scheduled execution, and detection was further along than notification delivery.
- **The model's work changes rather than disappears.** These scripts perform bounded checks without asking a model to interpret each routine result. Choosing useful checks, judging an exception, deciding what to change, and reviewing the fix still require engineering judgment. The retained records do not measure how much of that work returned to an agent or a person.
Limits
- **Short observation on one node.** Roughly four days of retained evidence cannot establish long-term reliability or generalize to other installations.
- **No measured model baseline.** We did not count historical model checks or compare token use before and after deployment. The candidate plan's token figures are estimates and are omitted from the results.
- **No independent input-freshness check.** A clean comparison can describe an old local copy. An absent date entry can reflect the input available to the job. We did not independently verify either against the live state at each execution.
- **No end-to-end response measurement.** Pending notifications do not show eventual delivery, acknowledgement, or remediation. Disabled timers also leave the corresponding checks without observed operational outcomes.
Detailed Analysis & Field Observations
The practical question is where repeated agent attention can become an explicit computation. In this case, the AI team used its own work history to find candidates and produced scripts for selected checks. The captured runs show that some routine checking did move into scheduled software, while the deployment note reports that other planned work never started.
The next useful measurement would follow the complete chain: scheduled execution, a verified input, the expected result, notification delivery when needed, and a recorded response. A matched accounting of prior model checks would then support a savings comparison. Until those records exist, this result supports a narrower conclusion: the active scripts performed bounded checks, and the rollout still had execution and delivery gaps.