Answers
Our AI writes 400-line handoffs and the next agent reads half of one. What fixes that?
The fix is not a shorter prompt or a stricter style rule — it is separating what TRAVELS from what is kept. Length is what the reader pays, and what the next agent needs fits in one authored line. In Arroway every entry carries an essence written by hand: the operative state in a single sentence, never a copy of the body's opening. That line is what a read serves. The full body stays recoverable and comes back only when someone asks for that entry by name. So the record can be as thorough as the work deserves without the next twelve reads paying for it — and because the line is authored rather than truncated, it says the thing instead of the first 200 characters of the thing.
Last updated September 18, 2026
A long note is not a thorough note; it is a bill the next reader pays
The trap is that thoroughness and length are the same thing while you write and stop being the same thing when someone reads. A model asked to hand off writes down everything it touched, because it has no way of knowing what mattered — that judgement comes after the work, from someone who knows which of the twelve things changed the outcome. The result reads as diligence and behaves as noise: every later agent loads the whole thing, spends its attention on the part that was already settled, and gets no signal at all about where the live part is. The cost is not paid once, by the writer. It is paid on every read, by every agent, for as long as the note exists.
Half-read is the normal outcome, and nothing reports it
When the note is longer than the attention it gets, the reader does not fail out loud. It reads the beginning — where the setup lives — acts on that, and the correction that arrived four hundred lines later goes unread. Nobody sees a truncation. What the team sees is an assistant confidently doing the thing that was reversed on Tuesday, and the conclusion they usually draw is that the model is unreliable, rather than that the record made the wrong part the easiest to reach. A record that puts its conclusion at the end is a record that will be misread by anything that runs out of room.
Ageing is a property of the entry, not of the file
The second half of the complaint — the note goes stale fast — is a question about what ENDS an entry, not about how often someone rewrites the file. A line of prose inside a long document carries nothing that says when it stops being true, so it sits there looking exactly like the lines that are still true. Here each entry is written with the condition that kills it, and work that makes that condition true retires the entry in the same act, with the reason on its archived line. Unfinished work is a separate thing again: it is addressed to whoever continues, it stays at the top of every read until somebody closes it, and it dies by being closed rather than by ageing out.
What it looks like in practice
A nightly routine finishes at three in the morning and writes a handoff. The model that wrote it had a long session behind it, so the note runs to four hundred lines: the files it opened, the two approaches it tried and abandoned, the full output of a test run, an apology for a tool that timed out, and — on line three hundred and sixty — the one thing that actually matters, that the migration was applied to preview and not to production. The next morning's routine reads it. It gets through the setup and the abandoned approaches, forms a picture of a session that mostly went fine, and starts its own work. The migration line never reaches it. Nothing fails. The build is green, the review passes, and the gap surfaces two days later as an integration error nobody connects to the note. The handoff was complete and it was correct and it did not work, because being complete is not the same as being read.
Questions people ask about this
- Can't we just tell the model to be brief?
- You can, and it works for one note. What it does not do is make brevity a property of the record, because the next session starts with a different model, a different prompt and a different idea of what counts as brief. The line that holds is structural: one authored sentence is what a read serves, and the body is recoverable on request. Then the incentive points the right way — writing more costs the author nothing and costs the readers nothing either, because the surplus never travels unasked.
- What if the one line leaves out something the next agent needed?
- Then it asks for the entry by name and gets the whole thing. That is why the body is kept rather than deleted: the short form is a default, not a ceiling. What changes is who pays — the read that needs the detail pays for the detail, instead of every read paying for every detail in case one of them needs it. And because the line is written by whoever did the work, rather than generated from the first paragraph, the cases where it misleads are rare enough to handle as exceptions.
- Isn't this just a summary field? We could add one to our file.
- A summary field on a file gets you part of it, and the part it misses is the one that hurts here. What decides whether it works is whether the short form is what readers actually RECEIVE: if the whole file still arrives and the summary sits at the top of it, nothing changed except that the file got longer. The other half is retirement — a summary of a document with dead lines inside it is a shorter way to serve dead lines. Both halves have to hold for the note to stop costing what it costs today.
Where this is verifiable
Product documentation on this site (How it works, Install), the answers on the context file that outgrew a page and on out-of-date memory being read as current, and the authored-essence, handoff and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/chatty-handoffs-bloat-every-agent-that-reads-them-next