Then I realized something was different. Those files mostly help systems discover or process information that’s already there. llms.txt exists to help AI systems understand our documentation.

For decades, tech writers have made editorial decisions about what customers should know. We decide which concepts deserve an explanation, which procedures belong (or don’t) in our product docs, and which content should be retired because it no longer reflects reality.

Today, many publishing platforms automatically generate a document whose audience isn’t your customer at all. Instead, it’s AI.

This Isn’t Just Another Generated File

An llms.txt file is often described as a guide for AI systems. That’s accurate, but incomplete. It’s much more than that. You can think of it as a summary of what your organization considers important enough for AI to read first.

Depending on how your documentation platform generates it, the file may point to product overviews, API references, tutorials, SDKs, migration guides, code examples, and other documentation. An AI system can use that information to build an initial understanding of your product long before it retrieves content from any individual page.

That’s a different editorial function than a sitemap.

👉🏾 A sitemap says, “These pages exist.”

👉🏾 An llms.txt file effectively says, “Start here.”

Automatic Doesn’t Mean Curated

Recently, I examined the llms.txt file for a public API documentation site. Nothing in it was confidential. Every page it referenced was already public.

What surprised me wasn’t the content. It was how much easier the file made it to understand the product.

Instead of exploring the documentation one section at a time, I could immediately see the major APIs, supporting guides, integration points, and product organization. The documentation had been distilled into a machine-readable map.

That’s exactly what the file was designed to do.

The question is whether that map reflects an editorial decision or simply the default output of a publishing platform.

Those aren’t the same things.

An automatically generated file may include deprecated documentation, legacy APIs, archived migration guides, experimental features, or transitional content simply because those pages are still public. The software doesn’t know which content best represents your product today. It only knows what we tell it.

This Is An Editorial Question

Tech writers are the people who decide how a product should be explained. We choose examples, organize information, and retire obsolete content. We often work with product managers, software developers, support teams, and legal reviewers because we understand that publishing is an editorial process, not a database export.

I think llms.txt belongs in that process. If AI systems are going to use it as a starting point for understanding our documentation, then someone should review what it communicates before its published.

Not because AI shouldn’t read your documentation. Because we should be intentional about what we’re helping it understand.

A New Publishing Checklist

Most documentation teams already review titles, links, examples, screenshots, and metadata before publishing. It may be time to add one more item to that checklist.

👉🏾 Review the documentation we’re publishing for machines with the same care we give the documentation we’re publishing for people.

A publishing platform can generate an llms.txt file automatically. Only we can decide whether it tells the right story about our product. 🤠

Note: The llms.txt specification is evolving through community input. Its GitHub repository provides version control, issue tracking, and public discussion, while a community discord channel gives implementers a place to share experiences, compare approaches, and discuss emerging best practices.

That advice has been retired by Google, but the exact same content model is now being promoted for Answer Engine Optimization (AEO) by a host of others, and I wanted to know whether the new claim is supported by comparable evidence.

What Answer Engine Optimization Aims To Accomplish

AEO is the effort to improve how often and how accurately an organization’s information or brand name appears in answers generated by AI systems. AEO includes AI features in search engines, but it isn’t limited to Google or Bing. It also applies to answer engines that search or retrieve information from the web and use what they find to generate a response.

AEO success can mean several things. Your organization might be mentioned in an answer or your information might be used without attribution. A page might receive a citation or link and someone might follow that link, visit the website, and take a business action.

What I want to know if this: Does organizing content around explicit questions followed by concise answers improve the chances that an AI answer engine will retrieve, use, or cite that content? And is the evidence strong enough to justify changing a website’s content model?

Read more

I had described the same workflow differently in two places. Some of the business rules didn’t become apparent until Claude reached points where the process couldn’t continue without them. Guidance I had developed over time conflicted in subtle ways that I hadn’t noticed because I already knew what I meant, but Claude didn’t.

Each time Claude reached one of those points, we stopped and worked out what the process was supposed to be. Sometimes that meant reconciling conflicting language. Other times we reorganized the information because the structure no longer held. A few problems forced us back several steps.

Looking back, we didn’t spend most of our time building software. Instead, we tried making the work explicit enough that Claude could apply it.

Why Did This Feel So Familiar?

A few weeks later I read a paper from Harvey, makers of AI software for legal pros, about governing AI agents. One sentence stopped me.

“Agents do not change what governance is for. They change where governance happens.”

A few pages later, another passage:

“Before automation can produce consistent results, the underlying process has to be understood, documented, and made repeatable.”

That described what had been happening more clearly than I had.

I wondered whether Harvey was unusual.

Read more

AI is building an understanding of your product. The quality of that understanding depends more on your documentation than many tech writers realize.

Information architecture isn't becoming more important because AI arrived. AI just wandered into a conversation we technical writers have been having for decades.

We choose terminology, define content relati…

Read more

Claude described the company as helping European SMEs make their content AI-ready. That detail wasn’t something I remembered seeing on the product website, so I asked Claude where it came from.

The answer Claude provided was revealing. According to popular AI platform, The Content Forge website is apparently built as a JavaScript application, and, as a result, it couldn’t easily retrieve the rendered page. Instead, it relied heavily on the HTML it could see — including the metadata — the page title, meta description, and Open Graph tags. It treated those fields as evidence and folded the metadata it could see into its explanation of the company.

Metadata Isn’t Just For SEO Anymore

HTML metadata serves many purposes. Some metadata tell web browsers how and where to display content a web page. Other types help search engines index content, control how pages appear when shared on social media, verify site ownership, or identify the preferred version of a page. Other metadata describes what the aboutness of the content on the page.

Read more

We’ve lived with the consequences of outdated content for years. What’s changed today is that those consequences are now much easier to see. Support analytics, customer feedback, self-service metrics, and AI systems now expose information problems that in the past may have remained hidden.

Tech writers have discussed these issues for decades. The costs are simply harder to ignore now.

What Is Documentation Debt?

The symptoms are familiar: outdated procedures, obsolete screenshots, broken links, duplicate content, conflicting instructions, and knowledge base articles that no longer match the product.

Documentation debt rarely arrives all at once. A feature ships before the technical documentation is updated. A subject matter expert leaves the company. Ownership becomes unclear. Teams focus on creating new content while older information slowly falls out of date.

The work doesn’t disappear; it accumulates.

Many Tech Writers Already Understand Technical Debt

Many of us have spent years working alongside software teams that discuss technical debt.

Developers use the term to describe shortcuts, deferred maintenance, aging code, or design decisions that eventually make software harder to maintain. Teams understand that the cost does not disappear simply because the work was delayed.

Documentation works much the same way.

When updates are postponed, maintenance is deferred, or ownership becomes unclear, organizations accumulate documentation debt.

Both forms of debt represent deferred maintenance.

Technical debt affects the software itself. Documentation debt affects the information people rely on to use, support, maintain, purchase, and troubleshoot that software.

Engineers encounter technical debt in the codebase. Tech writers run into documentation debt through support tickets, failed searches, outdated procedures, and frustrated users.

Technical debt is widely recognized because it affects schedules, budgets, and engineering productivity. Documentation debt affects support costs, customer experience, operational risk, and the reliability of information systems.

Read more

The criticism is fair. Large language models are known to invent facts, confuse details, and produce answers that sound convincing even when they are wrong. What interested me more was the assumption underneath the slogan. The comparison only works if people are reliable.

