How to Stop AI Workslop From Overloading Your Small Team

AI workslop arrives looking finished. A proposal has an executive summary, a sensible structure and confident recommendations. Then someone tries to use it. The numbers need checking, the customer context is missing, and nobody can explain why the recommendation follows from the evidence.

In a small team, the person doing that repair may also be the founder, account lead or only subject specialist. The author has finished drafting, but the work has barely started for its recipient. When this keeps happening, asking everyone to produce more with AI can make the review queue longer.

What is AI workslop, and what is a useful draft?

The term comes from research by BetterUp Labs and Stanford Social Media Lab.

An unfinished document is not automatically a problem. A colleague can reasonably ask you to challenge an early idea, help resolve an uncertainty or review an unfamiliar technical detail. Collaboration requires people to show work before they have every answer. The request becomes unfair when its apparent readiness conceals how much work remains, or when the recipient is expected to supply the reasoning the author was responsible for doing.

These distinctions apply to AI-assisted emails, meeting notes, plans, analyses and presentations. An approved tool can still produce weak work. A short note can also waste time if it omits the decision somebody needs. Length, grammar and a professional tone tell you very little about readiness.

Keep tool approval and data boundaries in the separate conversation about shadow AI. Here, the immediate question is whether the work meets the standard agreed for the next person in the chain.

What does the research actually show?

The BetterUp survey also reports roughly two hours spent resolving an incident. Those are recipients' reports, not an audited count of AI files or a prediction for every company. They do not mean that 40% of all work is poor, or that every employee loses two hours each day.

A 25 August 2026 experiment from Atlassian Teamwork Lab examined a different problem. Among 903 knowledge workers reviewing a proposal with deliberate flaws, AI polish reduced flaw detection and willingness to critique. An early-draft cue paired with an explicit feedback request largely reversed the effect. The public report describes one constructed proposal, and the effect differed by experience and role. It does not establish that a label alone fixes review quality in every workplace.

Other studies show where AI assistance has helped. Generative AI at Work studied a staggered rollout to 5,172 customer-support agents and found an average 15% increase in resolved issues per hour. Gains varied across workers. That is evidence of useful assistance in a specific operating setting, not a promised return for every document or team.

A field experiment with 776 professionals at P&G also found that AI-assisted individuals could match teams without AI on the studied innovation tasks. AI can contribute useful perspective. A manager should preserve that value while checking what happens after an output leaves its author.

The practical recommendations below are an editorial synthesis of these findings and ordinary management decisions. A hypothetical example makes the decisions concrete. Adapt the suggested handoff template and trial length to your situation; these studies have not validated them as a protocol.

Where does the extra work go?

Start with a recent handoff that felt more expensive than it should have been. Ask the recipient what they had to do before their own work could begin. Did they need a missing input, an explanation of the recommendation, a source for a claim or permission to ignore irrelevant sections? Their answer is more useful than a general complaint that everything sounds AI-generated.

A meeting summary illustrates the difference. Clean prose may accurately describe what was discussed while failing to distinguish a suggestion from a commitment. The project lead then checks the meeting notes, messages participants and rebuilds the action list. Typing took less effort, but the coordination work remained unfinished.

A recommendation can create another kind of repair. The author lists plausible options but does not choose one, explain the trade-off or say what would change the decision. Their manager supplies all three and sends the document back. If this becomes routine, the manager is effectively writing the difficult part of every proposal.

Sometimes the missing input belongs elsewhere. A sales colleague may lack access to delivery capacity, or a junior analyst may need an expert to interpret a result. Treat that as an access or collaboration requirement. Make the dependency visible and assign it. Calling every missing answer workslop would punish legitimate requests for help.

When the same person continually absorbs the gap, inspect work that has accumulated without a clear owner. Adding an approval step will not create capacity or settle responsibility. It may simply formalise the rescue work that already happens at night.

Follow one handoff through to completion: who created it, who received it, what remained unresolved and what finally made it usable. That keeps the discussion tied to work you can examine together.

What must be clear before a handoff?

Write the standard around a real recurring deliverable. A blanket instruction to check all AI output is too vague to use under pressure. A requirement that every client proposal identify the approved scope, evidence for its claims and the owner of each commitment gives people something concrete to inspect.

