Findings that only exist in terminal scrollback are functionally lost. I hold every investigation to one rule: it ends as a self-contained HTML page, titled with the project and the exact path it ran against.
An agent finishes an audit and prints the results into the terminal. I read them once, the pane fills with the next tool call, and by the time I want to check one specific line again it has scrolled past, or it is sitting under forty lines of build output I have to page through to find it. This happens on every task that produces more than a one-line answer, and it happens worse when several agents are running in parallel, each writing its own wall of text into a pane I am not watching live.
The terminal is a bad home for anything you need to return to. It has no persistence past scrollback, no way to put two runs side by side, and no way to hand a result to anyone else without them opening the same session and hunting for the same place I was looking at. A finding that only exists in scrollback is, in practical terms, a finding that does not exist, because the cost of finding it again is higher than the cost of just running the investigation a second time.
So the rule I hold agents to now is simple: anything I need to look at — an audit, a comparison of options, a teardown, a set of findings — gets written as a self-contained HTML page before I look at it. Inline CSS, inline SVG where there is a diagram, no external assets, no build step, nothing fetched from a CDN. It has to open correctly straight from a file:// path with nothing else running, because the moment a page depends on a dev server staying up, it has stopped being something I can trust to still work when I come back to it later.
The other half of the rule is the title, and this is the part agents skip most often. Every page names the project and the exact path it ran against, in both the page title and the visible heading — not just a task id, not a code name. Task ids collide. The same identifier can exist in two different repositories at once, or in three worktrees of the same repository, because a wave of parallel work spins up worktrees faster than anyone tracks them by hand. With a dozen tabs open from a dozen different investigations, a title reading only "T-204 — Review" disambiguates nothing, and acting on the wrong tab is not a cosmetic slip, it is treating a finding about one codebase as though it were about another.
What goes on the page matters too, in a specific order: the verdict first, in plain words, then the handful of findings that support it, then the detail — collapsed, not deleted, for when I actually want to check the working. An agent that leads with three paragraphs of methodology before telling me what it found has written the page for itself, not for me. I want to know what is true in the first five seconds of opening the tab, and I want the option to go deeper only if the summary makes me suspicious of it.
I have watched the difference this makes in practice. A security sweep that used to live as three hundred lines of terminal output, half of it tool-call noise, becomes a page I can open a month later and still trust, because the verdict is dated, scoped to a path, and sitting next to the evidence rather than mixed in with it. A page is something I can act on without re-deriving it. Scrollback is something I have to re-earn every time I need it again, and most of the time I simply do not bother, which means the work that produced it was wasted the moment the pane scrolled.