Tech writers spend enough time interviewing subject matter experts to know that isn’t always true. Ask several people how a product feature works and you may hear several explanations. One engineer describes the original design. Another explains how the system behaves today. Support remembers the workaround customers use. Product management recalls a decision that was never documented.

Nobody intends to mislead anyone, yet the facts often arrive tangled together. Much of the work of technical writers involves sorting through those competing accounts.

Human Hallucinations Are More Common Than We Admit

Chris’s post assembled several examples that are uncomfortable precisely because they involve ordinary people rather than obvious bad actors.

A YouGov survey found that 2 percent of Americans said they firmly believe the Earth is flat. Another 7 percent said they were unsure about the Earth’s shape. Among younger adults, the uncertainty was even higher.

A separate Economist/YouGov poll found that 12 percent of Americans agreed that the Moon landing was staged.

Related reading: Conspiracy vs. Science: A Survey of U.S. Public Beliefs

The so-called Mandela Effect offers another example. In a 2022 YouGov survey, 40 percent of Americans said they had shared a memory with others that many people remembered differently or believed to be false. When asked about specific examples, 61 percent remembered the children’s books as the “Berenstein Bears,” even though the books have always been published as the “Berenstain Bears.”

The same survey found that 28 percent of respondents considered parallel universes or alternate dimensions a plausible explanation for these shared memories.

These examples are easy to dismiss because they seem unusual, but memory errors appear in situations with much higher stakes. Eyewitness testimony remains one of the most persuasive forms of evidence presented in court. Yet the Innocence Project reports that eyewitness misidentification played a role in roughly 69 percent of convictions later overturned through DNA evidence.

One of the best-known cases involved Jennifer Thompson, who deliberately studied her attacker’s face so she could identify him later. She selected Ronald Cotton from a lineup, testified against him in court, and remained convinced she had identified the correct person. Cotton spent more than a decade in prison before DNA evidence established that another man had committed the crime.

Why Organizations Write Things Down

Organizations create documentation for many reasons. New products need instructions, APIs need references, and customers need help completing tasks. Over time, documentation also becomes a record of decisions, product behavior, terminology, and procedures that people may remember differently or forget altogether.

Most documentation teams eventually discover procedures that nobody follows, product behavior that differs from the manual, and explanations that change depending on who is asked. Generative AI did not create these problems.

When an AI system produces an incorrect answer, the mistake appears immediately. Human errors often move more slowly. They become outdated procedures, undocumented assumptions, conflicting explanations, and organizational folklore that survives long after the product changes.

Every tech writer has heard someone begin a sentence with, “We’ve always done it this way,” only to discover that nobody can explain why.

People And AI Make Different Types Of Mistakes

People are forgetful. We combine separate events into a single memory, and rely on assumptions, repeat information we heard years ago, and sometimes remember what we expected to happen instead of what actually happened.

Language models fail differently. They predict likely responses from patterns in training data and retrieved information. They may combine facts incorrectly, invent missing details, or generate plausible explanations that lack evidence.

Neither Humans Nor AI Systems Deserve Automatic Trust

It turns out that people and language models need many of the same things: good information, enough context, and a way to check whether an answer is supported by evidence.

Most of us have been in the meeting where three people remember the same decision three different ways. Eventually someone finds the ticket, the email, or the requirements document, and the argument ends.

Tech Writers Already Understand The Problem

Must we choose between reliable humans and unreliable AI? I hope not.

Anyone who has worked in documentation for very long has encountered the software engineer or product creator who explains a feature with complete confidence, only for testing to reveal that the product behaves — ahem — differently.

Every doc team eventually finds a procedure that nobody actually follows. Support teams have their own version of this problem, repeating explanations they conjure up that might have matched the product several releases ago but no longer do.

AI gives employees another place to get answers, but somebody still has to check whether those answers match the product, the policy, and the documentation.

What This Means For Tech Writers

Technical writers regularly walk into situations where different people remember the same event differently. One person recalls the decision, another remembers the exception, and somebody else insists the whole thing changed two releases ago. Eventually we have to sort through the emails, tickets, release notes, and meeting minutes to figure out what actually happened.

That work becomes even more important as AI systems begin answering questions alongside documentation, support teams, and subject matter experts.

Organizations have always operated with incomplete information. People remember meetings differently, repeat outdated explanations, and hold onto decisions that quietly changed years ago. Documentation helps reduce some of that confusion, even if it never eliminates it completely.

AI now participates in many of the same conversations that once belonged entirely to coworkers, support staff, and subject matter experts. That puts more pressure on the underlying information. Procedures, release notes, requirements, and product documentation increasingly serve both people and machines.

For tech writers, the work is familiar. Somebody still has to determine what is true, what changed, and which version belongs in the documentation. 🤠

A recent review of banking developer portals by Pronovix, a consultancy that specializes in developer portals and developer experience, suggests that assumption may be creating new problems. The company evaluated the portals of eleven major banks to see how well they support AI-assisted discovery and evaluation.

Banking was a useful test case because financial institutions have spent years investing in APIs, developer portals, and open banking initiatives. The industry has had plenty of time to refine how it presents technical information to developers and partners. If gaps in context, discoverability, and content relationships appear in environments this sophisticated, chances are good they’re unlikely to be unique to finance.

As I read through the findings, I kept noticing how many of the issues sounded familiar. Missing context. Weak connections between related content. Technical information separated from business meaning.

Tech writers have been dealing with these challenges for decades.

Why Are Some Developer Portals Hard For AI To Understand?

Many of the portals reviewed contained substantial technical information. The problem wasn’t a lack of docs. It was that much of the documentation contained information focused on implementation while providing limited context about business purpose.

Many portals explained how a capability worked but spent less time explaining who it was for, what problem it solved, or when someone should use it. That distinction matters because implementation and discovery are different activities.

👉🏾 Someone who already knows which API they need is looking for instructions
👉🏾 Someone evaluating possible solutions is looking for context

Many portals seem to assume site visitors already know what information they need. That works well for implementation, but it works not-so-well for discovery.

What Is The ‘Semantic Gap’ In Technical Documentation?

Pronovix uses the term semantic gap to describe the distance between business language and technical language.

Marketing teams describe business value. Product teams describe capabilities. Technical writers explain how those capabilities are used. When that information is spread across different websites, repositories, and systems, the relationships between the pieces become harder to see.

The result is that readers must connect the dots themselves. Tech writers see this problem regularly. Users care about goals. Product teams too often focus on functionality. The docs we create frequently serve as the bridge between those perspectives.

The review suggests that AI answer engines face many of the same challenges. When use cases, audiences, business outcomes, and technical capabilities are loosely connected, understanding becomes more difficult.

Why Does Content Fragmentation Matter?

The review found that understanding a product often requires gathering information from several sources. A user may need to access one website to understand the business value, another to understand the product capabilities, a developer portal for implementation details, and a support site for troubleshooting help. The content exists, but the relationships between individual pieces are not always obvious.

This observation helps explain why tech writers spend so much time discussing information architecture, metadata, taxonomy, governance, and terminology management. Those practices help establish connections between related content.

What Happens When Important Content Is Hidden Behind Login Walls?

Organizations often place valuable information behind registration forms and authentication barriers. The issue isn’t whether the content exists. The issue is when it becomes available. If important information appears only after registration or authentication, it can’t help visitors understand, compare, or evaluate options during the discovery process.

Does Technical Documentation Influence AI Recommendations?

Documentation is not the only factor that influences whether a product or service appears in AI-generated answers. However, documentation contributes evidence.