For a routine internal update, a few lines may cover all of this. A consequential recommendation may need the note above a fuller analysis. Do not make every person complete a long form for every message. Remove a field if it never changes what the recipient does, and add detail when an actual recurring failure justifies it.

Source checks deserve particular care. NIST's Generative AI Profile describes confabulation, including false content and misleading logic or citations. Check whether a cited source exists, supports the statement and applies to this case. A real link to a real report can still fail the last two tests.

A note saying "AI-assisted" does not answer those questions. If disclosure helps review, describe the assistance and the human check: "AI drafted the structure; I checked the figures against the approved report. The capacity assumption still needs the delivery lead's input." That is useful information about the document. A pasted prompt history usually is not.

Agree when the author must return with a recommendation and when exploratory work is welcome. Otherwise, people may hide uncertainty to appear competent. A clear early-stage request makes it possible to ask for help without claiming the work is ready.

What does a better client proposal look like?

Imagine an account manager preparing a proposal for a customer who wants faster onboarding. The draft recommends a self-service programme, a new launch sequence and a shorter implementation window. The writing is clear, but a claim that similar customers reduced support demand by 30% comes without evidence.

The delivery lead cannot approve it. The customer has not agreed which teams will take part, the implementation window has not been checked against capacity, and the claimed reduction may be invented or irrelevant. Before approving it, the recipient must investigate assumptions presented as a recommendation.

Do not ask the author merely to make the language more specific. Return the work with the precise gaps: remove or verify the support claim, check the delivery window with its owner, and explain which onboarding problem the proposal is intended to solve. Until those points are resolved, mark the document as a draft for discussion.

The revised note is shorter and makes its unfinished parts clear. It gives the delivery lead a bounded question. The account manager still owns the recommendation and the remaining checks. Nothing is promised to the client until the people responsible for delivering it have agreed.

Now consider the alternative: the founder quietly fixes the proposal and sends it. The customer may receive an acceptable document, but nobody learns which part of the handoff failed. Without seeing the correction, the author may repeat the same omission. If urgency makes a rescue necessary, make the correction visible afterwards and return ongoing responsibility to the author.

The 30% figure in this example is deliberately unsupported; it is not a research finding or a Cooperly customer result. The point is to recognise how a plausible number can become a promise simply because it survived the drafting stage.

How much review does each kind of work need?

One universal approval queue is a poor answer to AI workslop. It asks a scarce reviewer to inspect everything, including items they cannot meaningfully judge. It also encourages authors to treat approval as the moment someone else takes responsibility. Define which decisions require review and what that review is meant to establish.

Research on the uneven boundary of AI capability in consulting tasks helps explain why review must follow the task. In a study of BCG consultants, AI helped on some assignments but reduced accuracy on a task requiring people to reconcile numerical evidence with interview context. A tool that improves wording may still produce a weak interpretation.

Give the reviewer access to the relevant evidence, authority to stop the handoff and time to do the check. If any of these are missing, adding their name to an approval field creates an appearance of oversight. A person cannot verify a claim they cannot inspect, and a sign-off is not proof that the reasoning is sound.

For repeated low-consequence work, sample completed handoffs to identify recurring defects. Sampling can inform improvements; it cannot replace a required check on a consequential item. When an error would be costly or hard to reverse, the relevant checks belong before the work is used.

An AI critique can help an author find possible weaknesses. Treat it as another input. Agreement between generated answers does not establish that a source is real, a calculation is correct or a commitment is authorised.

How do you raise the problem with an employee?

Open the document together. Choose an example you can both examine: an unsupported claim, a missing decision or an action assigned to someone who never agreed to it. Explain the practical consequence. "I had to contact three people to find out which actions were agreed" gives the author a clear problem to fix.

An opening could be: "This summary reads clearly, but it does not separate decisions from ideas. The team cannot use it to plan the next step. Please verify the action list against the meeting record, confirm the owners and mark anything still unresolved. What got in the way of doing that before sending it?"

Then listen. The employee may have misunderstood the expected stage, lacked access to the source, been asked to move faster than the work allowed or assumed that a manager wanted to shape the recommendation. Each explanation calls for a different response. Establish what happened before deciding that the problem is effort or judgement.

