AI Agents Made Me Faster. Then Attention Became the Bottleneck.

Prompting Made My Attention The Runtime

I was not trying to coin a term or build a framework. I was trying to stop being the scheduler for the agents I was working with.

I started with prompts. The prompts worked. That was the problem. In those early sessions, working with agents felt like the obvious next unlock. I could ask for help with code, product thinking, strategy, documentation, UI review, research, testing, and planning. The work moved faster. A lot faster. Problems that used to take days could be explored in an afternoon. Design ideas could turn into mockups. Bugs could turn into tests. A vague concern could turn into a research brief, a task graph, or a pull request.

It was exciting because it was real. This was not a toy use case. I was using agents inside product work, repo state, tests, real software systems, and technical and product decisions. It felt like a door had opened. The possibilities were endless. So was the backlog.

I found myself prompting late at night, sometimes in the middle of the night, just to keep the flow going. There was always another thing worth trying: a bug to fix, a feature to sketch, a product idea to explore, a process gap to close, a competitor to research. The models could help with all of it, which made it feel wasteful not to keep pushing. That was the strange bargain. I could get more done in a shorter period of time, but only if I kept feeding the machine. If I stopped prompting, progress stopped too.

But after the first wave of acceleration, something strange happened. I was still holding the whole thing together. The agents could help with almost anything, but they did not know what mattered next unless I told them. They could review a PR, but they did not know which PR was stale. They could write tests, but they did not know which behavior was under-tested. They could improve a process doc, but they did not know which process had just failed. They could research a market signal, but they did not know whether that signal should interrupt product work. They could do the work, but they could not reliably decide when the work should wake up.

That became the first real bottleneck. It was not model capability. It was attention.

The Lure Of Endless Possibility

When people talk about agents, they usually start with capability. Can the model code? Can it reason? Can it call tools? Can it handle a repo? Can it use a browser? Those questions matter. They just were not what broke first.

What started breaking was the operating model around the capability. Every session still required me to rehydrate context:

• What am I building?
• What changed yesterday?
• Which branch matters?
• Which PR is ready?
• Which docs are stale?
• Which decisions are mine, and which decisions can an agent make safely?

The agents were not sitting idle because they were weak. They were sitting idle because the work had no reliable routing layer. If I showed up and prompted well, the system felt powerful. If I did not, nothing happened. That sounds obvious until you feel it in practice. A day passes. Then two. There is plenty of capable agent labor available, but no one has inspected the open loops, noticed the stale PR, checked CI, or turned scattered signals into ranked work.

So the human becomes the runtime. I was the scheduler. I was the memory layer. I was the QA gate. I was the product router. I was the escalation system. I was the person remembering which conversations mattered, which docs were current, which branches existed, which work was blocked, and which loose ends had to be picked back up. The irony is that the agents were making me faster and more overloaded at the same time.

There is another thing that happens once agents become useful: the surface area explodes. Before agents, a lot of ideas die quietly because they are too expensive to explore. You might think, "I should compare this competitor," or "I should improve this onboarding doc," or "I should refactor that handler," but there are only so many hours in the day. The constraint is obvious. You move on.

With agents, the constraint gets blurrier. Suddenly every idea feels actionable. Every stale doc could be cleaned up. Every product surface could be redesigned. Every competitor announcement could be analyzed. Every test gap could become a ticket. Every rough thought could turn into a plan.

There was also a quiet pressure that came from the tools themselves. If I had access to these models, these subscriptions, these windows of capability, it felt like unused capacity was being wasted. Every hour I was not prompting felt like an opportunity slipping by. That made my focus more fractured, not less. There were suddenly ten useful things I could ask an agent to do right now. The hard part was no longer finding leverage. The hard part was deciding where to point it, and then staying present enough to keep the work moving.

That is intoxicating, and dangerous, because when almost anything can be started, deciding what deserves attention becomes the real work. The problem is not just "Can an agent do this?" The problem is:

• "Should this be done now?"
• "Does this move the work forward?"
• "Is this a real signal or just an interesting distraction?"
• "Will this create durable leverage, or is it another thread I now have to manage?"

More agent capability does not automatically reduce cognitive load. Sometimes it increases it. The more agents can do, the more possible work appears. Without a system for routing that work, the builder, engineer, or small team becomes a human switchboard for infinite possibility. That is a fast path to burnout. Not because the work is bad. Because the work is all plausible.

The First Lesson: Prompts Are Not An Operating Model

I still care a lot about prompting. Prompt quality matters. Clear instructions matter. Context matters. A well-scoped request can be the difference between a useful artifact and a pile of confident nonsense. But prompting is not an operating model.

Prompting helps an agent do a thing in a moment. It does not, by itself, tell the organization what to remember, what to inspect, what to verify, what to improve, what to ignore, or when to escalate.

That was the first shift in my thinking. At the beginning, I was trying to get better at asking agents to help. Over time, the more important question became: what operating layer would let agent work compound without turning me into the runtime?

The Ladder That Came Next

The rest of this series is about what I started building in response, and how that personal workflow grew into a broader operating model. The problem started as a personal one, but I do not think it stays personal for long. Once agents become useful, any founder or small team runs into the same question: how do you keep work moving without making a human the runtime?

The first clue was repetition. If I kept asking for the same thing, the prompt wanted to become a reusable capability. Repeated prompts became skills. Skills needed shared process and durable state in GitHub. Static docs needed loops. Loops sometimes composed into ordered workflows. And those workflows needed attention routing.

Each layer solved the failure mode of the layer before it. Each layer also exposed the next bottleneck. Eventually the question became very simple: what should run now?

That is why I started defining an Attention Operating System. Not because I wanted a fancy term, but because the problem had become specific. The system needed a way to inspect state and decide what deserves attention, what can be delegated, what should be scheduled, and what needs a human decision. The goal is not more notifications. The goal is reliable attention routing.

That is the beginning of what I mean by an Agent Operating System: not an operating system in the computer science sense, and not a claim that I invented the category. More like a repo-owned operating layer for agent-assisted work: state, attention, loops, stacks, evidence, feedback, and human gates. The harness can change. The operating model should survive.

Where This Series Goes

This series is the story of how I got here, and how the process grew from there. Not as a finished doctrine. Not as a victory lap. More like field notes from trying to make agents useful every day inside real software work.

The path looks like this:

1. AI Agents Made Me Faster. Then Attention Became the Bottleneck - how prompting created leverage, but also made human attention the runtime.
2. When Prompts Become Infrastructure - how repeated prompts became skills, and how skills led naturally into process docs, onboarding, GitHub Issues, PRs, roadmaps, and shared operating context.
3. Loops, Attention, and the Agent Operating System - how recurring work got triggers, verifiers, stop conditions, evidence, escalation, and an attention layer that decides what should run next.

The next post starts with the first step up that ladder: the moment repeated prompts stop feeling like chat and start looking like infrastructure.

The broader thesis is simple: Agent-first teams will not scale by writing better prompts alone. They will scale by building better operating systems around the agents. That starts with a very human realization: if the agents are capable but nothing moves unless you prompt them, the bottleneck is not the model. The bottleneck is attention.