The weird thing about working with coding agents is how easy it is to miss your own work. I’ll start a task, move on to something else, and come back to finished work waiting for me. That part is great, but it’s not just about handing off your work. You need to own your work, understand what’s happening, be able to explain what’s going on in case something happens or you (or your team) builds on it.

It’s one thing when it’s my own agent, but then you add several sessions running at once. And it’s not just you. It’s the engineering team. It’s agents working asynchronously while we’re all in meetings. Subagents underneath those agents, multiple repos, everyone moving faster.

Somewhere in that stack, the hard part moved. Getting the work done is going fine. Keeping the team caught up with the work that’s getting done is the part that hurts.

The old way of working leaked context

For years, engineering teams have tried to reduce silos with pairing, code review, standups, Slack threads, architecture meetings, documentation, and more. Some of that felt like friction, and sometimes it absolutely was.

But that friction had a side effect: other people saw the work happening.

Think about how a bug used to travel. An engineer investigates, complains about it in Slack, asks someone a question, mentions it at standup, opens a PR, and a reviewer asks why they did it that way. It was slow and occasionally annoying. And the whole time, knowledge was leaking out of the work, because the work required human interaction. Teammates absorbed pieces of it without anyone scheduling a knowledge transfer.

Now watch the same bug travel through an agent. An engineer hands the agent a task. The agent investigates, tries three approaches, finds a weird undocumented constraint, works around it, and opens a PR. It’s faster and cleaner, but the entire middle of that story disappeared into a session. The team receives fix auth handling and 428 lines of diff.

We removed coordination overhead. We also removed accidental knowledge sharing. Both of those rode on the same friction.

AI makes silos cheap to create

A knowledge silo used to take time to build. Someone had to become the payments person, or the Kubernetes person, over months of being the one who touched that system. Eventually the organization noticed that too much lived in one head and tried to spread it around.

Now a silo can be one session long.

And they nest. An engineer knows something their teammate doesn’t. Their agent’s session holds something the engineer skimmed past and won’t remember in a week. A subagent discovered something that barely made it back into the parent session. That last one sounds paranoid until you read how these systems are built: Anthropic’s multi-agent research architecture runs subagents in parallel with their own separate context windows, and GitHub’s engineers describe multi-agent setups as behaving less like chat and more like distributed systems, with new failure surfaces around shared state, ordering assumptions, and implicit handoffs. Isolation is the design. The knowledge fragmentation comes free.

Here’s the thing about speed: it changes the half-life of shared context. If three people can do five times as much agent-assisted work, the organization has five times as much new context to absorb. The human bandwidth stayed the same (or in the case of a lot of layoffs, has actually decreased).

The bottleneck moves from doing the work to understanding it

The old bottleneck was execution. How quickly can we build this? The new bottleneck is orientation. How quickly can the rest of us understand the work that just happened?

You can see the whole industry arriving at this at the same time. GitHub built mission control, “a unified command center” where you “choose from a fleet of agents, assign them work in parallel, and track their progress from any device.” The same announcement describes what working with agent tooling had felt like up to that point:

That’s Kyle Daigle, GitHub’s COO, describing the daily experience of some of the most agent-forward developers anywhere. Anthropic added an agent view to Claude Code because people run enough parallel sessions that they need a dashboard just to see which ones are running, which are blocked on them, and which are done.

Every one of these is an orientation layer. The industry keeps increasing agent throughput, and then discovering that somebody has to help the humans point their attention.

What if you need that context this afternoon?

I wrote in August about the longer-term version of this problem: your team’s knowledge is hiding in sessions nobody reopens. Over two months our team ran 766 real agent sessions, and 29 of them were promoted into reusable skills. The rest sat in the store, full of environment fixes, debugging trails, and decisions, waiting for someone to go looking.

That post asked how useful knowledge survives after the work is over. This one runs on a faster clock. What if I need that context tomorrow? What if I need it this afternoon, because my teammate’s agent already touched the file my agent is about to touch?

Knowledge dying in history is a library problem. A team losing track of the current week is a coordination problem. It’s the same store with two different clocks.

Reading the transcripts won’t scale

Technically, we solved visibility. We have transcripts. Tool calls. PRs. Git history. Every step of every session, recorded.

Now please read 46 hours of them.

There’s no shortage of evidence. What’s missing is compression. And compression is a problem humans already solved for human work: standups, status updates, handoffs, weekly summaries, “here’s what changed,” “here’s what needs your attention.” We don’t send our manager our terminal history at the end of the day.

So it’s worth asking why our default answer to agent coordination is the complete transcript.

What a useful handoff tells you

Strip away the tooling, and a handoff needs to answer four questions:

• 1.What happened? The work that actually ran, in a few sentences a human can hold.
• 2.What changed? Code, config, decisions that are now different than they were this morning.
• 3.What got stuck? Dead ends, blockers, the thing two sessions abandoned at the same wall.
• 4.What needs attention next? Where a human should point their limited focus first.

And a fifth, the one that separates a status update from a team getting smarter: what did we learn that somebody else should know?

A good summary works like an index. It points, and the source stays underneath. If a line surprises you, you open the session and read the receipts.

Why we built digests into paper console

We’ve been feeling all of this inside Paper Compute, because we capture nearly everything our own agents do in tapes. Ironically, capturing everything is what made the problem impossible to ignore. Nobody on this team wants to consume everything. I don’t. I want to end the day, or the week, knowing what my team and our agents actually did, without opening every session one by one.

So the dashboard in paper console now leads with a digest: a summary of the window you pick, then highlight cards pulled from the sessions underneath. Each highlight is tagged by the kind of thing it is: an outcome, a blocker, a decision, an efficiency note, or an observation. Cards carry the labels of the sessions they came from, link to the session and its trace, and take a thumbs up or down so the digest learns what your team considers signal.

Try it. Switch between 24h and 7d, and rate a highlight:

Dashboard

24h7d

Weekly digest

Rolling window·Sep 9, 2026 – Sep 15, 2026

Refresh in 42m

Summary

Most of the week went to the ingest worker: the retry budget was rewritten and the export timeout that had been intermittent for a month was traced to it. The pgvector spike ran on Thursday and stayed a spike. Two sessions on the billing exporter were abandoned after a schema mismatch.

Highlights

1–2 of 4

1. Ingest retry budget rewrittenOutcome

   brian replaced the fixed backoff with a per-tenant budget; the worker no longer stalls under a burst.

   backend

   View trace
2. Export timeout traced to ingestBlocker

   maya found the 30s export timeout was waiting on the same worker. Fixed by the retry change, not on its own.

   flaky-test

   View trace
3. pgvector stays a spikeDecision

   Search quality was equal; write amplification was not. Parked with notes in the session.

   needs-review

   View trace
4. Billing exporter abandoned twiceObservation

   Both sessions stopped at the same schema mismatch. devon has not returned to it.

   View trace

The receipts stay underneath. The digest tells you the export timeout was traced to the ingest worker. The session tells you the three things that got tried first. Surprise sends you one level down, and the level down is always there.

The coordination layer has to catch up

We’ve spent the last few years making agents faster, more autonomous, and able to work in parallel. It’s working. Which means we’re busy creating the next problem: the work can now move faster than the people responsible for understanding it.

Agents already work without us. The missing piece is the way back in: how a human re-enters work they didn’t witness without starting from zero. It’s a bottleneck in the agentic engineering era.

If your team has found a rhythm for staying caught up, I’d honestly like to hear it. And if you want to see what your own week looks like compressed, the digest is sitting at the top of the dashboard in paper console.