The attention budget

Every stage of working with AI has had a different thing that runs out first.

Early on it was knowledge. The models were capable, but almost nobody knew how to talk to them. The skill was figuring out what a model could actually do, how to prompt it, where it quietly broke. If you learned that faster than the people around you, you got more out of the same tool than they did.

Then the constraint moved to tokens. Once you knew how to drive the models, the limit became how much they would let you do: context windows, rate limits, monthly caps. If you worked at the edge of what agents could handle, you spent real energy staying under the ceiling, batching work and trimming context until a limit reset. The token budget was the thing you managed.

That limit is fading. Windows are large, models are fast, and running several agents at once is normal now. The ceiling moved again, and this time it landed somewhere less comfortable: the thing that runs out first now is my attention.

The attention budget

I have started thinking about it as an attention budget. It is finite, it drains through the day, and every context switch spends some of it. Unlike tokens, I cannot buy more and I cannot raise the cap. I get roughly one human's worth of focus per day, and agentic work is very good at demanding more than that.

Here is the asymmetry that causes it. Starting an agent is cheap. Supervising it is not. I can kick off five pieces of work across three projects in a few minutes, but I cannot actually watch five things well at the same time. Each one wants something from me at an unpredictable moment: a decision, a review, a nudge when it wandered off, a check on whether the diff is safe to ship. The agents scale. My attention does not.

So the scarce input is no longer how much the models can produce. It is how much of what they produce I can meaningfully digest and steer.

Half watched agents are the real cost

The tempting move is to run more agents and skim all of them. It does not work, and the first issue of this newsletter was about exactly why: the agent is fast and often plausibly wrong, and the thing that makes fast safe is a human paying real attention at the right moments. Attention is not overhead on the work. It is the work.

When I spread my focus too thin, I do not get five projects moving. I get five projects that each received a shallow, distracted version of the judgment they needed. The failure that slips through is almost never in the agent run I followed carefully. It is in the one I skimmed while three other agents were also asking for me.

The agent harness makes it more expensive

The obvious response to all this is to build a harness. Once you are running many agents, you start adding machinery around them: retry loops, verification steps, orchestration scripts, agents that review other agents, triggers that kick off work on their own. You automate the mechanics so more can happen without you babysitting the agents.

It works, and that is the trap. A good agent harness raises how much real work runs while you are not watching. But none of it escapes your judgment in the end. It just arrives later, in bigger batches, and further from the cheap moment where a quick correction would have fixed it. The harness buys throughput by spending attention, and it often spends it faster than the hand work it replaced.

So automation does not refund attention. It concentrates it. The more mechanics you hand to the harness, the more every remaining human checkpoint carries, and the more it costs when you get one wrong.

Spending it on purpose

Once you treat attention as a budget, the question stops being "how many agents can I run" and becomes "where does my attention need to go, and how do I keep the rest from stealing it." A few things help:

• Decide in advance what you will not watch closely. Low blast radius work gets tests and a light review, not your live focus.
• Make agent output cheap to digest: good summaries, small diffs, and tests as the trust boundary, so you can judge a change without rereading it.
• Batch the interruptions. Reacting to every agent the instant it pings is how a whole day vanishes with nothing finished.
• Point your best attention at the highest risk change, not the loudest one.

Summon

This is the problem I am building Summon for.

Summon is still early, so treat this as a look at the current build, not a launch announcement. The first surface is called Attention. It tracks work across agent runs and projects, then groups it by what it needs from me now: decisions, failures, waiting items, and active work.

That sounds small, but it changes the shape of the day. Instead of scanning terminal tabs, browser windows, GitHub threads, and half remembered agent runs, I get one queue ordered around the question that matters: where does my attention need to go next?

The current view lets me filter by source, including Claude, Codex, and Shell. That matters because not all waiting work has the same cost. A Codex task that likely needs a product decision is different from a shell task that is still running, and both are different from a failed verifier that needs immediate diagnosis.

I am still shaping what belongs in Summon and what does not. But the core belief is fixed: if attention is the real budget now, it deserves a tool as much as tokens and code ever did.

The constraint keeps moving

Every era of this work has rewarded the person who noticed the new constraint first. Knowledge, then tokens, now attention. The teams that win the next stretch will not be the ones running the most agents. They will be the ones who are deliberate about where a human's focus goes, because that is the thing that is genuinely scarce.

That is what the attention budget is really about. And it is why I am spending some of mine building Summon.