Faster With AI, Fried by It: The Hidden Cost of Parallel Agents

On a busy day I have agents working on several things at once: a game port, a numerology app, this website, a client audit. Each of them is faster than I would be. By late afternoon I am slower than I have ever been. Not tired from doing the work, tired from checking on it.

Cole Medin named the feeling in a video published October 22, 2026. His argument: AI made us far more productive and quietly wrecked our focus, because supervising many agents means switching context all day. I agree with his diagnosis and most of his way out. I want to add what the research on switching actually says, what fifteen years of product leadership taught me about supervision, and the operating rules I use to keep a one-person company from turning into a full-time babysitting job.

Cole MedinAI Makes Us WAY Faster but Fries Our Focus (Here’s What I Do About It)

The fried-brain effect is a switching problem

The fried-brain effect is the exhaustion that comes from constant context switching between parallel AI sessions, not from the volume of work itself.

Cole opens with a post by Tibo, who describes spinning up agents all day and context switching far more than he did a few years ago. By evening, in the post's words, his brain is “completely toasted.” Tibo writes that almost every founder he talks to says the same, and Cole says he feels it too.

The mechanism he describes is simple. You send a request, the agent works for a while, so you start another. Then the first one needs input. Then the second. You never spend a solid block of time on one problem, so you never reach the state where you are fully in it. Cole misses coding for four hours straight with music on. He does not do that any more, because sitting with one task while an agent idles feels like waste.

That last part is the real trap. Cole calls it guilt: if you could ship ten times more, it feels like you should ship ten times more every day. Waiting for an agent to finish, when you know you could start something else, starts to feel irresponsible. So you start something else.

Scroll back up and watch it again. The shards do not get shorter because the work got harder. They get shorter because each new agent adds its own schedule of interruptions to yours, and you have no say over when they arrive.

What the research says about switching

Task-switching research shows three costs that compound under agent supervision: time lost to each switch, attention left behind on the previous task, and stress from compensating with speed.

None of this research is about AI agents. It is lab and field work on ordinary people switching between ordinary tasks. That is exactly why it is useful: it describes the human side of the loop, which the models have not changed.

• Switching costs time, and more for complex, unfamiliar work. In four experiments, Rubinstein, Meyer and Evans (2001) found that alternating between tasks cost time, and that the cost grew with the complexity of the rules involved. Switching into a less familiar task cost more than switching out of one. An agent session on a codebase you have not touched since Tuesday is about as complex and unfamiliar as a context gets.
• Unfinished work leaves residue. Sophie Leroy (2009) named attention residue: when you move on from a task you have not finished, part of your attention stays with it, and you do worse on the next one. Agent check-ins are, by construction, switches away from unfinished work. Every session is still running when you leave it.
• People absorb interruptions by speeding up, and pay in stress. Mark, Gudith and Klocke (2008) found that interrupted people finished tasks faster with no loss of quality, but reported more stress, frustration, time pressure and effort. That is Cole's title as a lab result: faster, and fried.
• Watching is work. A review of vigilance research by Warm, Parasuraman and Matthews (2008) concludes that sustained monitoring demands real mental work and is stressful, and notes it applies to human monitoring of automated systems. Supervising agents is not a rest between bursts of real work. It is the work.

Put those together and you get a shape, not a number. The simulator below makes the shape visible. The residue minutes are your estimate; the research supports the effect, not a universal figure.

Two things usually happen as you drag the agent count up. Your longest block collapses well before the agents run out of capacity. Then, past a knee, the agents stop gaining output, because they are queued behind you. That is the point where adding a session makes your day worse and the business no faster.

Supervision is a span-of-control problem

Supervising agents is management, and management has a span of control: the number of reports one person can direct well before quality drops.

I spent years in enterprise product roles before I became a solo builder. The lesson that transfers best is that nobody runs a team of eight engineers by answering each of them the moment they have a question. Teams run on cadence: a planning session, a daily check-in, a review at the end of the cycle. Questions batch up between those points, and most of them get answered by a better brief the next time.

