Everything looks equally important.
You're still accountable for what your AI tools produce, but there's far more of it than you can read. Every update, note and summary looks equally important, so you skim all of it and catch nothing.
The signal arrives inside the bookkeeping.
Models are cheap to run and write a lot. Most of it is bookkeeping: status updates, “I picked this up”, re-statements of what was already said.
The few lines that need you (a decision, a failure, a question) arrive in the same stream, in the same format, at the same volume as everything else.
What doesn't work.
Reading everything. You can't, and trying to is how you end up skimming.
Asking for summaries. A summary of noise is shorter noise, and the one important line can get summarized away.
Running more sessions. That makes the stream bigger, not clearer.
What actually helps.
Most of this isn't us.
Separate the kinds of output: decisions, failures and questions in one place, bookkeeping somewhere you can ignore.
Make tools say only what changed. “Still waiting” is not an update.
Put one plain sentence at the top of anything that needs you.
Count the volume now and then. You can't cut noise you haven't measured.
We count our own volume, and the count changed the rules.
We measure how much our own sessions write. One evening in October the count was 259 entries in two hours, and about 120 of them were bookkeeping rather than signal.
That count is why our status updates now replace the previous one instead of piling up, why “I picked this up” notes were dropped, and why our dashboard is being changed to show decisions and failures first, with bookkeeping folded away. The same pass surfaced two important items the volume had buried, and both had owners within the hour.
| What was measured | What the record says |
|---|---|
| entries written in two hours | 259 |
| of those, bookkeeping rather than signal | about 120 |
| the rule it produced | a status update replaces the last one instead of adding a new entry |
| recorded | 13 October 2026 |
| where it's from | Vinculum's own project record, which runs on Vinculum |
Where a shared memory fits.
Vinculum records what kind each entry is, so decisions and failures can be shown apart from bookkeeping.
A shared memory adds to the stream unless you design against that, which is why the count matters.
Common questions.
Can't I just have an AI summarize it all for me?
A summary keeps whatever the summarizer thinks matters. Splitting the stream by kind (decisions, failures, questions) keeps the important line from being averaged away.
Should I just run fewer sessions?
Fewer sessions write less, but the ratio of noise to signal stays the same. Changing what each one writes does more.