A Microsoft Research study of 319 knowledge workers found associations between confidence in generative AI and self-reported critical-thinking effort. This was a survey, not proof that AI causes permanent loss of skill. It supports asking what was actually checked rather than treating confidence in an answer as evidence that the answer is reliable.

If the gap is a skill, demonstrate one check and let the employee complete the next. If the gap is capacity, reduce the volume or change the deadline. If the standard was unclear, document an acceptable example. If a clear, achievable standard is repeatedly missed after support, address the pattern through your normal performance process with specific evidence.

Use timely, constructive feedback so the correction arrives while the work is still fresh. Keep "workslop" as a description of a handoff problem; turning it into a label for a person will make the next conversation harder.

What if the manager is creating the workslop?

A founder shares an AI-generated strategy document late in the evening. It contains new priorities, ambitious dates and confident language about the market. On the next working day, one person treats it as a brainstorm, another starts changing the project plan, and a third assumes their current work has been cancelled. The cost comes from the authority attached to the message.

Before sending it, write the decision status in plain language: "These are ideas for discussion. Current priorities remain in place. I want your view on the customer problem and the trade-offs before we decide." If the direction is already settled, say what changed, why, who owns the change and what existing work should stop.

Invite questions about your own handoffs. Ask a colleague which part of the last plan required them to infer your meaning or repair the argument. Make it possible to return an unclear brief without turning that return into a debate about commitment. The standard only works when people can apply it upwards.

Watch what you praise. If you celebrate the number of documents produced or insist that every task must involve AI, people have a reason to optimise for visible activity. Praise a useful recommendation, an uncertainty identified before it became a commitment, or a concise update that saved its recipient a clarification meeting.

There is also a workload decision for the leader. Faster drafting can create more proposals than the team can evaluate or deliver. Choose what should enter the queue and which decisions matter now. Otherwise, the reviewer has to choose priorities as well as check the work.

If you regularly rewrite everything yourself, revisit the decision boundaries behind a founder bottleneck. The aim is to make authors and reviewers effective within their roles, with enough context to act.

How do you keep review from becoming a bottleneck?

A practical starting point is one accepted deliverable with annotations explaining why it worked. Show which evidence mattered, why the recommendation followed and which uncertainty remained acceptable. This is more useful than circulating a generic instruction to use better judgement. It lets a colleague compare their draft against an actual standard.

Ask the author to explain the recommendation briefly in their own way. A spoken walkthrough, a short written rationale or an annotated document can all work. You are checking whether the reasoning is available for discussion. Avoid making fluency under pressure into a test of competence or assuming that someone who uses writing assistance cannot understand their work.

For a junior colleague, separate learning from final approval. Give them a bounded task, let them attempt the reasoning, and discuss any gaps before they polish the draft. An AI tool may help them explore an unfamiliar topic, but they still need feedback from someone who knows which parts matter in this business.

Keep the recurring sources easy to find. If five people independently ask a model for a policy that already exists internally, better access to the approved policy may remove more rework than another prompting session. Someone must own the source and keep it current. A tidy library of outdated examples simply moves the problem upstream.

When review volume rises, ask whether the team needs every proposed output. Can one decision note replace a slide deck and a separate report? Can an early conversation settle a question before someone generates a lengthy analysis? Reducing unnecessary deliverables is a valid response to AI workslop.

Check who pays for the improvements. Mentoring, maintaining examples and updating source material take time. Assign that work openly and adjust other commitments, rather than assuming the reviewer will squeeze it around their existing role. A cleaner handoff process should make expertise easier to use without making the expert permanently available.

How do you measure whether AI is helping?

Start with the question the business needs answered: did this process produce a usable result with less total effort, or improve quality enough to justify the effort? Time to a first draft is one part of that question. A document can arrive sooner while the decision it supports takes longer.

METR's early-2025 developer experiment illustrates the difference between felt and observed speed: experienced developers working in familiar repositories believed AI helped, while measured completion took longer in that setting. Its February 2026 follow-up explicitly describes selection and measurement problems that prevented a reliable updated estimate. Neither result supplies a general verdict on present-day AI productivity.

Use a simple hypothetical calculation. A manual process takes 90 minutes of author work and 20 minutes of review, for 110 person-minutes. An AI-assisted version takes 25 minutes to draft, 20 to verify and 25 to review, for 70 person-minutes. If it also needs 50 minutes of repair, total effort becomes 120. The first-draft saving is real in both cases; only one version saves total effort.