Today's agents behave like brilliant new hires with no cadence. They work quickly, they ask whenever they need something, and they ask often, because they do not yet know how you work. Cole's point is that this is why we babysit: the harnesses are not yet good enough to leave alone for a full day. Mine is the corollary: until they are, you have to impose the cadence yourself, because the agents will not.

I have written before that the person who signs off becomes the bottleneck as execution speeds up, and that the honest unit is accepted work, not generated output. Switching is where that bottleneck hides. You do not feel review capacity running out; you feel tired.

My switching bill: 4 agent sessions × 2 check-ins/hour × 8h = 64 switches/day if I answer as they come (26.7 h/week reloading context at 5 min each). Batched into 4 review windows: 20 switches/day (8.3 h/week). Trade-off: agents wait ~60 min on average for me.

Batching is not free. The calculator shows the wait time it costs your agents, and at low check-in rates it shows batching losing. That is the right answer for some days. The point is to choose your switching bill instead of receiving it.

Cole's way out: invest in autonomy, not another session

Investing in autonomy means spending time making each agent run longer without you, instead of spending the same time opening one more parallel session.

Cole's most useful idea is about what to do with gains. Every time your harness gets a little better and an agent runs a little longer, the temptation is to fill the gap with another session. He argues for the opposite: take a short-term productivity hit and put the time into the larger harness, meaning the rules, the skills and especially the workflow where an agent plans, implements and validates in a loop on its own.

His version of that is what he calls a software factory. You agree the intent up front, letting the agent question you until you are aligned, and then the pipeline runs for a day or more and hands back a batch of work to review and test in staging. He is explicit that a generic built-in goal command is not enough in his view, because the babysitting you remove is specific to how you work and how you validate. He also expects two things to help: agents that act more like trained employees, and near-instant model responses, so you can stay in one primary conversation rather than hopping between several.

I think this direction is right, and I have watched it work at small scale. When I write a full brief for an agent lane, with the files it may touch, the check it must pass and the format of its report, the lane comes back with a report instead of a stream of questions. That is harness work in the plainest sense, and it is the harness getting better at the harness that compounds. The same logic sits behind designing the loop instead of the prompt.

Where I would push further is the objection Cole raises himself. Members of his community asked: what stops us from simply context switching between factories instead? He admits he does not have a full answer. Mine is that the constraint was never the number of agents or factories. It is how much finished work you can judge in a day. A factory that produces more than you can review just moves the pile. If you do not cap intake by review capacity, the hamster wheel gets a bigger wheel.

Close the loop before you switch

A ready-to-resume plan is a one-line note, written before a switch, that records where you stopped and how you will restart, so the unfinished task stops competing for attention.

This is the most practical finding in the literature and the least known. Leroy and Glomb (2018) ran four studies on interruptions. People who expected to return to unfinished work under time pressure struggled to focus on the interruption and performed worse on it. A brief plan for resuming, made before switching, reduced the residue and protected performance on the interrupting task.

For agent work, that maps cleanly. Before you jump to the session that pinged, write down where you were and the first move when you come back. You are not saving the task. You are giving your head permission to drop it.

Cole mentions a quieter symptom too: he catches himself procrastinating with chess, because it gives him the deep focus his workday no longer does. I recognise the craving. I would rather build a small, deliberate pause into the day than steal one. The toy below does both: park the thought, then take sixty seconds before you open the next context.

My operating rules as a one-person team

Operating rules are standing decisions about how you work with agents, made once so you do not have to make them under pressure every hour.

I run several ventures alone: a monetized app, a few games, this consulting site, a rental business. Agents are how that is possible at all. These are the rules that keep it from consuming every hour, and most of them came from noticing a specific failure twice.