When documentation clearly explains capabilities, audiences, use cases, business goals, and implementation details, there is more information available to support understanding. When content focuses almost exclusively on technical specifications and procedures, there is less context available.

Good docs have always explained more than how to complete a task. They help readers understand purpose, relevance, and relationships between concepts.

What The Findings Tell Us

The findings reinforce many principles tech writers already advocate for:

👉🏾 clear terminology
👉🏾 strong information architecture
👉🏾 useful metadata
👉🏾 well-defined audiences
👉🏾 practical use cases, and
👉🏾 content that explains purpose alongside procedure

None of those practices were created for AI. They exist because people need context to understand complex information. The review suggests that AI tools benefit from many of the same signals.

Reading through the findings, it is difficult not to notice how many of the observations map directly to challenges tech writers have been discussing for years. Missing context, disconnected information, inconsistent terminology, and weak relationships between content assets are not new problems. The review simply shows what happens when those problems are examined through the lens of AI-assisted discovery. 🤠

Most discussions about AI costs focus on language models. That’s understandable. Models have names, rankings, benchmarks, pricing pages, and marketing campaigns.

Content gets far less attention. That’s surprising because AI systems spend much of their time looking for information before they generate an answer.

That distinction becomes more important as organizations move beyond experimentation and begin deploying AI-powered support systems, internal assistants, knowledge portals, and agentic search experiences at scale.

Stripe, the online payments company that processes transactions for millions of businesses, recently caught my attention for exactly that reason. The company announced AI usage billing, a capability that charges customers in proportion to what they consume (e.g., tokens processed, compute seconds, API calls, agent actions) rather than a flat fee.

The announcement wasn’t about model quality. It was about consumption. How many tokens were used? Which application consumed them? How should those costs be allocated? How should they be recovered? By whom?

Once organizations can see AI consumption, they’re eventually going to ask why some AI-powered experiences cost more to operate than others. In many cases, part of the answer may be the content itself.

Why Does Content Ambiguity Increase AI Costs?

Tech writers have always worried about ambiguity because it frustrates readers. AI systems introduce another reason to care.

Suppose a procedure says:

“Approve the request after validation completes.”

Most people working in that environment can probably figure out what’s happening. They know who performs the approval and they understand what validation means. They probably know what event signals validation completion.

AI systems don’t share that background knowledge.

If the role, condition, or triggering event isn’t documented, the AI system often searches for that information elsewhere. As documentation repositories grow, those searches become more expensive. The answer may already exist, but the system may retrieve multiple documents, compare competing explanations, and evaluate additional context before it can decide which information to use.

The System Has To Find The Missing Pieces

Many organizations assume AI works like a very fast employee who already knows where everything is. In reality, AI systems spend a surprising amount of time searching, comparing, ranking, and evaluating information before generating an answer.

A user asks a simple question. The retrieval system may pull multiple documents, compare overlapping explanations, evaluate terminology, identify the most likely workflow, and discard information that appears unrelated.

When our documentation is clear, the search narrows quickly. But, when our content contains inconsistent terminology, undocumented assumptions, duplicate information, or missing workflow context, the system often retrieves more material than it otherwise would.

Organizations are beginning to measure that work.

What Does TRACE Have To Do With It?

TRACE stands for Tasks, Roles, Actors, Conditions, and Events. The framework grew out of an observation I’ve encountered repeatedly in documentation reviews: many problems aren’t caused by missing information. They’re caused by missing context.

👉🏾 The task is described, but nobody identifies the role responsible for it.
👉🏾 The workflow is documented, but the triggering event isn’t.
👉🏾 The actor changes halfway through the process without being identified.
👉🏾 The conditions that determine success or failure exist only as assumptions.

Human readers often work around those gaps because they already understand the environment.

TRACE became interesting to me because it highlights exactly the information retrieval systems often go looking for. When tasks, roles, actors, conditions, and events are explicit, the system has stronger clues about what a topic is describing and how it relates to other topics.

Technical Documentation Has Entered the Cost Conversation

For years, tech writers justified structured content using familiar arguments around reuse, consistency, metadata, governance, localization, and maintainability. Those arguments still hold up today.

What’s changing is the audience for the discussion. As organizations start tracking AI consumption, content issues may begin appearing in conversations that previously focused on infrastructure, support operations, and technology spending.

We’ve spent years cleaning up duplicate content, arguing about terminology, and chasing down missing workflow details. Those activities may sound unrelated to AI operating costs. They probably aren't.

Those same issues may also increase the amount of work AI systems perform before it can answer a question.

Five years ago, most conversations about structured content focused on publishing efficiency, governance, and reuse. AI may pull the discussion into a different part of the organization, the people responsible for operating budgets.

Why Tech Writers Should Pay Attention

Organizations are building AI systems on top of documentation repositories, knowledge bases, support portals, and content collections that were never designed for machine consumption. Some of those systems will work remarkably well. Others will consume more resources than expected because the underlying content requires constant interpretation.

We’ve been talking about context, consistency, terminology, and structure for years. If organizations begin tracking AI consumption the way they track cloud spending, those conversations may start happening in different meetings with different stakeholders. 🤠

For years, we tech writers have been trying to explain structured content to people who looked at metadata the way you might look at steamed broccoli. 🥦

Necessary? Maybe. Exciting? Absolutely Not.

Then AI arrived, wrapped in venture capital and optimism, promising to revolutionize the way we work and eliminate our drudgery.

And now, suddenly, organizations are discovering something painful we tech writers have been muttering for decades: Messy information is expensive. 💰

Welcome to the strange new world where unclear docs and inconsistent product information can increase infrastructure spending.

Tokens: The Invoices Nobody Talks About

Let’s start with tokens because the AI industry throws the word around as though everybody understands it.

Every time an AI system:

• reads a prompt

• retrieves documentation

• processes instructions

• accesses a service

• searches for references

• remembers conversation history

• generates a response

…it consumes tokens. And tokens cost money. 💴

At small scale, the costs feel trivial. A chatbot rewrites our awkward email message. A support assistant summarizes a customer support case. Somebody in marketing asks AI to “make this sound more dynamic” and receives three paragraphs that sound like a regional bank trying to flirt.

No big deal, right?

But organizations aren’t deploying AI for one interaction. They’re deploying it everywhere for all sorts of reasons.

• Customer support

• Internal search

• Knowledge retrieval

• Workflow automation

• Developer assistance

• Sales enablement

• Training systems

• Agentic orchestration

That’s where the meter starts spinning.

Related reading: AI can cost more than human workers now

AI Doesn’t Understand Our Documentation

This is important. AI models don’t “understand” our content the way humans do.

Humans are remarkably forgiving creatures. We can infer meaning from terrible prose, missing context, vague terminology, and screenshots that look like they were captured during a small electrical fire 🔥.

AI systems aren’t really understanding anything (in the human sense). They’re processing statistical language patterns and attempting to assemble probable meaning.

Which means ambiguity creates work. And work creates token consumption.

Now imagine the AI retrieves:

• six overlapping procedures

• two outdated workflows

• contradictory terminology

• troubleshooting mixed into conceptual overviews

• outdated screenshots from 2019

• a release note pretending to be task guidance

• an unlabeled warning block that reads like a hostage note

The system now has to process all that material trying to determine what’s actually relevant.

💰 Costs start to rack up quickly.

Retrieval of data costs tokens. Ranking what it found and reasoning across it costs more. Generating an answer adds — you guessed it — more expense.

Then the agent may decide it’s uncertain and retrieve even more content.

