AI Fatigue Is Real and Workplace Jargon Is Making It Worse

I keep hearing the same reaction around meetings where AI terminology is being thrown around. People say they feel tired. They are confused about what was actually decided. Some leave with the impression that everybody else understood the conversation better than they did.

I do not think this is unusual, and I do not think the problem is that people are unwilling to learn.

Terms such as agents, retrieval, fine-tuning and reasoning models may be necessary when a team reaches the technical details. They are a poor place to begin a business conversation.

AI fatigue is often the cost of being asked to understand a solution before anybody has clearly explained the problem.

Feeling overwhelmed by AI is not a fringe reaction

The phrase “AI fatigue” can cover several things: frustration with constant product announcements, pressure to adopt new tools, anxiety about changing roles and the cognitive effort of keeping up with unfamiliar language. We should not pretend they are one condition with one cause.

But the underlying sense of overload is visible. A Pew Research Center survey of 5,273 employed US adults found that 33% felt overwhelmed by how AI may be used at work in the future, while 52% felt worried. A 2026 Henley Business School survey of 2,900 full-time UK workers found that 61% felt overwhelmed by the pace of AI development, even as 58% remained optimistic about AI at work.

Those surveys do not tell us that jargon in meetings caused the response. They do show that optimism and overwhelm can exist at the same time. Someone can believe AI will be useful and still be exhausted by the way it is being introduced.

Language adds its own burden. In a controlled experiment involving 650 people, researchers studying scientific communication found that jargon disrupted people’s ability to process information fluently, even when definitions were supplied. It also affected perceived understanding and engagement.

The experiment was about science communication, not AI meetings. The useful connection is narrower: defining a difficult term does not automatically remove the effort required to process it.

Jargon can manufacture agreement

The most damaging AI meeting is not always the one that ends in open confusion. It can be the one that ends with everybody nodding.

Imagine somebody proposes an “agentic workflow” to improve delivery. The phrase sounds specific, but it can create four different meetings at once.

Nobody in that meeting has necessarily misunderstood the words. The problem is that the words have allowed different assumptions to survive.

The group leaves with apparent alignment. The disagreement appears later in estimates, architecture, governance, expectations and measures of success. Another meeting is scheduled to resolve it, usually with even more terminology.

Shared vocabulary is not the same as shared understanding.

The business rules did not disappear when AI arrived

AI gives us new capabilities. It can make some previously impractical solutions affordable, fast or accessible. It does not remove the basic questions behind good delivery.

• What problem are we solving?
• Who experiences it?
• What evidence shows that it matters?
• What outcome should change?
• What constraints must the solution respect?
• Who owns the decision and verifies the result?

These are not anti-AI questions. They are what prevent AI from becoming an expensive answer in search of a problem.

I made a related argument in AI Won’t Fix Agile Until You Redesign the Handover: making every role faster can still make delivery worse when queues, handovers and incentives remain unchanged. The same principle applies one step earlier. A team can learn every current AI term and still fail to agree on the work that needs to change.

Start with a sentence that contains no AI

Suppose a team begins with this proposal:

We need an AI agent connected to our delivery platform.

The technology is already inside the problem statement. That makes it difficult to question whether an agent is necessary, whether the delivery platform contains the right evidence, or whether the real constraint sits elsewhere.

Now start again:

We discover cross-team dependencies too late, and missed dependencies are making delivery commitments unreliable.

That sentence gives every role something concrete to examine.

Engineers can identify where dependency information exists and whether it is reliable. Project managers can clarify which commitments and stakeholders are affected. Delivery leads can map where dependencies become visible and where work waits. Scrum masters can surface the team behaviours and feedback loops that allow the same impediments to return.

The team may eventually decide that AI can inspect existing updates, suggest potential dependencies and prepare a review for a human. It may instead discover that teams do not record dependencies consistently, ownership is unclear or the planning process has no useful checkpoint.

In that case, adding AI would not solve the problem. It would automate guesses made from poor information.

The problem statement creates common ground. The technology discussion should earn its way into the room.

Map the problem to AI instead of mapping AI onto the team

I find this sequence more useful than beginning with a tool:

1. Name the friction. Describe what is slow, unreliable, repetitive or difficult without prescribing a solution.
2. Bring evidence. Use incidents, delays, rework, customer feedback or another observable signal.
3. Define the outcome. State what should improve and how the team could recognise the change.
4. Consider the simplest intervention. A clearer responsibility, removed handover or better source of information may be enough.
5. Test the AI fit. Ask whether classification, summarisation, generation, prediction or another model capability helps with this particular constraint.
6. Keep ownership human. Decide who reviews the output, handles failure and remains accountable for the result.

This works across the roles involved in delivery.

If engineers spend too long diagnosing failures across fragmented logs, an AI system might help correlate signals and prepare a summary. The measure is not how many summaries it produces. It is whether diagnosis becomes faster without hiding evidence or creating unsafe confidence.

If project decisions are scattered across calls, documents and tickets, AI might consolidate them and flag contradictions. The measure is whether clarification cycles and requirement churn fall, not whether more acceptance criteria are generated.

If a delivery lead repeatedly discovers dependencies after commitments have been made, AI might surface possible relationships for review. The measure is earlier discovery and more reliable delivery, not the number of risks added to a dashboard.

If a scrum team raises the same impediment in several retrospectives, AI might group themes and help track agreed actions. It should not be used to infer individual performance or emotion from team conversations. The measure is whether recurring impediments are resolved and whether the team considers the process safe and useful.

In each case, AI is a candidate intervention. It is not the objective.

A better AI meeting needs a shared definition of done

A glossary can help, but it is not enough. A meeting becomes clearer when participants know what decision they are there to make.

Before introducing an AI solution, ask:

• Can we describe the problem without mentioning AI?
• What evidence tells us this problem is worth solving?
• What would be observably better?
• Why might AI be more suitable than a process or conventional software change?
• Who will check the output and act when it fails?
• What decision must this meeting produce?

If the answers remain vague, explaining the difference between an LLM, an agent and a copilot will not rescue the conversation. The team needs discovery, not another terminology session.

This matters because meetings already consume attention. A 2022 study of 195 US full-time employees who attended virtual meetings found that people needed recovery after meetings and that meeting outcomes and relevance were related to that recovery. The study was conducted during the early months of the pandemic and did not examine AI terminology, so it should not be treated as proof of AI-induced fatigue. It does support a practical point: meetings have cognitive consequences that continue after the call ends.

Making participants translate undefined technology language while following the business discussion gives them more work to carry.

AI fatigue is also a delivery signal

When people say they are tired of AI, the easy response is to prescribe more training. Training may be necessary, especially when somebody needs to use or evaluate a system. But it does not fix an initiative that lacks a clear purpose.

Gallup reported in 2025 that 44% of US employees said their organisation had started integrating AI, while only 22% said it had communicated a clear plan or strategy. Gallup also identified an unclear use case or value proposition as the most common adoption challenge. Employees who strongly agreed that leadership had communicated a clear plan were much more likely to feel prepared and comfortable using AI. These are associations rather than proof that communication alone caused readiness, but the gap is hard to ignore. Adoption can move faster than shared understanding.

Fatigue can therefore be useful information. It may be telling you that the organisation is asking people to absorb tools, vocabulary and expectations before it has made the purpose clear.

That is not a reason to stop discussing AI. It is a reason to improve the discussion.

Before the next AI meeting, write the business problem in one sentence. Remove every model name, product name and AI term. If the sentence no longer explains what needs to change, the technology has taken the place of the problem.

If a team cannot describe the problem without using an AI term, it is not ready to discuss the AI solution.