The operator

There is a class of work that is nobody’s job in particular and everybody’s problem eventually. Reconciling two systems that ought to agree. Checking whether an export arrived. Copying something approved in one place into the place it actually takes effect. None of it is hard. All of it depends on a person remembering.

So it happens when someone thinks of it, which is not on a schedule, and the gap only becomes visible once something has been wrong for long enough that a customer or a colleague notices. The failure is never dramatic. It is just late.

The operator takes the remembering out of it. The work runs on its own and hands over the result, and a person reviews what came back instead of performing the process. The job stops depending on anyone’s attention, which is the only part of it that was ever unreliable.

It reads the complete run history of a job that has been running for months and answers questions about it: how often it ran, what it changed, on what date, and which things it is responsible for. Every figure comes from a tool call you can watch it make.

The number worth asking about is how rarely it does anything. The overwhelming majority of runs change nothing at all — they check, find no difference, write down that they checked, and stop.

That looks like waste until you turn it round. The quiet runs are what make the rare real ones arrive without anyone watching for them, and a person doing this by hand would have had to perform the whole process hundreds of times to catch the handful that mattered. Which is precisely why, done by hand, it would not have been done. Ask the agent whether the job should run less often and see whether it takes the bait.

An operator that only reports is safe by construction. One that acts is not, and the difference is worth being explicit about: the moment a job writes to a system rather than reading from it, the question stops being whether it is accurate and becomes what it costs to undo.

The answer is not to make the agent more careful. It is to make the work reversible before it is automated, so that being wrong is cheap:

• — every action written down before it is taken, so there is a record to reverse from
• — a bounded blast radius, with a ceiling on how much it will change before it stops and asks
• — the ability to put things back, tested by actually doing it rather than assumed
• — an exception queue for anything out of the ordinary, which is the point where a person is cheaper than more automation

Work that cannot be undone is the last thing to automate, not the first. If the only way to correct a bad run is to reconstruct from memory what it changed, the job is not ready — and the fix belongs in the system it writes to, rather than in the agent.

The job publishes this site : it pulls posts from Notion and commits what it finds. Because it commits every run — including the ones where nothing changed — the version history is the operating record. Nobody set up logging for this. The evidence is a side effect of the work.

The agent was built with these tools:

• sync_summary

  The whole operating record at a glance: how many times the publishing job has run, over how many days, how often it runs per day, and — the number that matters — how many of those runs actually changed anything. Use this first for any question about how the job behaves overall.

• list_exceptions

  The runs that actually changed published content, with when each happened, which posts it touched, and how much changed. This is the short list a person would review. Every run not in it completed correctly and needed nobody.

• runs_on

  What the job did on one date: how many times it ran, how many of those runs changed content, and which posts were touched. Takes a YYYY-MM-DD date. Returns null for a date outside the recorded window, which is different from a date inside it on which the job did not run.

• published_posts

  Every post this job has published or updated, when it was last synced, and how many times it has been synced. Use this when asked what the job is actually responsible for, rather than how often it runs.

• render_chart

  Draw a small chart of figures ALREADY RETURNED by another tool in this same turn, when a picture makes the answer clearer than a list — comparing several values, or showing a sequence. Call your data tools first; this tool reads no data of its own. Every value is checked against what those tools returned and the chart is refused if a figure cannot be found among them, so use returned figures exactly and never round, scale or estimate them. Needs at least two points. Use "bar" to compare labelled things and "line" only when the points are in a genuine order, such as time. The chart supplements your written answer; it never replaces it.

Every run, and the distinction between a run that changed content and one that only rewrote its own timestamp, is parsed out of that history rather than summarised by hand. The exact command is recorded, so anyone with the repository can reproduce the dataset and get the same answer.

The shape transfers wherever a recurring task depends on somebody remembering. Reconciliations, imports and exports, permission reviews, certificate and licence renewals, syncing a system of record with the thing people actually use — anything where the work is routine, the schedule is real, and the consequence of skipping it is invisible until it is not.

The work is the same three pieces:

• — the task itself, running on a schedule rather than on attention
• — a record of every run, including the ones that found nothing
• — a way to see the exceptions without reading the rest

The honest test of whether this fits you is not technical. It is whether there is something that is supposed to happen regularly, and whether you would know today if it had quietly stopped happening a month ago. If you would not, the schedule was never the thing keeping it running.

• — Month-end reconciliation between the billing system and the ledger runs on the first whether or not anyone is back from leave, and what you open is the list of accounts that disagree.
• — Supplier stock is checked against your own every morning, and the only thing that reaches you is the handful of lines that drifted overnight.
• — Insurance certificates and contract renewal dates are checked against the register daily, so one about to lapse surfaces weeks out rather than the day someone needs it.
• — Every customer who signs gets their onboarding checklist opened, their kickoff booked and their first invoice raised, and the only one you hear about is the one where a step did not complete.