Because your documentation repository has become the informational equivalent of a kitchen junk drawer filled with expired coupons, tangled charger cables, mystery batteries, and three keys nobody recognizes but nobody dares throw away.

Agentic AI Makes the Problem Worse

Traditional chatbots were comparatively simple. They answered a question and moved on with their lives.

Agentic AI systems are different.

These systems often:

• interpret intent

• reformulate questions

• retrieve multiple content chunks

• compare sources

• invoke tools

• summarize results

• validate outputs

• retry retrieval

• generate next actions

Every step burns tokens.

And the less explicit your documentation is, the harder those systems must work.

This is where technical writers should become deeply interested in the economics of ambiguity.

Because the AI industry increasingly profits from uncertainty.

The more your content forces AI systems to infer meaning, the more compute gets consumed.

And now companies like Stripe are openly building systems to meter, monitor, bill, and even profit from AI consumption costs.

That’s not science fiction anymore. That’s accounting.
https://techcrunch.com/2026/03/02/stripe-wants-to-turn-your-ai-costs-into-a-profit-center/

The AI industry is quietly transforming tokens into a utility model.

Like electricity.

Or water.

Or those suspicious resort fees hotels add while pretending the hallway Wi-Fi is a luxury experience.

This Is Why Structured Content Matters Again

Technical writers have spent years talking about:

• reuse

• taxonomy

• metadata

• controlled language

• modularity

• governance

Usually while someone from another department asks whether we can “just put it in Confluence.”

Now AI has accidentally made all those conversations financially relevant.

Structured content reduces retrieval waste.

Clear topic types help AI systems distinguish between:

• tasks

• concepts

• references

• troubleshooting

• policies

Consistent terminology reduces ambiguity.

Metadata narrows retrieval scope.

Reuse reduces duplicate processing.

Governance improves precision.

The goal is no longer just helping humans find information.

The goal is helping AI retrieve the smallest amount of information necessary to generate a reliable answer.

That’s token efficiency.

And token efficiency is becoming operational cost control.

PREA Makes AI Work Less

This is where PREA becomes especially interesting.

DITA already gives organizations structural consistency. But structure alone doesn’t always expose operational meaning clearly enough for AI systems.

A topic can validate perfectly while still leaving important relationships implicit.

PREA — Process, Role, Event, Actor — helps make those relationships explicit.

Instead of forcing AI systems to infer:

• who performs an action

• what triggers a workflow

• which actor changes a system state

• when a process starts or ends

…the content tells the system directly.

That matters enormously in agentic retrieval systems.

Without PREA, an AI may retrieve dozens of vaguely related chunks because it’s relying mostly on keyword overlap and statistical proximity.

With PREA-informed content, retrieval becomes narrower and more precise.

The AI reads less because the documentation says more.

That’s the magic.

Not magical in the “wizard sparks and unicorn tears” sense.

More like the deeply satisfying magic of finally labeling storage bins in the garage after years of opening random boxes looking for extension cords.

Every Vague Heading Creates a Tiny AI Tax

This may sound dramatic, but it’s true.

Every ambiguous title.

Every duplicated procedure.

Every overloaded topic.

Every inconsistent term.

Every undocumented workflow transition.

Every “Important Information About Setup” heading quietly increases computational effort.

One isolated retrieval operation costs almost nothing.

Millions of retrieval operations across thousands of users become a budget discussion.

And organizations are going to start noticing.

Especially once finance departments realize AI systems don’t merely consume software licenses.

They consume language.

Technical Writers Are Quietly Becoming Infrastructure People

Nobody entered technical communication dreaming of optimizing inference efficiency.

Yet here we are.

The role is changing.

Technical writers are no longer just producing documentation for human readers.

We’re increasingly designing information environments for machine consumption too.

That means our choices affect:

• retrieval precision

• context size

• inference efficiency

• hallucination risk

• orchestration overhead

• operational AI costs

Which is honestly a bizarre career development.

Somewhere in 1998, a technical writer was carefully adjusting bullet indentation in Microsoft Word while eating yogurt from a desk drawer and worrying about printer drivers.

That person probably didn’t imagine future writers would one day influence enterprise AI infrastructure economics.

And yet.

Here we are.

Because in the age of agentic AI, content isn’t merely communication anymore.

It’s fuel.

And fuel costs money.

Humans do this so naturally that we rarely notice it. Machines don’t.

I was thinking about that while reading a recent LinkedIn post from knowledge graph researcher Benny Cheung. He described the progression from data to taxonomy to ontology to knowledge graphs and argued that organizations that stop too early in that progression are likely to struggle with AI.

The post resonated with me because technical writers have been dealing with parts of this problem for years, although we don’t usually use the same vocabulary.

Organizing Information Isn't The Same Thing As Defining Meaning

Most organizations have plenty of places to store information. They have databases, content management systems, knowledge bases, SharePoint sites, and file repositories.

Storage isn’t the problem.

Cheung points out that a database schema and an ontology solve different problems. A schema describes how information is organized. An ontology describes what something is, how it relates to other things, and what rules govern those relationships.

Many organizations blur those distinctions. They assume that once information is structured, categorized, and stored, meaning somehow comes along for the ride.

It doesn’t. Not even close.

Consider the difference between a content label such as “firmware update” and a description that explains who performs the update, what event triggered it, what conditions must be true before it can begin, and what happens when it succeeds or fails.

👉🏾 One helps identify a topic.
👉🏾 The other helps explain how something works.

For AI systems, those details matter.

Taxonomy Helps You Find Things

Technical documentation teams have spent years building taxonomies. We classify products, features, audiences, document types, and metadata values. That work is useful because it helps people find information.

The challenge is that classification only answers part of the question.

AI systems increasingly depend on structured context, not just text. Knowledge graphs and RDF (Resource Description Framework) represent entities and the relationships between them, while action and process models make it explicit who performs an action, what object is affected, what events or conditions shape a workflow, and how activities connect across a process. That structure helps AI systems retrieve information with context and perform multi-step tasks more reliably.

Those relationships are often scattered across multiple documents or left unstated because human readers can usually infer them. AI systems don’t always infer them correctly or consistently.

That’s where many documentation repositories start to show their age. The information exists, but the relationships are incomplete, inconsistent, or implied.

Why Documentation Can Confuse AI

When people read our documentation, they bring a lifetime of experience to the process. They know that customers and technicians have different responsibilities. They recognize that a setup procedure may not apply during routine operations. They can usually tell when a warning belongs to a specific circumstance rather than every circumstance.

Documentation often depends on that kind of judgment.

Large language models don’t read the way people do. Not even remotely. They generate responses based on patterns and probabilities. When key relationships are missing, the model may connect things that shouldn’t be connected, skip conditions that matter, or assign actions to the wrong person or system.

The result can sound reasonable while being wrong.

That’s one of the reasons I’ve been working on the TRACE framework:

• Tasks

• Roles

• Actors

• Conditions

• Events

The framework grew out of a simple observation. Many documentation problems that affect AI have less to do with missing information than with missing context. The facts may be present, but the relationships between those facts often aren’t.

Tech Writers Are Already Working in This Space

Tech writers routinely define components, describe workflows, document responsibilities, explain dependencies, and identify conditions that affect outcomes.

Most of us think of that as documentation. But, viewed another way, it’s also the work of defining how a system operates.

That’s why I think some organizations are overlooking a valuable source of expertise. They want AI systems that can answer questions across large collections of enterprise knowledge, but they often treat documentation as a publishing function rather than a knowledge-definition function.

