Your Attention Is the Bottleneck, Not Your Agents A developer argues that human attention, not agent capability, is the bottleneck in AI-assisted workflows. While agent capacity and compute costs are dropping, the fixed resource of human review time limits productivity. The author advocates designing systems that minimize attention spent on agent outputs. Your Attention Is the Bottleneck, Not Your Agents I run a handful of bots that do real work without me watching. An inbox classifier drafts replies to forty-odd emails a week. A blog assistant writes posts, makes the images, and opens pull requests. Devin ships code from a one-line Slack message. People keep asking the 2023 question: can the agents do the work? Mine do enough of it that the question lost its pull. The useful question now is simpler. I can spin up another agent this afternoon. I cannot spin up another me. Agent capacity is cheap and gets cheaper each quarter. My attention stays fixed at one human, and it does not scale with the number of bots I point at a problem. The scarce resource in my whole setup is the number of times per day I can look at something and decide. Compute and context windows matter. Model quality matters too. The review slot they cost me matters more. I gave a talk on this at AI Engineering London called Untethered Productivity /blog/aie-london-untethered-productivity . The one-line version on stage: the agents scale, you don't. This post is the argument behind that line. If you want the stage version, here's the recording: I stopped thinking of myself as someone who builds agents. I build an attention budget: a system whose job is to spend my looking on the few things that need a human and to keep the rest away from me. The loop ends when the agent produces output and costs me the right amount of attention to ship it. The cheap thing and the scarce thing The two curves go in opposite directions. Providers keep driving down the cost of an agent doing a unit of work. A year ago at WorkOS we couldn't get a Devin session to finish a real multi-file refactor and we killed the trial; now Devin ships PRs my team merges each day /blog/devin-has-come-a-long-way . Tokens are cheaper. Context is longer. I can run several agents in parallel without thinking much about the marginal compute bill, and that trend only moves one way. Agent work used to be the constraint. That constraint keeps lifting without my help. The cost of me reviewing a single artifact is roughly flat. It takes me about the same thirty seconds to do a first pass on a small PR in 2026 that it took in 2024. What changes is volume: more agents, bigger diffs, more things in the queue, and still the same hours, the same one stream of attention, the same single point of judgment. Ten agents producing output give me ten things to look at and one me. A system with one input dropping toward free and one input fixed will strain at the fixed input first. Each design decision I make becomes a decision about that fixed input. I ask how to spend the least attention to get a result I'll stand behind. Capability stopped being the bottleneck a while ago. I kept optimizing it out of habit. Attention enters the loop in three places If attention is the budget, I need to find each place I spend it. In my agents, I budget for three buckets with different price tags. The spark is me pointing the agent at a problem: the Slack message, the prompt, the idea. I borrow the word from the forge metaphor I wrote about in I Am the Spark, the Bellows, and the Quench /blog/spark-bellows-quench . The spark is the first fire you strike by hand, the part no pipeline reaches. It costs a little attention, and it's the right place to spend it, because it's the part only I can do. The agent is the bellows after that: directed pressure on the ember, the mechanical middle I happily hand off. The gate is the automatic decision about whether an action needs me. The budget leaks at the gate. If each action an agent takes routes to a human, you've built an expensive way to do the work yourself. The quench is the review: me looking at a finished artifact and deciding whether it ships. In the forge, the quench is the hiss where workable steel turns hard and permanent, and it's also the test: get the earlier steps wrong and the blade cracks right there in the bath. Same here. This is the most expensive attention in the system, and everything upstream exists to make sure only the things that need it arrive here. Attention-budget design moves work out of the third bucket. Each action you can push into "runs unattended" with confidence is attention you get back. Each action that has to reach you is attention you spend on a crowded day. The agents are cheap. The looking is what you're rationing. The gate is where the budget gets set I have one rule that decides what reaches me, and I wrote a whole post on it: the autonomy boundary /blog/the-autonomy-boundary . An agent can do anything reversible on its own; anything irreversible or outbound stops for a human. I framed that as a safety rule. I use the same rule as an attention-budget rule here. The boundary shapes my day. The inbox classifier drafts replies every five minutes on a schedule, and I don't think about it, because a draft sitting in a Gmail thread is reversible and inbound. It costs me zero attention until I choose to spend some. The blog bot drafts unsolicited posts and opens PRs, and a bad one costs me one click to close plus whatever compute it burned. This post tripped its own gate on the way to me: the image checker caught a draft that referenced a .png the generator had saved as .jpg , and the voice scan flagged a paragraph crammed with too many em-dashes. The bot fixed both before the PR existed, so neither reached me as a question. I don't want to find that class of mistake during review. Those errors are boring, binary, and beneath a human's attention. A broken draft on a branch is the cheapest kind of failure there is. Devin burns a VM all night writing code. None of that touches my budget. It all lands as reversible artifacts that wait. Then a small set of actions hit the gate and stop: a sent email under my name, a merged PR that publishes to my domain, anything that spends my reputation or can't be undone without mess. Those get my attention, on purpose, because that's the half of the work where a mistake is expensive. The boundary points autonomy at cheap-error work and reserves my thirty seconds for reputation-risk work. Reversibility is the simple version of the test. In practice I also stop anything with a big blast radius even when it's undoable on paper, because restoring a wiped table or unwinding a money move costs me far more attention than the action saved. The attention math has the same lopsided shape as the safety math. Auto-approving an outbound action saves me ten seconds of clicking. The downside is reading a retraction email and rebuilding trust with a stranger, which costs me hours and a chunk of reputation. You don't spend a fixed, scarce resource to save a trivial amount of a cheap one. Gate on reversibility and your attention flows to the actions that have earned it. Make the artifact cost less to review Moving work out of the review bucket is half the job. The other half is making the stuff that does reach you cheap to look at. I build agents that open PRs instead of agents that chat /blog/build-agents-that-open-prs for that reason. A chat reply makes me the storage layer, the validation layer, and the merge button at the same time. I have to read it, judge it, and move it somewhere it matters. That's three attention costs stacked into one ambiguous blob. A pull request gives me a diff I can scan, with a gate that already ran and a reject button as the default. The gate in front of the artifact does attention work before I look. My blog bot runs verify-blog-post.sh before it's allowed to open a PR. The script checks the boring, falsifiable things: files present, every image URL returns 200, every internal link resolves, zero banned phrases, the OG image is live. A script can check all of that. Without the script, I would spend that attention by hand. The script handles it, so a PR that reaches me leaves attention for the thing a script can't check: is it true, is it good, do I stand behind it. verify-blog-post.sh — exits 0 iff every check passes 1. metadata.json present and valid 2. page.mdx present, word + image counts meet the floor 3. hero image returns HTTP 200 on the CDN 4. every inline CDN image returns HTTP 200 5. every internal /blog/