These invented timings explain the arithmetic. They are not a benchmark, a business forecast or proof that a particular tool helps. Person-minutes also differ from elapsed time: two people can work in parallel, and a short review can wait days in a queue. Record both when the delay matters.

Tell the team what you are measuring and why. Avoid covert individual productivity rankings or counting every AI interaction. Look for workflow patterns, keep sensitive content out of the log and discuss ambiguous results with the people doing the work. A rough sample is useful for deciding what to investigate next; it cannot establish a precise productivity percentage for the whole company.

What can you change over the next two weeks?

1. 01

   Choose a handoff with visible friction

   Pick a recurring client update, project brief, meeting summary or recommendation. Ask both sender and recipient where work becomes unclear or requires repair. Use a recent example with permission and remove sensitive details from any shared discussion.

2. 02

   Agree the minimum usable result

   Write the decision or action the handoff should support. Add the necessary evidence, stage, owner and review request. Choose an accepted example. Confirm that the author has access to the information and time needed to meet the standard.

3. 03

   Try the standard on real work

   Let authors use approved assistance within existing data rules. Have them identify completed checks and open questions before review. Ask recipients to return specific gaps rather than silently rebuild the document. Keep required approvals in place.

4. 04

   Review effort and defects together

   Compare similar completed items, including checking, review, repair and waiting. Discuss exceptions. If the sample is too small or the tasks differ materially, extend observation instead of announcing a percentage improvement.

5. 05

   Keep, adjust or stop the change

   Retain fields that helped someone make a decision. Remove unnecessary process. If AI assistance adds work without enough benefit for this task, narrow or pause that use. Carry useful gains into the next workflow only after checking its different risks.

Keep the review conversation short enough to repeat. Ask which information the recipient needed, which check caught a real problem and which part of the process was unnecessary. Record the change you agree and give it an owner. Otherwise, a trial can become another discussion whose conclusions nobody applies.

If people cannot meet the standard within their workload, change the workload or the standard deliberately. Do not quietly accept incomplete work while recording that the process has been introduced. The point of the trial is to discover what the workflow requires, including whether you have enough capacity to run it.

A successful trial may produce fewer documents. It may also reveal that AI is useful for early exploration but adds little to a particular final analysis. Either finding is usable. Adopt the part that improves the result and keep the decision open as tools, tasks and team experience change.

What about the cases that do not fit neatly?

Should you ban AI to stop workslop? A broad ban does not address unclear briefs, weak evidence or hidden repair work. Restrict a particular use when it breaches your data rules, cannot be adequately checked or repeatedly fails the required standard. Keep helpful uses where the team can demonstrate an acceptable result. Deal with tool permission through the existing AI agreement.

Does every message need an AI label? Set disclosure expectations where the assistance changes trust, verification, confidentiality or an existing requirement. Avoid treating spelling, translation or accessibility assistance as misconduct. A work-stage label and an account of the checks performed may give the recipient more actionable information than a blanket badge. Neither label excuses missing substance.

What if the employee denies using AI? If you have a concrete quality problem, you can address it without proving authorship. Show the unsupported claim or missing action owner and agree the correction. Do not turn a hunch about writing style into an accusation. If there is a separate policy concern, examine the relevant facts through the appropriate process.

What if the recipient is too demanding? Ask which requested changes affect the decision, safety, accuracy or an agreed requirement. A reviewer who rewrites every sentence to match their own voice can create rework even when the original is usable. Settle the acceptance criteria together and distinguish a necessary correction from a personal preference.

What if there is no time to finish checking? Make the remaining uncertainty explicit and ask the decision owner to choose the scope, timing or review route. Do not describe unchecked work as verified. For consequential commitments, an urgent deadline does not make unsupported assumptions dependable.

What if a rough draft is exactly what the team needs? Send it, with the question you want help answering. "I have two possible approaches and need your view on the constraint I may be missing" is a legitimate collaboration request. Protect that openness while making the author's next step clear.

Start with the next handoff that already causes friction. Ask its recipient what they need in order to use it, agree who will supply that information and check what changes on the following attempt. That gives the team a concrete way to reduce AI workslop while keeping assistance that earns its place.