The people who understand the relationships are frequently the same people who wrote the documentation.

Why Knowledge Graphs Are Back In The Conversation

Knowledge graphs have been around for years, but many organizations never saw a compelling reason to invest in them. Search generally worked “good enough.”

Generative AI changed expectations. Organizations now want systems that can explain relationships, answer questions in context, connect information across departments, and adapt responses to different situations.

Those capabilities depend on more than retrieving content. They depend on understanding how pieces of information relate to one another.

Knowledge graphs can help with that, but only if the underlying content contains clear relationships. If the source material is ambiguous, the graph inherits the ambiguity.

At some point the AI starts filling in the blanks. What appears to be an AI problem may be exposing weaknesses that have existed in our documentation all along.

A Different Way to Think About AI Readiness

Many conversations about AI readiness focus on models, tools, and infrastructure. Those things matter. But organizations may also need to look at the information itself.

👉🏾 Is operational context explicit?
👉🏾 Are actors clearly identified?
👉🏾 Are conditions documented?
👉🏾 Are workflows connected in ways that a machine can follow without making assumptions?

Those questions sound a lot like documentation questions.

That’s why Cheung’s post caught my attention. It highlights a gap that technical writers have been working around for a long time. As organizations push AI deeper into customer support, training, service delivery, and enterprise search, that gap becomes harder to ignore.

The issue may not be that organizations lack content. It may be that too much of the meaning still lives in the heads of the people reading it. 🤠

Subscribe now

Here’s the problem with that: technical documentation was never primarily about typing sentences. The real work has always been deciding what matters, how information connects, what order things belong in, which warnings will save somebody from catastrophe, and which missing prerequisite is about to turn a software deployment into a small electrical fire in the server room.

AI won’t eliminate tech writing, but it is exposing what tech writing actually is.

The Great Decoupling

For decades, writing and architecture were welded together. If you wanted documentation, someone had to manually draft every sentence. Writing and thinking looked like the same activity because they happened in the same place.

AI broke that relationship.

The easiest way to understand this is to stop thinking about documentation and start thinking about construction.

For years, we were expected to design the blueprint and lay every brick ourselves. Want a 50-page manual? Congratulations. Please hand-place 20,000 words while also managing review cycles, fighting SharePoint permissions, and wondering why the product changed three days before launch and nobody bothered to inform you.

Now AI shows up as an automated bricklayer capable of laying ten thousand bricks a second. That sounds impressive (until you realize what happens when you unleash an automated bricklayer without a blueprint).

Suddenly there’s a staircase leading into a hedge. The bathroom opens directly into the kitchen. A wall suddenly appears across the driveway.

The machine builds quickly. It just doesn’t build intelligently on its own. That’s the real shift. Drafting has become cheap. Architecture has become valuable.

Your Company’s AI Is Only As Smart As Its Documentation

Organizations keep spending on AI while feeding it a digital landfill full of outdated PDFs, random Google Docs, unstructured help articles, inconsistent terminology, duplicate procedures, and seventeen different ways to describe the same button.

AI systems don’t magically create truth. They retrieve information from whatever source material exists. If the source material is a mess, the AI becomes a highly confident confusion machine.

This is why information architecture suddenly matters to executives who previously thought metadata was some kind of skin condition.

Technical writers aren’t just producing content anymore. They’re building the operational knowledge layer that AI systems depend on to function safely.

And honestly, some of us have been trying to explain this for twenty years while being treated like the office people who “make the PDFs prettier.”

The New Career Split

Although my crystal ball 🔮 is cracked (and my psychic powers are limited), I predict tech writing is no longer one profession moving in one direction. It’s splitting into several paths. Four, for now.

Read more

For most of the internet’s history, humans directly interacted with content. We searched, clicked, read, compared, interpreted, and decided what to trust. Websites competed for our attention. Search engines acted as maps that guided us toward information, but humans still visited the original destination.

That relationship is beginning to change.

Increasingly, AI is becoming the layer between humans and information. Instead of navigating websites, people are asking questions. Instead of reading ten links, they are receiving one synthesized answer. Instead of evaluating sources themselves, they are trusting systems to interpret the internet on their behalf.

The shift may sound subtle, but it fundamentally changes the role of content online. Content is no longer just something humans consume directly. It is becoming raw material that machines interpret, summarize, rank, and repackage before humans ever see it.

We are entering the era of invisible content.

The Collapse of the Footnote

In many ways, this transformation is already here. Google’s AI Overviews, ChatGPT, Perplexity, Microsoft Copilot, and other conversational systems are changing how people interact with knowledge. Industry analysts at Gartner have projected that traditional search engine volume is on track to decline by 25 percent as users increasingly migrate toward AI driven conversational experiences.

For publishers, media companies, and enterprise organizations built around discoverability, the implications are structural. The internet is shifting from a referral driven network to an ecosystem increasingly shaped by extraction and synthesis.

As Cloudflare CEO Matthew Prince recently observed while discussing the future of AI search:

“People aren’t following the footnotes.”

To understand the scale of this transition, look at the widening gap between machine crawling and human visiting. A decade ago, search engines crawled websites primarily to guide humans back to original sources. Today, AI systems increasingly consume information without returning meaningful traffic to publishers. According to comments shared publicly by Prince, emerging AI platforms appear to generate dramatically higher crawl to referral ratios than traditional search engines, with extraction metrics for major LLM crawlers scaling into the thousands or even tens of thousands of pages scraped for every user redirected back to a source.

The result is already becoming visible across digital publishing ecosystems. Multiple analytics firms and media organizations have documented significant drops in referral traffic as users increasingly receive summarized answers directly within AI interfaces. But traffic loss is only part of the story. The deeper shift is psychological.

The internet is moving from an environment where humans evaluate information themselves to one where AI increasingly mediates reality for them.

That changes how trust works online.

From Source Literacy to Interface Trust

For years, trust on the internet was tied to visible signals. People trusted recognizable publications, established brands, expert authors, or communities they felt aligned with. Even when misinformation existed, users still had some awareness of where information originated.

AI changes that relationship because it compresses many sources into a single confident response. The original context disappears. Nuance fades. Contradictions flatten. In many cases, even the source itself becomes secondary.

The answer becomes the interface.

This compression also amplifies something psychologists have long studied: automation bias. Humans naturally tend to place greater trust in structured, automated outputs, especially when they appear confident and efficient. Researchers are increasingly examining how the fluency and conversational tone of Large Language Models can create an illusion of authority even when information is incomplete, outdated, or inaccurate.

People quickly adapt to whatever feels easiest, and fast conversational AI fits that pattern well. Once users get used to instant, low-effort answers, going back to slower manual research feels inconvenient, but convenience alone does not guarantee trust: people may prefer the speed while still questioning whether the answer is accurate, complete, or safe.

When humans begin emotionally trusting systems that summarize reality for them, the internet changes from a network of information into a network of mediated interpretation.

The Enterprise Imperative: Content As Machine Infrastructure

This creates an entirely new playbook for organizations far beyond media companies.

For content strategists and information architects, this may become one of the defining challenges of the next decade. We are no longer designing content exclusively for human readers. Increasingly, we are designing it for machine interpretation.

Modern AI systems rely heavily on structured and retrievable information. When organizations use Retrieval Augmented Generation frameworks to connect AI models with enterprise knowledge, the quality of the underlying content architecture becomes critical.

AI systems perform better when information is modular, semantically organized, clearly tagged, and consistently maintained.

