A report-only agent that acts as a scrum master for my whole body of work. Every weekday it reads my open issues and the log of my scheduled agents, then reports what moved, what has gone quiet, what looks finished but was never closed, and which agents ran. It never comments, reassigns, or changes a status.
A scheduled task starts each weekday morning and reads the current state of open issues and the run log of scheduled agents. Access is read-only.
Each item lands in one group: moved, gone quiet, finished but still open, or agent run. Risk, exception, and compliance work sort the same way as any other work.
The agent writes one short report in a fixed format. The format stays stable so changes from day to day are easy to see.
The agent takes no action on what it found. A person reads the report and decides what to do.
An agent that can update records could fix the finished-but-open group by itself. It would also put its own mistakes into the record, and each fix would need a second check. That check returns the work of noticing to a person.
Signs of completion indicate probable completion. Closing an item asserts that the work is done, and that assertion belongs to the person who owns the item.
An agent that contacts owners places itself between the reader and their team. A message from the reader carries context that an agent lacks.
A dashboard shows current state and waits for a visit. A scheduled report arrives whether or not the reader remembers to look.
The agent has no write path to the issue tracker. A wrong report costs a minute of reading; it cannot change any record.
The agent treats every program as work that needs to keep moving. Program subject matter does not change how the report reads.
The format settled before anything was added. Each later section came from a check I made by hand twice.
The agent adds no new tool to the workflow. It reads what the existing tools already record.
The report arrives on weekdays at a set time, so the absence of a report is itself a signal.
Prioritization stays with a person. The agent supplies the picture; the reader supplies judgment.
The starting point was one sentence: things are going stale and I am not noticing. No specification existed yet.
Claude and I rewrote the sentence as questions a system can answer from records. Did this change? Did that run? Is this done? Each question needed a definition I could state in plain words.
The first version was a single report in a single format. The format settled before anything else was added.
A new section appeared when I caught myself performing the same manual check a second time. A check I had done once did not get a section.
Items that changed since the previous report, so progress is visible without opening each issue.
Open items with no recent activity, listed for a person to review.
Items whose work appears complete while the record still shows them open.
Which scheduled agents ran and which did not, drawn from the agent run log.
When the tracker or the run log cannot be read, the report says so and covers what it could read. A partial report with a stated gap can be trusted for what it covers. A report that hides a gap cannot.
A report nobody reads has the same effect as no report. A short report in a stable format keeps the reading cost low.
The report arrives at a fixed time each weekday, so a missing report is itself visible.
Teams change how they use statuses over time, and definitions of quiet and finished stop matching practice. Reviewing definitions against the first few reports, and again when a workflow changes, keeps them aligned.
Each added section increases reading time. Sections earn their place through repeated manual checks, and a section that no longer changes a decision can be removed.
The report describes recorded state. Work that never reaches the tracker does not appear in it, and the reader supplies that context.