I spent time in Europe this summer and got into the architecture. I stayed near Hammersmith. The bridge there opened in 1887. While I was there, the local news was running stories about Hammersmith Bridge falling apart. Cracks in the pedestals. Weight limits. Closures.
London bridges are legitimately falling down. That is not a nursery rhyme problem. It is a load problem. The bridge was built for a volume of traffic nobody in 1887 could have modeled.
The same thing is happening in infrastructure right now. GitHub is overwhelmed. The pipes agents push data through were built ten or more years ago for human-sized traffic. They were not designed for the volume agents ship.
Part of this is agentic coding. Part of it is new vibe coders one-shotting more than 100 projects and pushing them to GitHub. Part of it is that anyone can produce a SaaS product in an afternoon now. Developer, vibe coder, prompter, pick your label. Everyone is part of the machine.
Paris solved this once
Paris hit the same wall a generation before London and answered it differently: it decided to rebuild everything from the ground up. In the 1850s Haussmann tore up the medieval street grid and rebuilt the city around boulevards. Wide, straight, connected. The city was choking on dirt roads built for carts.
The boulevards went down before the traffic that would justify them. Trains, buses, trucks. None of it existed at scale when the pavement was laid. And it worked. Paris absorbed every new mode of transport without ever cutting a freeway through the center of the city, because the streets were already shaped for a load nobody had seen yet.
Also worth mentioning: Haussmann built the boulevards wide so they could never be barricaded. Les Misérables was based on real events, and Paris had a DDoS problem: narrow streets favor whoever has the paving stones. Wide, straight boulevards meant the military could always move through the city. That is why those streets exist, and it makes the design lesson honest: infrastructure is never neutral. It is built for whoever the builder expects to move through it.
So London can patch a bridge designed for 1887 today and still end up with a closed bridge. Hammersmith is shut for maintenance right now, and the traffic did not disappear. It moved to Putney Bridge, the next crossing on the Thames, which is now carrying strain it was never designed for either. Load does not wait for the fix. It reroutes to whatever is still standing.
Paris prepared for the onslaught of traffic that had not yet arrived, and its infrastructure held. That is the actual choice in front of anyone building infrastructure right now: patch for the traffic you had, or build for the world that is coming.
The traffic that is coming is agents. And the question is not whether the load is real. The question is who you are building the streets for, when everything now runs through a token.
And the load is partly our own doing. The first half of 2026 was tokenmaxxing. Leaders told developers to use as much AI as possible, usage leaderboards went up, and usage became a proxy for value. IBM already wrote the postmortem: tokenmaxxing is dead, long live valuemaxxing.
The answer is not token minimization either. That is the same mistake inverted. Both treat token count as the metric, and neither measures what the tokens bought. Valuemaxxing asks the better question: how many tasks were completed, how much time was saved, how much rework was avoided. Token consumption is a cost signal, not a value metric. Token efficiency is the foundation the next layer of AI infrastructure gets built on, because value per token is what decides which streets are worth paving.
Here is what that looks like when you apply it to your own spend.
Every session is a spend
I have spent the past few months building a Pokémon game with self-healing infrastructure tools. The write-ups are linked at the bottom. What follows is the part that generalizes.
Every session you run with Claude Code or Codex is valuable. You ideate. You go back and forth. You get stuck, or you finish a thread, and you open a new session.
What happens to the one you just closed?
Thariq at Anthropic has said that around 80% of the code he writes never ships. It is proofs of concept and development work that was never meant for production.
Read Thariq’s article on XThat number sounds right to me. But those sessions are not worthless. Some of those features were not ready this quarter and will be ready in six months. The work is done. The context is gone.
That is token slippage. You paid for the work. You cannot get it back. By default, Claude Code sessions are deleted after 30 days, so you are really spending on dead tokens while choosing to let that valuable experience die on the vine.
Markdown files are not the answer
The obvious fix is to write it down. Most of us tried that. Most of us now have 200 or more markdown files in a repo. No agent is slurping that up and finding the right one.
Skills are a better answer. A skill tells the agent when to load a specific file, when to inspect a specific part of the project, and when to grep for something. It is routing, not storage. This is context engineering: deciding what the agent sees and when it sees it, instead of dumping everything in a folder and hoping it finds the right file.
The problem is that we are not really building skills. We are using them. Nobody has solved managing skills at scale. Context engineering is still done by hand, one skill at a time.
Where I actually use this
The thing I look up most often in my old sessions is how to set up staging. I am not great at cloud native infrastructure. That is why I have a CTO. But I have done it, and every time I do it I go back through my sessions like blog posts, trying to reconstruct what I did and how to repeat it.
So I built a staging skill. Here is the whole thing:
---
name: prepare-and-promote-cloud-deployments
description: Use when deploying new versions of services to the cloud via
GitOps workflows. This skill involves preparing staging and production PRs,
validating changes, and automating the deployment process.
version: 0.1.0
tags: [cloud, deployment, GitOps, Helm, CI/CD]
type: workflow
sessions: [019f8b0a-5eea-75f0-9822-96aaefd60025]
---
## Prepare and Promote Cloud Deployments
1. **Research Deployment Mechanism**: Understand how your application is
currently deployed to the cloud, including version pinning and promotion
patterns.
2. **Prepare Staging PR**: Create a pull request that updates the staging
environment with the new version while keeping production stable.
3. **Build Promotion PR**: Stack a promotion PR on the staging PR that updates
the production environment and cleans up any old staging overrides.
4. **Validate Changes**: Before pushing, validate both PRs for correctness in
YAML syntax and confirm the changes reflect the intended deployment.
5. **Monitor Tags and Images**: Track the relevant Git tags and Docker images
so the correct versions land in the deployment.
6. **Push Prepared Commits**: Once the release image is confirmed, open the
staging and production PRs per your org's approval rules.
7. **Monitor Deployment**: After merging, watch the rollout across staging and
production.Look at the frontmatter. That sessions line is not decoration. The skill was generated from a recorded session, and it carries the ID of the session it came from.
Demo: Staging skill
This is the entire demo input. The skill is never named. It fires on the description, and the agent walks the staging PR and promotion PR without another word from me. The whole thing takes under 30 seconds.Prompt: Get this release into staging.
Notice what I did not do. I did not teach the agent a command. I did not point it at a file. The prompt went in and the routing did the rest. That is the boulevard. You do not teach the traffic the street plan. You build the streets wide enough and the traffic finds its way.
Check the tapes
Here is the limitation. I am not the person on this team with the best staging setup. My version works after a lot of back and forth with the agent. Somebody else got there faster and cleaner.
That is where orchestration matters. If my teammates’ sessions land in the same database as mine, I can ask a different question. Not “what did I do,” but “what did the person who is good at this do.”
“Check the tapes” is a skill I run constantly. When was the last time a teammate set up staging? What did that session look like? Build me the skill from theirs, not mine.
It is a skill like any other. This is all it takes:
---
name: tapes
description: Use when the user says "check the tapes", "search tapes",
"tapes search", or wants to look up past agent sessions. Starts tapes
services if needed and queries the local SQLite store at ~/.tapes/.
---
# Tapes
Query local tapes session data. The tapes SQLite database lives at
`~/.tapes/` and contains recorded LLM agent sessions across all projects.
## Trigger phrases
- "check the tapes"
- "search tapes for ..."
- "look up sessions about ..."
- "what did I work on ..."
## Search
```
tapes search "<query>" --api-target http://localhost:8081 --top 5
```
- Adjust `--top` based on how broad or narrow the user's question is
- Use `--quiet` when piping results to other commands like
`tapes skill generate`Routing, not storage. The skill does not hold any answers. It tells the agent where the answers live and how to ask.
Demo: Check the tapes
Prompt: Check the tapes. When was the last time someone on this team set up staging? Build me the skill from their session.
| Session | Status | Name | Model | User | Turns | Cost | Tokens | Duration | Active |
|---|---|---|---|---|---|---|---|---|---|
| 019f4262 | Completed | Review grove changes before releasematched turn ~/paper/groves/release | GPT-5.5 Codex | Maya Chen | 13 | $11.37 | 14.75M | 2d 3h | 18h ago |
| 019f39ce | Completed | Implement ClickHouse metering infrastructurematched turn ~/paper/groves/metering | Claude Fable 5+1 | Noah Williams | 21 | $175.80 | 122.15M | 2d 0h | 2d ago |
| 019f85a9 | Completed | Console access against staging setup ~/paper/groves/develop | Claude Opus 4.8 | Priya Shah | 20 | $44.86 | 63.55M | 1d 2h | 6d ago |
| 019f8b0a | Completed | Open staging PR for testing ~/paper/groves/deploy | Claude Opus 4.8 | Noah Williams | 4 | $6.13 | 7.50M | 31m | 6d ago |
| 019fa573 | Completed | Capture Claude fixture recordings for tapesmatched turn ~/paper/groves/extract | Claude Opus 4.8+1 | Priya Shah | 34 | $179.03 | 325.39M | 22h 17m | 2h ago |
Reflections
Claude Code shipped a feature called Dreams. It is documented, but it is gated to specific Team and higher plans. I wanted the concept without the gate, so I built my own.
It works in two layers.
First, reflections. A reflection is the recap of your day: the notes you put on paper before you start dreaming. In practice, it is a summary of a session. Compact, structured, and good for vectorizing. Reflections are what make a large session history searchable instead of theoretical.
Second, the agent reads across those reflections and reasons about what you did not ask for. You came in wanting a staging environment. Somewhere in the team’s history is a session about generating staging data. You did not know to ask. The reflections did.
That is the difference between a search index and a feedback loop.
Demo: Reflections
Prompt: I want a staging environment for the console.
Stand up a console staging environment
- youI want a staging environment for the console.agentStaging is up: console, tapes API, and gateway on an isolated slice. Production untouched.
- youIt looks empty. I need realistic data in it to test search.agentChecked the tapes. A teammate’s session already generated ad-hoc sessions for UI testing. Reusing that workflow instead of inventing one.
- youDo it, and verify search works against it.agentSeeded 40 sessions with matching turns from the teammate’s trace, then verified the search flow end to end against the staging data.
Session 019fb0c2 · Brian Douglas · Claude Fable 5 · 3 turns · 5.1M tokens · $6.84 · 38m. This is a concept of the reflections feature, not the shipped paper console.
The point
Hammersmith Bridge did not fail because someone built it badly. It failed because the load changed and the design did not. Haussmann’s boulevards still carry Paris because they were built for the load that was coming, not the load that was there.
That is the choice in front of us. The tooling we have was built for humans committing code. The traffic is agents running sessions. You can patch the bridge and post weight limits, or you can cut the boulevards now.
Paul Graham told a generation of founders to make something people want. The infrastructure version of that advice is due: make something agents want. Agents do not want your 200 markdown files. They want routing. They want shared session history. They want reflections they can reason across.
The loudest symptom is still the simplest one. Every session ends and takes its context with it. Skills are how you make that context reusable. Team sessions are how you make it more than personal. Reflections are how the loop closes.
Humans write things down so other humans can read them later. That is what paper is for. Agents want something else entirely: skills, shared sessions, reflections. A loop instead of a page.
That is what we are building. The way for you to put it on Paper Compute.
Previously: Agent Played Pokémon for 1,000 Turns, Logs Are the Self-Healing Feedback Loop
Related reading
Start with paper
Turn every session into knowledge at team scale.