Agentic Workflow Fatigue: Why Your Team Ships More and Enjoys It Less

 Quick Bridge: Your engineers adopted AI and got measurably faster. The velocity chart looks great, and a few of your best people seem strangely flat next to it. Nothing in the sprint data explains the gap.

A tired engineer sits at a dusk-lit office desk holding a small hand-built mechanical timer in the lamplight while four blank monitors on arms sit unattended behind her, and a man in a deep blue shirt stands at her shoulder looking at the object with her.

One of my strongest engineers asked if she could go back to writing a chunk of our test coverage by hand.

Not all of it. Just the part she used to like. She had been running three or four AI agents at once for a couple of months, shipping more than she ever had, and she told me the days felt like air traffic control. It was all watching and deciding, with nothing at the end she could hold up and say she made.

I did not have a good answer for her in the moment. The velocity chart said she was having her best quarter. She was asking to be slower on purpose.

Why Agentic Work Feels Like a New Kind of Engineering Burnout

Making something gives you a finish line you can see. A test that was red goes green. A design problem you have been circling for an hour finally gives way. You point at the thing and know you built it. Before the tools arrived, the day was paced by a steady supply of those, one every hour or two, and they added up to more than they looked like.

Steering a set of agents removes most of them. What is left is a mode the brain is not built to run for long. You hold three or four tasks in your head at once. You judge whether output you did not write is good enough. You trace which inputs produced it. You keep track of what is actually done against what only looks done. Then you assemble a shippable whole out of the parts.

None of that produces the small hit of completion that building does. It produces vigilance, which is tiring in a specific way. Watching a stream of mostly-fine output for the one costly error is one of the hardest things to keep doing well, and attention slides off it fast. Your engineer is not imagining the drain. The work changed shape, and the part that used to pay her back is mostly gone.

The Cause Is Not AI Output Quality. It Is the Operating Model.

The common explanation is that the model is not good enough yet, and people just need to prompt better or wait for the next version. Set that aside. Even when the output is solid, two things wear people down.

The first is the switching. Running several agent sessions at once means starting one, tabbing away while it works, picking up the next, and coming back to the first one half finished. Every switch leaves part of your attention stuck on the thing you just left, and it is worst when that thing was unfinished. With parallel agent tasks, all of them are.

The second is the management work nobody named. Running a set of agent tasks is a project-management job in everything but title. You break the work down, hand each piece to the right tool, decide whether what comes back clears the bar, trace what produced it, and track real progress against the look of progress. Then you pull it together into something you can ship. That used to belong to managers and project managers. Now it sits on every engineer, and nobody scheduled the training for it or the recovery time around it.

Underneath both is the same catch. You are handing work to something you do not fully trust, so you follow up on everything it returns. That is the load of running a team without the earned trust that lets a manager stop checking every line. You get the oversight cost and none of the relief.

I felt it myself recently. I spent an afternoon steering an AI through an analysis of employee survey data. It locked onto my first reaction to one bad number and kept circling how to avoid that outcome, and I had to keep redirecting it with sharper questions until it was useful. That loop, prompt and watch it drift and pull it back, took more out of me than doing the analysis by hand would have.

The Research: Progress, Not Hours, Is What Protects People

There is research under this, and it matches what I notice in myself. Teresa Amabile and Steven Kramer ran a multi-year study of daily work diaries, published in the Harvard Business Review article "The Power of Small Wins" (2011). They collected roughly 12,000 daily entries from 238 professionals across 26 project teams and seven companies. Their central finding: of everything that shapes how people feel and perform at work, the single most important factor is making progress in meaningful work. Small wins counted for far more than their size.

The part that matters for a leader is what came next. In a survey they ran alongside the study, 669 managers asked to rank what motivates employees put "support for making progress" last. The thing that most protects a team from burning out is the thing managers most reliably overlook. Agentic work runs almost entirely on half-finished parallel threads with very few clean completions, which is exactly the condition that drains people.

Sources and further reading: Teresa Amabile and Steven Kramer, "The Power of Small Wins," Harvard Business Review, May 2011. Annie Vella's longitudinal study, "The Productivity-Experience Paradox", which found productivity perception steady at 84% while the share of engineers reporting worse developer experience nearly doubled, and the correlation between flow-state change and productivity change fell to 0.02. Harvard Business Review, "When Using AI Leads to 'Brain Fry'", a survey of 1,488 workers in which supervising multiple AI outputs was associated with about 33% more decision fatigue and hit high performers hardest.

What Technology Leaders Can Do About Agentic Workflow Fatigue

This is individual work, not a structural program. The workday redesign is a separate piece. Here the job is helping each person carry the new mode, and it looks different for different people.

Give the recovery gap back, and say so out loud. The time while an agent runs, or the ten minutes after a hard call, is recovery doing real work. People will not take it if they expect to be asked why they were away from the keyboard. That question is most of what people are actually resisting about return-to-office. Tell your team plainly that time between tasks is expected and does not need to be accounted for.

Protect one piece of owned work per person. When the coordinating work drains me, I go build something end to end and it resets me. Make sure everyone on your team still has a piece of work that is recognizably theirs, start to finish, even a small one. If someone steers all day and finishes nothing with their name on it, that is the thing to fix first.

Coach the recovery skill instead of mandating it. Left alone, people fill the gap between tasks with another agent run or a scroll, and neither one restores anything. The skill worth coaching is noticing what you actually need in the moment, whether that is a walk, a hard problem worked by hand, or ten quiet minutes. You cannot require it. You can model it and talk about it in one-on-ones.

Try single-threading as an experiment. The switching is the core of the drain, so fewer live agent tasks at once is the change that most directly addresses it. Offer it as something to try for a week, not a rule. People land at different numbers.

The Fixes That Make Agentic Workflow Fatigue Worse

Some responses feel like action and quietly make it worse.

Declaring a company-wide no-AI day. It reads as taking away the tool people are measured on, and it does nothing about the switching or the missing sense of ownership on the other four days.

Standing up a wellness channel and calling it support. The drain lives in the shape of the work. A new Slack channel is motion, not a change to the work.

Telling people to prompt better. That turns a work-design problem into a personal skill gap. It adds a little shame and no relief, and the vigilance cost does not move.

Turning the ownership question into a metric. The minute "do you still feel like the work is yours" has a number attached and a target next to it, the honest answer goes away.

Cutting headcount because the tools made everyone faster. The oversight and integration work is real work. Removing the people who do it concentrates it on whoever is left, which is how the fatigue spreads.

On Monday, Start Here

In your next one-on-one, ask each person what they built this week that felt like theirs. Push past the list of what shipped to the thing they made and can point at. Treat a blank answer as a load signal, not a performance problem, and spend the rest of the hour working out where the building went.

Then look at your two fastest people. Count how many agent tasks each is running at once, and check whether either has finished and owned something in the last two weeks. If the answer is a lot and nothing, you have found the work worth doing this month.

If your team got faster with AI and flatter at the same time, what has each person actually finished and owned in the last two weeks?

You're great at the work. Let's make you impossible to ignore.

If you are working out how to keep your best people attached to work that feels like theirs while the tools do more of the building, consider reaching out.

jessestaffordcoaching.com

Comments

Popular posts from this blog

You Should Mix up Your 1-on-1 Locations

How to Get Manager Approval for Engineering Side Projects at Work: A Framework for Getting Buy-in for Technical Improvements

What Does a Good 1-on-1 Look Like?