1. The brief is the only context the agent has. I write it before I launch, with the goal, the files in scope, how the work proves itself, and what is out of bounds. A vague brief buys a dozen check-ins later.
2. Capacity is my review time. I launch only what I can review the same day. Unreviewed output is inventory, not progress.
3. One integrator. Parallel agents each get their own files. Shared files are touched by one integrator. Collisions are the most expensive interruption there is, because two contexts need fixing at once.
4. Review windows, not pings. Notifications stay off. I look at agents at set times and protect one deep block for the decision only I can make.
5. Reports have a fixed shape. What changed, how it was checked, what is blocked, what is needed from me. A fixed shape makes review a scan instead of a read.
6. Asks become backlog rows immediately. A chat transcript is not storage. If an agent raises something I cannot act on now, it goes into the backlog in the same session, so it stops living in my head.
7. Twice means fix the harness. The second time I correct the same mistake, I change a rule, a skill or a test instead of correcting it a third time.

None of these are clever. They are what any good engineering manager does with a team, applied to a team that never sleeps and never stops asking. Build your own version below; the defaults are mine.

# My agent operating rules

- Max parallel agent sessions: 3
- Protected deep-work block: 08:00–09:30 (90 min, no agents in view)
- Review windows: 09:30, 12:15, 14:45, 17:30

## Before I launch
- [ ] Write the brief first: goal, files it may touch, how it proves it worked, what it must not do.
- [ ] Launch no more sessions than I can review today. Capacity is my review time, not the agent's.
- [ ] Give each agent its own files. Shared files are changed only by the one integrator.

## While they run
- [ ] Notifications off. I check agents in review windows, not when they ping.
- [ ] Before switching, park a ready-to-resume note: where I stopped, first move back.
- [ ] An idle agent is not a debt. Waiting is fine; a second unreviewed session is not.

## When I review
- [ ] Every agent ends with a fixed report: what changed, how it was checked, what is blocked, what it needs from me.
- [ ] Turn every ask into a backlog row in the same session. A chat transcript is not storage.
- [ ] If I correct the same mistake twice, fix the harness (rules, skill, test) instead of opening another session.

## End of day
- [ ] Stop launching new work an hour before the end. Close loops, write tomorrow's first brief.

What I would tell a founder starting this week

Starting well with parallel agents means measuring your own switching before scaling your agent count.

Spend one day counting. Every time you switch to an agent, make a tally mark. At the end of the day, compare the count to how many hours you spent in blocks longer than thirty minutes. If the second number is near zero, you do not need more agents. You need fewer, longer-running ones, and a cadence.

Then pick one improvement to the harness, not one more session. A better brief template, a validation step the agent runs before it asks you anything, a report format. Cole is right that the in-between will not last forever. The people who come out of it in good shape will be the ones who used it to teach their agents how they work, not the ones who opened the most tabs.

Agents scale. Your attention does not. Design the day around the part that does not.

FAQ

Short answers to the questions I get most about agents and focus.

Want help designing an agent workflow your team can actually supervise? Let’s talk.

Sources

The video supplies the argument; the research papers supply the evidence on switching, residue and monitoring. Claims about Cole's own workflow and plans are his, as described in the video.

1. Cole Medin — AI Makes Us WAY Faster but Fries Our Focus (Here’s What I Do About It), YouTube, October 22, 2026
2. Leroy, S. (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Organizational Behavior and Human Decision Processes, 109(2), 168–181
3. Leroy, S. & Glomb, T. M. (2018). Tasks interrupted: How anticipating time pressure on resumption of an interrupted task causes attention residue and low performance on interrupting tasks and how a “ready-to-resume” plan mitigates the effects. Organization Science, 29(3), 380–397
4. Rubinstein, J. S., Meyer, D. E. & Evans, J. E. (2001). Executive control of cognitive processes in task switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763–797
5. Mark, G., Gudith, D. & Klocke, U. (2008). The cost of interrupted work: More speed and stress. Proceedings of CHI 2008, 107–110
6. Warm, J. S., Parasuraman, R. & Matthews, G. (2008). Vigilance requires hard mental work and is stressful. Human Factors, 50(3), 433–441