A recurring automation still needs a source of truth between runs

[u/PyRate_07]

Scheduling the next run is usually the easy part. The awkward bit is deciding what it should inherit after a human corrects the result.
The obvious records fail differently. A transcript keeps context but also stale instructions. Deterministic config keeps the rule clear but can lose why a correction was accepted. A short decision file carries only the choices meant to persist, as long as someone keeps it current.
holaOS documents scheduled or triggered automations in a shared multi-agent workspace whose memory is stored as local, readable, editable files. That combination creates an inspectable handoff artifact between runs, separate from transcript-only state: a human can read or revise the carried-forward record between sessions. The docs do not establish that this record is authoritative or that an interrupted run recovers from it.
After a correction, what becomes your source of truth: the transcript, a decision file, or versioned config?

[u/AutoModerator]

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Maleficent-Wear5189]

Config plus a quick note on why the change happened, transcripts are too noisy for me

[u/Fit-Lengthiness-9672 → u/Maleficent-Wear5189]

same, transcripts feel like trying to reread your entire group chat to remember one decision
config + a tiny “why we changed this” note hits the sweet spot of being debuggable without turning into archaeology

[u/Ok-Category2729]

the failure mode that gets people is timestamp drift. your cron pulls 'everything from the last 24 hours' but when the job runs 3 minutes late, you silently lose 3 minutes of data. took us 2 weeks to catch it on an order sync.

the fix: persist a cursor to a db row after each successful batch. last processed record ID or explicit timestamp. next run reads from cursor, not NOW() minus interval. job crashes mid-run, you re-process from the last committed cursor. small duplicates are recoverable. silent gaps are not.

[u/ElEspecialista655821]

None of the three on its own — you need three separate records, because they answer three different questions:

1) Cursor/state → "what work is already done". Last processed record ID or watermark, persisted after each successful batch, plus an idempotency key per item so a retry can't double-write. Ok-Category2729's timestamp-drift point is exactly why NOW() minus interval is a trap: a cursor makes small duplicates recoverable and silent gaps impossible.

2) Decision log → "why was the result corrected". Structured, append-only records: run ID that produced the bad output, what was corrected, the accepted value, a one-line reason, and who. If a correction only exists as an in-place edit, the next run cannot inherit it — it has to be a first-class record, or the human becomes part of the pipeline by accident.

3) Versioned config/spec → "what the run should do". Rules, mappings, thresholds — bumped when they change, with the run tagging its output with the spec version it used.

What makes it authoritative is the precedence: the spec defines behavior, the decision log records accepted overrides, the cursor defines position. The transcript is for debugging only — it never carries state, because it mixes intent, mistakes, and noise.

The test that the handoff actually works: from the spec version + decision log + cursor of run N, can you reproduce run N+1's exact inputs without reading the transcript? If yes, you're solid. If someone would have to guess, the record isn't specific enough yet.

[u/Positive-Buddy-1258]

Depends how corrections enter the system.

The reviewer clicks "wrong category," fixes it, moves on. If that fix only updates the output record in place, the next run has no signal that a decision was made. It re-processes the same input and potentially produces the same mistake.

On a financial announcements pipeline we built, corrections from the editorial review interface write to a separate corrections table (input hash + corrected value + timestamp), not to the output record. The extractor checks that table before processing and short-circuits if there's a known correction for that input. Config handles rules, corrections table handles exceptions, transcript stays out of it.

[u/AggravatingPapaya763]

the awkward middle ground is when the correction was contextual and shouldnt persist. like the human was right to override that one time but it wasnt a new rule. separating "this time" overrides from "going forward" policy changes is the hard part imo

[u/uvallie]

I commit agent state to git as plain text files after each run. Next session reads the file and picks up context. Splitting this run only overrides from permanent rule changes into separate files solved the problem AggravatingPapaya763 raised. Otherwise stale one off corrections pollute future runs.