AI is saving your team hours a week on paper. Almost none of it is showing up as shorter days. Here's where it's actually going, and how to design it out.
Workers report AI saves them roughly 11 hours a week. Glean’s Work AI Institute found they spend 6.4 hours a week on the unplanned work of making that AI output usable: supplying missing context, checking results, and fixing mistakes, a pattern it named botsitting. When that checking gets skipped instead of done, it turns into something riskier: shipping AI-generated work nobody actually verified. Neither problem gets fixed by telling people to be more careful. It gets fixed by naming who owns the checking, building it into the workflow on purpose, and measuring the rework instead of just the usage.
Picture an operations manager at a mid-size logistics company who rolled out an AI drafting tool for her client-facing team this spring. The pitch was straightforward: draft replies faster, spend less time on routine correspondence, get an hour of the day back. Three months in, she pulled up the team’s calendars expecting to see it somewhere. Meetings still ran to the last minute. Nobody left early. If anything, a few people were staying later, because now, on top of writing the email, someone had to read what the AI drafted, check the pricing was current, and rewrite the paragraph that sounded confident but was quoting last quarter’s terms.
That’s not a story about a bad tool. It’s a symptom of a specific, measurable pattern that doesn’t have much name recognition yet: the time AI saves doesn’t sit around as free hours. It moves. Most of it moves into checking, fixing, and re-explaining what the AI got wrong or didn’t know to begin with, work that never showed up on anyone’s task list and still doesn’t show up on most calendars.
Glean’s Work AI Institute put a number on that gap in its Work AI Index 2026, a survey of 6,000 full-time digital workers across the US, UK, and Australia. Workers report AI automation saves them roughly 11 hours a week. They also report spending 6.4 hours a week on the work of making that AI output actually usable, which is more time than they spend using AI to produce work in the first place. [1]
That’s the gap the operations manager was staring at without a word for it. The hours AI saved her team were real. They just didn’t turn into shorter days, because an unbudgeted second job filled the space instead. A few quick signs it’s happening on your own team, before the numbers below.
Glean calls that second job botsitting: giving an AI system the context it’s missing, checking its output, debugging its mistakes, rerunning prompts, and cleaning up the confident-but-wrong answers it leaves behind. It isn’t one task. It’s the accumulation of small, unplanned corrections that show up every time AI output meets the specific, messy details of a real job.
Harvard Business Review picked the term up in August 2026, in a piece by Rebecca Hinds, who leads Glean’s Work AI Institute, and Paul Leonardi, a technology management professor at UC Santa Barbara. Their opening example is a consultant who signed up for an AI scheduling agent expecting a clearer calendar and fewer interruptions, and instead got what he described as a second job: managing the agent he’d hired to manage his calendar. [2] One tool, one task, and still enough supervision to eat back most of the time it was supposed to save.
The name borrows its shape from babysitting on purpose, and it’s worth sitting with why. Babysitting is itself unpaid or underpaid, often invisible labor, and more than one outlet covering the term since has pointed out that the parallel isn’t accidental. [3] Naming a pattern does what good vocabulary always does: it turns a diffuse, private annoyance into something you can actually point at, measure, and put on someone’s job description instead of nobody’s.
Botsitting rarely announces itself as one obvious task on a to-do list. It shows up as five smaller ones, stitched into the gaps between the meetings already on the calendar. Here’s what each one tends to look like on an ordinary Tuesday, for five genuinely different roles.
| What it is | What it looks like in practice |
|---|---|
| Context feeding | A paralegal retypes the client’s real filing deadline into the drafting tool every single time, because it can’t tell a placeholder date in the template from the actual one. |
| Output verification | A finance analyst opens the source spreadsheet behind every AI-generated variance number before it goes in a report, because the number looks right whether or not it is. |
| Error correction and rework | A support lead rewrites a handful of AI-drafted customer replies most weeks because they answered last month’s version of the return policy. |
| Tool coordination | A recruiter copies a shortlist by hand from the AI screening tool into the applicant tracking system, because the two don’t talk to each other. |
| Improvised delegation | A marketing coordinator decides, on the fly, which social captions are fine to post as the AI wrote them and which need a human pass, a judgment call nobody ever wrote down. |
Five recurring, unplanned activities behind the botsitting hours. Definitions per Glean’s Work AI Institute; the role examples are ours. [1]
Look at that list again and notice what it isn’t. None of these five things are really about the AI producing bad work most of the time. They’re about work nobody assigned: who checks, who reconciles the two systems, who decides. That’s the part a manager can actually redesign. Whether the model itself is impressive has almost nothing to do with it.
None of this is a story about careless workers or an underpowered tool. It’s what happens, predictably, when a capable system gets dropped into a workflow built for a person doing every step, and nobody goes back afterward to redesign the handoffs.
Most AI rollouts stop at training. Someone learns which button drafts the email or which prompt pulls the weekly numbers, in principle. What rarely happens next is workflow design: deciding, on purpose, which parts of the task the AI now owns, which parts a person still owns, and how the handoff between the two actually works. Capability with nowhere defined to land turns into exactly what that operations manager saw on her team’s calendars: everyone quietly improvising the missing structure themselves, one email at a time.
Put simply, the tool that was supposed to serve the person ends up needing to be served instead, and it happens gradually enough that nobody notices until the hours don’t add up.
An original illustration of the botsitting cycle, built for this article. Workers spend an average of 6.4 hours a week somewhere in this loop, per Glean’s Work AI Institute. [1]
The effect isn’t spread evenly across roles, either. In Glean’s data, it’s sharpest among designers: 55% say the more they use AI, the less ownership they feel over their own work, the highest share of any function surveyed. [2] That’s worth naming specifically, because “employees use AI differently” is true but not very actionable. A designer losing ownership over creative judgment is a different problem than a paralegal retyping a deadline, and it calls for a different fix, not the same generic reminder to “double-check the AI” handed to everyone regardless of role.
This sits right next to something else we’ve written about: more AI subscriptions on the company card don’t automatically mean the work itself has changed, a pattern covered in our piece on the AI tool trap. Botsitting is what happens on the other side of that gap, once a tool is genuinely being used and the workflow around it still hasn’t caught up.
There’s a second term worth knowing, and it’s uglier on purpose. Botshitting is what Glean calls it when the supervision in botsitting gets skipped instead of done: shipping AI-generated work that hasn’t been properly checked, isn’t fully understood, and couldn’t be defended if someone asked about it. [1] The Work Management Institute picked up the same word to describe the same failure, and has since built out its own named framework around preventing it, worth a look if you want a fuller model of the governance side of this problem. [4]
Glean’s survey found 69% of AI users admit to at least one botshitting behavior, whether that’s shipping something they couldn’t explain if pressed, using a tool in a way that quietly breaks policy, or knowingly passing along output they suspected was wrong. [1]
The mechanism is the part worth sitting with, more than the number. Botshitting rarely starts as a decision. It starts as fatigue. Skip the verification once because a deadline is tight, and the output still looks fine, because AI output almost always looks finished whether or not it is. Skip it again, and the person gradually stops fully understanding what they’re shipping, stops questioning it by habit, and eventually stops feeling personally responsible for it at all.
It’s worth being fair to botsitting itself here, too. Checking an AI’s work, giving it context it’s missing, catching a mistake before a client sees it: that’s not overhead to eliminate. It’s the judgment part of the job, and it belongs to a person, the same way you’d want a person reviewing a junior colleague’s first drafts. The actual problem was never that this checking exists. It’s that it’s unplanned, unmeasured, and falls on whoever happens to notice, which is exactly the condition that turns into botshitting once people get too tired to keep noticing. That’s a different failure mode than the everyday risks of a careless prompt or an oversharing habit, which we’ve covered separately in how to use AI safely at work; botsitting is about the ordinary, structural tax of making any AI output usable at all, not about any single risky use.
The Work Management Institute has published its own named model for this, built around governance controls with their own branded terms, worth reading if you want the fuller framework. [4] What follows is a shorter, practical version, built from the same underlying logic but not a re-skin of it: decide who catches the mistake, give AI context on purpose instead of retyping it every time, build review into the workflow instead of leaving it invisible, and measure the rework instead of just the usage.
| Strategy | What it looks like this week |
|---|---|
| 1. Name one owner per workflow | Not “the team.” One named person catches mistakes on a given recurring AI-assisted task, reviewed monthly, so nobody’s guessing whether it’s theirs to catch. |
| 2. Build the context once | Save the brief, the style guide, the current pricing sheet, the data-source list, as a reusable file the AI is pointed to, instead of someone retyping it into a chat window every session. |
| 3. Put review inside the workflow, not after it | AI draft, then a named reviewer step, then send, written into the actual process, not “someone probably reads it.” |
| 4. Track rework as its own visible line | In a weekly check-in, ask what people had to redo this week because of an AI mistake, not just whether they used the tool. |
| 5. Treat a repeat mistake as a setup problem, not an output problem | If the same error shows up three times, fix the context, the prompt template, or the tool choice upstream, instead of just fixing that one output again. |
An original Future Factors framework, built from the underlying causes of botsitting, not a re-skin of any named third-party model.
Name who catches the mistake before you talk about which tool to buy.
Strategy two is where most teams actually get stuck, because it means building something once instead of repeating it every session, and that only sticks if there’s a real, reusable place to put it. If your team is already experimenting with Claude for this kind of work, that’s exactly the gap a properly set-up workspace closes: context, files, and standing instructions the AI can draw on without someone retyping the brief from scratch each time, the kind of setup covered in our piece on one coach’s Claude Cowork setup.
Where AI is genuinely doing part of the work here, it’s worth being explicit about which part stays a human decision, rather than just saying in general that a person is still involved.
| What AI does | What the human still owns | How it gets checked |
|---|---|---|
| Drafts a first-pass client email or report from a template and the day’s data | Deciding whether the numbers, tone, and specifics are actually right for this client | A named reviewer reads every draft before it sends, not a spot check |
| Summarizes a document, thread, or meeting | Deciding what’s actually decision-relevant versus just present in the source material | Whoever called the meeting or owns the thread confirms nothing material was left out |
| Answers a routine customer question from a knowledge base | Deciding which questions are routine enough to auto-send versus needing a human first | A weekly sample of auto-sent replies gets checked against current policy |
Measuring whether any of this is working means going past usage. Don’t stop at whether the team used the AI tool this week. Ask whether the correction rate is actually dropping a month later, without anyone having to remind people to check, which is persistence, and whether the output itself, the email, the summary, the schedule, is genuinely better or faster because of it, which is impact. A login count tells you people opened the tool. It doesn’t tell you whether the work got better.
If the five strategies above are the redesign, this is the five-minute version you can actually run this week, before any of the rest of it.
A copy-ready starting list, not exhaustive. The goal is naming where the hours are actually going, out loud, in the room.
Pick one of those five and ask it in your next team meeting, then actually write down the answers instead of letting them pass as conversation. That’s the whole start. The redesign in the section above comes after you know, specifically, where the hours are going on your team, not before.
Botsitting is the unmanaged work of making AI output usable: giving it the context it’s missing, checking its results, catching its mistakes, and re-running prompts until it’s actually right. Glean’s Work AI Institute coined the term in its Work AI Index 2026, a survey of 6,000 full-time digital workers across the US, UK, and Australia. It isn’t specific to one tool or one department. Anywhere someone hands a task to AI and then has to watch over it, whether that’s an email draft, a spreadsheet formula, or a scheduling agent, that’s botsitting.
Botsitting is doing the supervision: checking the output, catching what’s wrong, filling in context the AI is missing. Botshitting is what happens when that supervision gets skipped, when AI-generated work ships without being properly checked, understood, or defensible if someone asks about it. Botsitting is the tax on making AI usable. Botshitting is what happens once someone stops paying it, usually out of fatigue rather than a single bad decision.
Glean’s data puts it at 6.4 hours a week on average, roughly split into three pieces: about 2.3 hours feeding AI the context it’s missing, 2.2 hours checking its output, and 1.7 hours debugging mistakes once something’s gone wrong. That’s more time than the average worker spends using AI to actually produce something. It’s worth checking against your own team’s actual week, since averages across three countries and every function will run higher for some roles and lower for others.
Start with one recurring AI-assisted task, not the team’s entire AI use at once. Name who’s responsible for catching mistakes on that task, build the context it needs into a reusable brief instead of retyping it each session, and put review inside the workflow rather than treating it as an informal afterthought. Then ask at your next team meeting what people actually had to redo that week. Botsitting gets smaller when the workflow around the AI gets designed on purpose, not when people are simply told to be more careful.
Not by itself. Some checking and correcting is just what responsible AI use looks like, similar to reviewing a new team member’s first pieces of work. What’s actually worth worrying about is when nobody’s tracking the time it takes, when the same mistake keeps recurring without anyone changing the setup that caused it, or when people start skipping the checking altogether to save time, which is the slide into botshitting. Untracked, unmeasured botsitting is the real warning sign, not the existence of botsitting itself.
This article verifies its claims against primary sources: Glean’s Work AI Institute Work AI Index 2026 report page and its companion blog post (both published by Glean, the company that coined the term), Harvard Business Review’s August 2026 article by Rebecca Hinds and Paul Leonardi, and the Work Management Institute’s June 2026 article, which coined the related term botshitting. The HBR article is paywalled beyond its summary and opening anecdote; only what’s freely readable was used here, and no claim beyond it was made up. A widely syndicated Business Insider-attributed figure on job-hunting likelihood could not be traced to a single, independently fetchable primary source in this session and was left out rather than guessed at. Future Factors’ own mitigation framework in this piece is built from the underlying causes described in the research, not adapted from any single named third-party model.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.