If corporate knowledge bases, technical documentation, policies, or support systems are fragmented, inconsistent, or buried inside static files, the AI pipeline begins to weaken. Messy, incomplete, or inconsistent inputs usually lead to unreliable AI outputs because models can only work with the context and constraints they are given. When prompts are vague or poorly structured, the system is more likely to guess, omit important details, or produce inaccurate results. Even sophisticated AI models cannot consistently produce trustworthy outcomes from chaotic source material.

This is why the future of content strategy may depend less on publishing volume and more on governance, structure, and information integrity. The real competitive advantage will not come from generating endless amounts of synthetic content. It will come from building systems that preserve clarity, provenance, consistency, and trust in environments increasingly saturated with machine generated information.

A Premium On Authenticity

Ironically, as generative AI makes text, images, video, and code easier and cheaper to produce, genuinely trustworthy information may become more valuable, not less.

Human credibility, transparent sourcing, and verified expertise become premium.

We are already beginning to see the early foundations of this shift. Initiatives such as C2PA, the Coalition for Content Provenance and Authenticity, are developing technical standards that help verify where digital content originated and whether it has been manipulated. At the same time, organizations are investing more heavily in structured content systems, metadata frameworks, modular authoring models, and governed knowledge ecosystems that can support trustworthy AI experiences at scale.

Practices once considered niche disciplines within technical communication and enterprise documentation are steadily moving toward the center of business strategy.

The internet has always evolved through layers. First came static pages, then social platforms, then algorithmic feeds. AI introduces another layer entirely: interpretation itself.

The biggest change AI brings to our digital landscape is not simply that machines can create content. It’s that humans may increasingly stop seeing where that content came from in the first place, making the invisible architecture behind information one of the most important forms of infrastructure in the AI era.

The conversation about AI often focuses on what machines can create. But the more profound question may be what humans stop doing.

When AI becomes the primary interface between people and information, fewer users visit original sources, compare perspectives, examine evidence, or evaluate context for themselves. Increasingly, those responsibilities shift to the systems that retrieve, interpret, and present information on their behalf.

That makes the future of content larger than a publishing problem or a search problem. It becomes a trust problem.

The organizations that succeed in the AI era will not necessarily be those that generate the most content. They will be those that build the most trustworthy knowledge ecosystems—systems where information is accurate, structured, traceable, and resilient enough to survive multiple layers of machine interpretation.

For content pros, this represents a significant shift in responsibility. Content isn’t simply a communication asset — it’s part of the infrastructure through which people understand reality.

The era of invisible content is not really about content disappearing. It’s about the growing importance of the information architecture, governance, content provenance, and trust mechanisms that remain invisible to users but increasingly determine what they see, believe, and act upon. 🤠

Swaha Bhattacharya is a senior content strategist and technical communicator with over 11 years of experience in enterprise technology. Having worked extensively in structured content, documentation, knowledge systems, and AI-enabled experiences, she writes about the future of content strategy, information architecture, and trust in an increasingly AI-mediated world.

That’s what makes the example a useful teaching aid for tech writers looking to make the tech docs content easier for AI answer engines to process.

The topic highlights a growing problem in tech docs — content that works adequately for humans can still be highly ambiguous when AIs consume it.

Humans are remarkably good at filling in missing context. We infer relationships automatically, and we assume causality. We understand implied actors and unstated conditions because we’ve spent our entire lives navigating incomplete communication.

AI systems don’t actually “understand” any of those relationships. In lieu of understanding, they infer them probabilistically. That distinction matters.

The SimpliSafe topic contains several examples where operational context is implied instead of modeled explicitly. Those gaps create opportunities for retrieval errors, procedural confusion, and AI hallucinations.

The original topic is here: SimpliSafe: Updating Your SimpliSafe System

I evaluated the topic using TRACE, a framework I’ve been developing to identify contextual signals AI systems need in order to generate reliable answers.

TRACE looks for:

• Tasks

• Roles

• Actors

• Conditions

• Events

The goal isn’t to make documentation sound robotic. It’s to reduce ambiguity by making operational context explicit enough that AI systems don’t have to guess.

Here’s where the topic begins to break down.

Read more

👉🏾 Not because the model is “stupid.”
👉🏾 Not because the AI vendor failed.
👉🏾 Not because Mercury is in retrograde again.

The problem is probably the documentation itself.

Welcome to retrieval contamination. It’s one of those phrases that sounds like a plumbing issue in a pharmaceutical lab, but it describes a very real problem tech writers are about to spend the next several years untangling.

Retrieval contamination happens when an AI system pulls instructions, warnings, conditions, or procedural steps from the wrong source and blends them into an answer that sounds plausible enough to pass casual inspection. The AI doesn’t necessarily invent the information. In many cases, it retrieves real information from somewhere else in our documentation set and applies it to the wrong product, version, role, workflow, or situation.

That’s the important distinction. This isn’t hallucination in the classic sense (there’s no such thing). It’s often contamination through proximity.

And we’re sitting right in the blast radius.

The Documentation Equivalent Of Putting Leftovers In The Wrong Container

You know how someone puts mashed potatoes into the yogurt container and then the next morning you confidently spoon potatoes into your coffee? 😆 Hopefully not — but if something similar has ever happened in your world — it’s like that.

AI systems retrieve content by similarity. They look for patterns, relationships, terminology overlap, semantic closeness, and contextual signals. If your docs repeatedly reuses vague phrases like “press the reset button,” “restart the device,” or “update the firmware,” the system may retrieve procedures from multiple products that happen to look statistically related.

Especially if:

• the metadata is weak

• product names are inconsistently applied

• versioning is at worst, non-existent or at best, sloppy

• our docs assume human readers will “know” which product a paragraph belongs to

Humans use common sense and visual and other sensory-fueled context to separate instructions. AI retrieval systems don’t have that luxury.

To a retrieval engine, these two sentences may look dangerously similar:

“Press and hold the reset button for 10 seconds.”

and

“Press and hold the reset button until the light flashes amber.”

If the surrounding contextual clues are weak, the system may merge nearby fragments into a Frankenstein procedure assembled from multiple devices like some kind of support-ticket centaur.

Read more

👉🏾 Too complicated
👉🏾 Too rigid
👉🏾 Too enterprise
👉🏾 Too many angle brackets
👉🏾 Too old
👉🏾 Too “legacy”

And perhaps most emotionally loaded of all:

“Won’t structure kill our creativity?”

That last one always fascinated me because nobody asks airline pilots whether take-off preparation checklists suppress self-expression. Nobody asks surgeons whether standardized procedures interfere with their artistic vision while someone’s spleen is open on the table. 😷

Meanwhile, tech docs teams using structured content quietly continued doing things their less-structured counterparts struggled to manage consistently: multichannel publishing, large-scale localization, semantic metadata management, content reuse, personalization, governance, and automation.

Because XML never left – at least not in oplaces where leadership understood the business value structure provided.

The funny part is that XML’s roots in Standard Generalized Markup Language (SGML) made some people treat it like historical reenactment software. Mention SGML at a conference and some younger attendees react like you just brought up Mesopotamian irrigation techniques.

And yet, despite all the mockery, structured content systems kept quietly powering enormous documentation ecosystems behind the scenes while the rest of the industry periodically reinvented badly organized content in various ways.

Today, AI has arrived and software engineers, startup founders, and self-appointed “prompt engineers” are wrapping prompts in XML tags because they are learning some of the same lessons we learned years ago:

Computers work better when you stop making them guess.

