In 2017, a group of Google researchers published Attention Is All You Need. It taught machines to decide which part of their input deserved focus, and it led to the agents that now write a growing share of our code.
Those agents have flipped the title. Execution is becoming abundant. What does not scale is the thing the paper gave the machines: attention. Ours.
And it is all we have.
Abundant work, scarce judgment
In 1971, Herbert Simon warned that “a wealth of information creates a poverty of attention.” Replace information with agent output and you have a normal Tuesday.
One of us runs five to seven agent tasks in parallel on a normal day. More could be launched. They are not, because each one comes back: a question, a pull request, a failing check, a choice between two designs. How many agents you can run depends on how much your own mind can process.
The failure mode is not agents doing bad work. It is subtler. After a day of small interruptions, it gets easy to approve things we did not really read. The agents are still sharp. Our judgment is not.
So for anyone designing agentic workflows, and for engineers in particular, since we build the AI SDLC the rest of the team works in, the question changes from how much can the agents do? to:
How little of my attention does each good decision need?
Spend attention only where it changes the outcome
An agent can waste our attention in two opposite ways. It can ask about things it should decide on its own: a name, a format, a choice between two equivalent libraries. Or it can carry on past a decision it should have brought to us, and return two days of work built on the wrong assumption. The first drains us a little at a time. The second costs more later.
A better model does not fix either. Design does: explicit rules for when to continue and when to stop.
In Facility, the platform we use to take tickets to production, attention is a story state of its own, next to working and review, with one queue per project. When an agent needs a person, the work says so in one place, not scattered across a dozen chat tabs. Interruptions should be something the system budgets, not a side effect.
Timing is part of that budget. A production risk deserves an interruption now. A naming preference can wait for the end-of-day review, grouped with the rest.
And every time we do step in, it should make the next intervention unnecessary. One of us used to set aside a fresh moment each month to send an invoice: at least ten manual steps. Now a scheduled agent prepares everything, and the work is reviewing a draft and pressing send. When we correct an agent, the correction should become a check, a rule or a reusable instruction.
Make every request decision-ready
When an agent does need us, the request should arrive ready to decide.
One of our engineers gave their agents a strict report format: a TL;DR of two or three lines; what it found and did; the actionables, with pros and cons for every option; caveats; a plan; and an annex for terminology. Two rules make it work: everything must fit on one screen, and everything is numbered, so the answer can be as short as “go with 2.1.”
The general pattern: what needs deciding, why now, what the agent recommends, the alternatives, and the evidence, with the full detail one click away. Not “here is everything I did.”
Conciseness has one hard limit: never cut the fact that could change the decision.
Present it the way each head works
A colleague noticed that many of these tricks are really ways of adapting the work to how our heads work. Delegate the routine so it does not drain attention. Talk to agents in your own language: one of us switched to Spanish because reading that much text in English was exhausting. Ask for visual explanations.
That matters even more for neurodivergent people (ADHD, dyslexia, autism) and for anyone who struggles with walls of text, constant context switching or starting from a blank page.
For the first time, the format of a decision is cheap to change. In a recent internal discussion, one of us described a messaging tool we would like to have: send a ten-minute voice note, and the colleague receives it restructured visually, the way they think, with the original audio still there. Approving a workflow could work the same way: a comparison table, a diagram, or a short generated video that walks through each step.
Format is part of the decision interface. Two cautions. Offer formats instead of assigning them by label, and let people switch. And check understanding: a polished video can hide the detail that matters as easily as a wall of text.
Size parallel work to what you can integrate
More agents also means more decisions between their results. One of our engineers found three open pull requests that each rewrote the same database constraint, each adding its own new value. Each passed review. Git saw no conflict, because the migrations lived in different files. Whichever merged last would have dropped the values the others added, and the inserts that used them would have started failing.
Every review did its job. The risk lived between them, where no single review looks.
That is the real limit on parallel work: not how many agents you can launch, but how much of their output you can safely combine. You raise it by making integration the system’s job, before anything reaches a person:
- Check open work against each other, not only against main. Same function, same constraint, same migration, or a type check that only fails when two branches meet. The engineer who found this case is prototyping exactly that check.
- Resolve what is mechanical. When changes only add, like those three values, each pull request can carry the union and the merge order stops mattering. When they change logic, the agent proposes the fix.
- Bring one integration decision, not three approvals. “These three pull requests collide on the same constraint. Here is the combined version and the order.” That takes a minute to decide.
If integration still depends on someone noticing, adding agents adds risk faster than it adds output.
Design for the person who decides
Every agentic workflow now has two users: the agent that executes, and the human who decides. Until now, we have mostly optimized for the first.
Start measuring the second. How long does it take to understand a request? Which interruptions turned out to be unnecessary? Which questions came back twice? What needed correcting after approval? Asking these questions already changes how we design.
And do not spend all the attention you recover approving more output. Keep some for exploring, learning and asking whether the goal is still the right one. No agent will do that part for you.
Pick your noisiest agent this week. Count how often it interrupts you, rewrite its report so it fits on one screen, and list the questions it could have answered on its own.
Attention is all you have. Make it count.