AI agents for libraries / Worked example
Monthly statistics are a good place to start experimenting with AI agents. The job is small enough to describe clearly, but there are still several ways to get it wrong: use the wrong month’s report, count the same title twice in the rankings, overwrite a formula, or announce that the work is finished before checking the saved result.
For my monthly Flipster reporting, I use an agent to coordinate the work and a script to handle the calculations. The useful part is the whole process: knowing which source to use, what the numbers mean, where they belong, and what evidence is needed before calling the job done.
Start with the work
The report arrives as a vendor workbook. The reporting month comes from inside that workbook, not from the date the email arrived. The result I need is a monthly total for online views and downloads, plus the five most-used magazine titles, recorded in an existing statistics sheet.
That sounds straightforward. It still needs rules. A title can appear more than once in the source. Online views and downloads are separate activities. The destination already contains a total formula and formatting that should survive the update.
I use written instructions to make those requirements explicit. They also define when the process should stop and what must be checked before anyone receives a completion message.
Divide the responsibilities
| Responsibility | What it involves |
|---|---|
| My decisions | Define the intended result, allowed sources, destination, authorization, and exceptions that need attention. Review changes to those rules. |
| Agent coordination | Locate the source under those instructions, invoke the processor, inspect its result, check the destination, carry out authorized updates, and verify them before notifying a colleague. |
| Repeatable code | Validate the report period and expected layout, combine rows with the same title, reconcile counts, rank titles, and prepare a separate output copy. |
Routine runs can proceed under standing authorization. That does not mean the agent gets to invent a new source, change the reporting definition, or silently work around a failed check. Human accountability includes deciding those boundaries in advance and handling exceptions; it does not require pretending that I manually approve every cell on every run.
The sequence is:
Vendor report → source and month checks → calculation and reconciliation → prepared copy → destination checks → authorized update → saved-value verification → notification.
If a check fails, completion stops at that stage. Preparing a file is not the same as updating the shared sheet, and updating the sheet is not the same as confirming a notification.
A small worked example
The following numbers and title labels are synthetic. They come from a disposable test fixture, not from a library’s usage report.
The source contains download counts of 1 and 6 on separate rows for Title A. Titles B, C, D, and E have 2, 3, 4, and 5 downloads. Each title has one online view. The processor combines the two Title A download rows before ranking:
| Rank | Synthetic title | Online views | Downloads | Combined use |
|---|---|---|---|---|
| 1 | Title A | 1 | 7 | 8 |
| 2 | Title E | 1 | 5 | 6 |
| 3 | Title D | 1 | 4 | 5 |
| 4 | Title C | 1 | 3 | 4 |
| 5 | Title B | 1 | 2 | 3 |
| Total | 5 | 21 | 26 |
Without combining its rows, Title A’s use would be split across entries. The processor groups matching title text, then orders titles by combined downloads and online views. It uses reporting-period use and then title text to break remaining ties. This is exact-title grouping; it does not decide that different spellings must refer to the same publication.
The totals also have to match the vendor’s grand totals for each activity. In a test that changes the downloads grand total from 21 to 200, the processor refuses to proceed because the title rows no longer reconcile. Other tests reject a mismatched month header and a missing count. These checks were exercised with local test data; they are not claims about errors found in a real vendor report.
Check what was actually saved
The processor preserves the source workbook and creates a separate processed copy. It reopens that copy, checks the summary values, and confirms that the original source-cell values remain unchanged. It also prepares the exact values for the two destination ranges; it does not publish them itself.
Before the shared sheet is changed, the workflow calls for checking its year, month, layout, and existing cells. After an authorized update, the saved values are read back. The total formula, title order, and formatting are checked as well. Only then is the completion notification sent.
For the October 2026 report, the saved execution record documents that sequence through spreadsheet verification and a confirmed notification. During preparation of this case study, the preserved source was processed again in read-only mode and reproduced the saved totals and ranking. That supports a specific completed run. It does not establish that every scheduled run succeeds.
Plan for the unfinished cases
A missing or expired source should leave the job unfinished, with a clear explanation. Substituting an older report could produce a perfectly tidy spreadsheet for the wrong month.
A changed layout or failed reconciliation needs investigation before publication. If the sheet is updated but the notification fails, those are two different statuses. A retry should inspect the saved sheet and delivery evidence before repeating either action.
This is also why I would start a public demonstration with synthetic data. The example needs to show the decisions and checks, not private messages, account information, or access links. The real workflow still requires decisions about which connected services may process the source data; keeping instructions locally does not make all processing local.
What another library can take from this
Start with one recurring task and answer five questions:
- Which source is authoritative, and how will we know it covers the right period?
- Which steps follow stable rules that code can handle?
- Which decisions belong to a person, and which actions have already been authorized?
- What evidence will show that the saved result is correct?
- What should stop the workflow, and how will we resume without duplicating work?
This example demonstrates a bounded reporting workflow with inspectable calculations and verification. I have not measured a before-and-after time saving, an error-rate improvement, or a net cost saving. Those would need a comparison that includes setup, review, subscriptions, maintenance, and recovery when something fails.
For me, the useful starting point is a task with a clear source, a clear result, and checks that mean something. Once those are in place, it becomes easier to decide where an agent is useful and where a straightforward script is enough.