Somewhere, a senior DITA architect just smiled so hard they startled the cat and pulled a neck muscle.

Related: XML Tutorial from W3Schools

AI Needs More Structure Than People Expect

Large language models are very sophisticated prediction systems. Which means ambiguity creates problems very quickly.

When an AI model receives a giant content hairball comprised of loosely organized technical documentation, it must infer:

👉🏾 What is context
👉🏾 What is instruction
👉🏾 What information is authoritative
👉🏾 What constraints matter
👉🏾 What format the user wants
👉🏾 Which information should be ignored

That’s a tremendous amount of interpretation (where things begin going sideways).

Tech writers understand this already because humans behave exactly the same way when our docs lack structure. 🤠

Read more

That doesn’t mean the discussion about capability is wrong; it’s just incomplete.

We’ve spent a lot of time marveling at AI’s ability to summarize, rewrite, classify, retrieve, generate, explain, translate, categorize, and answer customer questions. But somewhere behind the flashy demo, the meter is running. 💰

And not metaphorically speaking. Every AI-powered answer has a cost. The infrastructure to keep AI systems grounded, current, auditable, secure, and useful isn’t free.

Tokens cost money. Retrieval does, too.

As does inference, monitoring, rework, escalations, and human review.

Related reading: What Is Token-Based Pricing for AI Models

Recent Reporting Shows Many Companies Are Already Wrestling With This Shift

Reuters reports that Target is weighing AI tool costs as vendors move toward usage-based pricing, where token consumption and scale can quickly change the economics.

Read more

[TL;DR] Findings from the 2026 AI In Technical Documentation Survey provide tech docs leaders a useful reality check: “AI adoption” is not the same thing as “AI operationalized.”

Your team may have plenty of AI activity — people experimenting, prompting, and sharing tips — while very little of it shows up in repeatable, governed production work. That gap is where leaders can create leverage.

Respondents to the 2026 AI In Technical Documentation Survey were asked whether they were “currently using” AI tools in their tech writing work.

Here’s what we found

AI has already moved into the technical documentation toolbox in a big way.

If you are not using AI at all, you are now officially “in the minority,” which is a weird place to be for a profession built on standards and best practices.

AI is no longer the quirky side project someone tries on a Friday afternoon when the build finally stops failing.

But the numbers also show a meaningful pause at the edge of real production dependence. About one in five respondents are not using AI as a true production tool.

Bold stances in 2026 — like refusing to adopt spellcheck because you prefer the thrill of raw, unfiltered typos.

The takeaway is not “everyone is all-in.” It’s that many teams are still in the awkward middle stage: testing what works, figuring out what is safe, and negotiating where AI belongs in a process that already has enough ways to go sideways without adding a probabilistic text generator to the mix.

How Leaders Encourage AI Adoption

1. Recognize This Is A Segmentation Problem

The numbers imply at least four groups inside most tech docs organizations: regular users, occasional users, experimenters, and non-users (some curious, some opposed). Each group needs different leadership moves.

Regular users need

• guardrails

• approved workflows, and

• clear quality expectations so their output becomes consistent and auditable

Occasional users need

• friction removed — templates, sanctioned tools, and quick wins that fit existing tasks

Experimenters need

• a path from “cool demo” to “production-ready,” with criteria for when something graduates

Non-users needs

• clarity on what remains human-only and why, so they do not become silent blockers or feel pushed into unsafe behavior

2. Define What “Production Use” Means On Your Team

Many tech docs teams never cross the threshold because they cannot answer basic operational questions:

👉🏼 Which tasks are allowed?
👉🏼 Which content types are off-limits?
👉🏼 What review steps are required?
👉🏼 Where do prompts live?
👉🏼 Should we share prompts and if so how?
👉🏼 How do we log what was used and where?

Leaders of these teams can move the needle quickly by publishing a short “AI in production” definition that includes: approved use cases, required human review, citation/provenance expectations, and security rules. Without that, people keep AI use personal and unofficial — exactly what our survey result reflects.

3. Focus On Converting Workflows, Not “Adopting AI”

Pick high-volume, low-risk work where the value is obvious and mistakes are containable.

Examples: rewriting for clarity and consistency, summarizing internal release notes into customer-facing updates, drafting first-pass FAQs from resolved support tickets (with SME review), or generating examples/walkthrough skeletons.

Then standardize the workflow: inputs, prompt pattern, output format, review checklist, and a definition of done.

When leaders productize a workflow like this, AI stops being a personal trick and becomes a team capability.

4. Make The Barrier Visible: Production Requires Integration And Governance

People often stay in “occasional” mode because AI is outside the toolchain, outside the approval process, and outside compliance boundaries.

Leaders should map where AI breaks down today: security restrictions, lack of structured content, poor integration with CCMS/help center/ticketing, and unclear legal/compliance rules.

Then address the biggest choke point first. If security is the issue, clarify what data can be used, which models are approved, and whether retrieval can be constrained to a trusted knowledge base.

If integration is the issue, prioritize “AI inside the workflow” (editor, CCMS, ticketing, review) so usage becomes easy and consistent.

5. Treat Adoption As Change Management With Measurement, Not Vibes

The survey suggests many teams feel AI is helpful, but only about half are using it in production. Leaders can close that gap by tracking a few simple indicators: percentage of writers using approved workflows, time-to-first-draft for targeted content types, editorial rework rates, and defect signals (support escalations, doc inaccuracies found post-release).

If you cannot measure it, you cannot defend it — and leaders need defensible results to justify expanding use.

6. Use Skeptics As A Signal, Not An Obstacle

Every team has principled skeptics. Yours, too. Leaders can harness skeptics by involving them in risk assessment, quality checklists, and governance design.

It’s important to recognize that skeptics often improve systems because they articulate failure modes early. The goal is not 100% adoption; the goal is safe, repeatable, high-value production workflows that improve technical documentation outcomes.

The story here is not “half the field resists AI.” The story is that many experienced teams are stuck in the middle — interested, experimenting, but not operational. That’s a leadership opportunity: define production, standardize a couple workflows, remove toolchain friction, and measure outcomes so AI becomes a controlled capability rather than a private habit. 🤠

You’ll hear this immediately after someone proposes adding content typing, metadata, role labeling, taxonomy governance, semantic structure, or any other activity requiring humans to think carefully for more than seven consecutive minutes.

“The AI can infer the intent.”

“The model understands context.”

“Modern AI is really sophisticated now.”

And there it is. The magical thinking phase of enterprise AI adoption.

• Not the technical phase

• Not the governance phase

• Not the budgeting phase

The magical thinking phase. 🧞‍♂️

This is often where leaders attempt convince themselves that probability engines are somehow replacing the need for precision.

Meanwhile, tech writers are sitting in the corner like exhausted air traffic controllers wondering why everyone suddenly wants to remove the runway lights because airplanes have GPS now.

AI Does Not “Understand” Our Documentation

This is the first thing tech writers must recognize when these conversations arise.

AI systems like large language models do not understand documentation the way humans do. They don’t comprehend intention, accountability, risk, authority, or operational nuance. They predict likely relationships between patterns of words.

That distinction matters more than people realize.

When humans encounter vague instructions, they often compensate using experience, judgment, and contextual clues. We’re surprisingly good at this. We’ve had practice. Humanity has spent thousands of years decoding ambiguous instructions from bosses, governments, user manuals, and passive-aggressive family members.

AI systems compensate differently. They generate statistically plausible interpretations.

Sometimes those interpretations are correct, while other times they’re spectacularly wrong. And the more ambiguous the source material becomes, the more interpretive work the AI has to perform.

That’s not intelligence. That’s interpolation.

Ambiguity Becomes Operational Debt

For years, poorly structured documentation mostly punished humans. Our readers became frustrated. Support calls increased. New employees took longer to onboard. Procedures got skipped. Nobody enjoyed any of this, but the damage was somewhat contained.

AI changes the scale of the problem.

Now ambiguous content isn’t merely read by humans. It’s ingested, chunked, embedded, retrieved, summarized, synthesized, recombined, and operationalized by machines.

Which means every undocumented assumption suddenly matters.

• If a procedure never explicitly states who performs an action, the AI has to guess

• If preconditions are implied instead of stated, the AI has to infer applicability

• If process explanations are mixed inside step-by-step instructions, the AI has to determine which text represents action versus explanation.

If six departments all created slightly different versions of the same procedure over eight years because governance was treated like optional cardio, the AI now retrieves conflicting truths simultaneously and attempts to merge them into one coherent answer.

What emerges is often less “artificial intelligence” and more “organizational fan fiction.”

“But The AI Can Infer Meaning” Is Missing The Point

Of course AI can infer meaning. Humans can infer meaning too. That’s not the benchmark.

The real question is this:

Why are we designing enterprise knowledge systems that require inference in the first place?

Especially when the content could’ve been explicit.

This is where tech writers need to reposition the conversation. The goal of structured content isn’t to make documents prettier, more academic, or more technically fashionable. The goal is to reduce ambiguity before ambiguity becomes automation.

Because once AI systems start generating answers from our content ecosystem, every vague sentence becomes a liability multiplier.

The Difference Between Retrieval And Guessing

Consider this instruction:

“Access the admin panel and update the system configuration.”

Simple enough, right?

Except now our AI system has to determine:

• Who can perform this action?

• Under what conditions?

• Is this a required task or optional guidance?

• What happens afterward?

• What permissions are required?

• What risks exist?

• Is this production-safe?

• Is this procedural instruction or conceptual explanation?

Now compare that with content explicitly structured as:

• Task

• Role

• Preconditions

• Procedure

• Expected outcome

• Warnings

• Exceptions

Suddenly the AI isn’t “understanding” better. It’s guessing less.

That’s the entire game.

AI Has Quietly Turned Technical Documentation Into Infrastructure

This is the shift many organizations still haven’t absorbed. Docs used to be viewed as support material. Helpful, certainly. Necessary, perhaps. But still secondary to “the real product.”

AI changes that relationship.

Technical documentation is now operational infrastructure.

It feeds:

• AI copilots

• Search systems

• Support automation

• Agentic workflows

• Retrieval-augmented generation (RAG) systems

• Knowledge assistants

• Internal enablement systems

• Customer self-service platforms

Machine are now one of our primary readers. And they’re remarkably literal consumers of ambiguity.

Humans recognize that a warning ⚠️ buried four paragraphs later still applies to the earlier step. AI systems may sever that relationship entirely during retrieval.

This is why structure matters more now, not less.

Even Structured Content Can Fail AI

This part makes some people uncomfortable.

Simply having XML isn’t enough. Our docs can be perfectly valid structured content (well-formed and that conforms to a specific structure (think Darwin Information Typing Architecture or DITA) and still fail AI retrieval scenarios because the semantics of our docs are weak, incomplete, or inconsistent.

👉🏼 A task topic missing actor clarity is ambiguous

👉🏼 A process explanation embedded inside procedural steps can easily create confusion

👉🏼 A role implied through prose rather than explicitly identified forces inference

This is partly why semantic approaches like PREA — Process, Role, Event, Actor — become increasingly valuable in AI environments. They help us explicitly expose operational relationships that prose alone often obscures.

What Tech Writers Should Say When SMEs Push Back

This is where diplomacy matters.

If we frame structured content as bureaucracy, we’ll lose. But, if we frame structured content as operational risk reduction, scalability, reuse enablement, and AI reliability, people start listening.

The conversation shifts from:

to:

That’s a very different meeting. And frankly, a much more interesting one.

The Real Irony Of Our AI-Powered Work

The rise of AI is not reducing the value of disciplined technical communication. Instead, it’s exposing how badly organizations needed it all along.

For years, weak structure, inconsistent terminology, duplicated procedures, and vague ownership models survived because our readers compensated for our content chaos manually.

AI removes that safety net.

Suddenly organizations are discovering that “kind of organized” is not a machine-readable strategy. Who could’ve guessed.

Well, probably the tech writers. 🤠

For tech writers, that advice is useless on its own. The question isn’t whether we should use AI. The question is where it fits, what kind of work it should touch, and how much chaos we’re willing to invite into the building.

This post from our friends at CherryLeaf is useful because it separates AI use into four distinct approaches: web-based chatbot agents, no-code AI app builders, command-line AI systems, and workflow automations. It also makes clear that these approaches differ in skill needed, risk level, and organizational ambition.

That’s an important distinction, because too many teams talk about AI as though it were a single appliance you plug in beside the microwave. It isn’t. These are four different ways of applying machine assistance to work, and they don’t solve the same problems.

What Tech Writers Should Do With This

The practical takeaway is simple. Don’t ask, “How do we use AI?” Ask, “Which part of our work are we trying to improve?”

👉🏾 If you want faster thinking and quick experiments, start with a chatbot agent.

👉🏾 If you want a repeatable tool colleagues can use without your supervision, build a no-code app.

👉🏾 If you need AI to inspect technical systems directly, look at command-line tools.

👉🏾 If you want to change how documentation work flows across the organization, then workflow automation is the real play.

CherryLeaf’s conclusion is that chatbot agents and no-code apps are the lowest-risk entry points, while workflow automation offers the biggest transformational upside but requires more planning, stakeholder alignment, and change management.

So don’t begin with “transform documentation.” Intead, begin with one painful, repetitive task. Estimate a project. Classify release notes. Identify missing prerequisites. Trace which product changes actually need user-facing content. Start there, see what breaks, and pay attention to where the upstream information is too vague, too messy, or too dependent on tribal knowledge to support automation.

Because that’s the real gift of AI in documentation. It doesn’t just speed things up. It reveals where your process has been held together by hope, habit, and one extremely patient person named Karen.

And Karen, frankly, deserves a break.🤠

Instead, AI infers intent. —> It guesses.

When you type, “How do I reset my router?” your AI doesn’t actually know what you mean. It doesn’t know if you want to reboot your device, restore its factory defaults, reset your Wi-Fi password, or erase all of your configuration settings and start over.

A human support agent would ask follow-up questions to determine those things. Large language models, on the other hand, often try to help by choosing the most statistically likely interpretation and charging forward with unbridled confidence.

That confidence is the problem.

Most AI systems interpret intent through a combination of classification and prediction. First, the model tries to identify our user’s underlying goal. Then it tries to categorize their request into a general task type: installation, troubleshooting, configuration, account access, feature usage, compliance question, and so on. After that, it attempts to infer our missing context — product version, device model, operating system, permissions, and user role.

Finally, it assembles an answer. And this is where things can get really messy.

If the system has access to a retrieval layer (Retrieval-Augmented Generation or RAG), it pulls content from our docs and uses it to ground its response. If it doesn’t find the right content, or if it finds something incomplete, vague, or contradictory, it fills the gaps in our content using general training data and pattern recognition. In other words, it makes an educated guess.

Which is a polite way of saying: it invents plausible nonsense when it has to.

Read more