The eight families of AI workflows for technical writers

We have been researching the different AI documentation workflows technical writers use, as part of developing our new Managing documentation projects with AI e-learning course, and we discovered they fall quite neatly into eight broad families.

1. AI as a researcher or explainer

The first family is one of the simplest, and often one of the most useful. Here, AI helps the technical writer understand something.

For example, you might ask an AI assistant to:

• explain an unfamiliar codebase
• describe how an API works
• compare two configuration files
• identify patterns in source material
• summarise a technical discussion
• suggest questions to ask a subject-matter expert

The output is not necessarily documentation.

It might simply be a better mental model of the product.

A typical workflow might look like this:

1. Source material
2. AI explanation
3. Writer checks understanding
4. Vetter questions

This is close to what Fabrizio Ferri-Benedetti describes as the “watercooler” mode of AI-assisted technical writing. The AI acts as someone you can talk through a problem with.

That can be particularly useful at the start of a documentation project, when the writer is trying to understand a new product, feature or architecture.

The main risk is the explanation may sound convincing while being wrong.

So the AI should be treated as an aid to understanding, rather than as an authoritative source.

2. AI as an outlining and planning partner

The next step is to use AI to help organise information.

Technical writers often begin with a mixture of inputs:

• meeting notes
• product specifications
• tickets
• SME comments
• existing documentation
• requirements
• design documents

Turning those into a coherent documentation plan can take a surprising amount of work.

AI can help identify themes, group related information, highlight possible gaps and suggest an outline.

For example:

1. Notes and specifications
2. AI identifies themes
3. Proposed outline
4. Writer revises
5. Documentation plan

This can be a relatively low-risk use of AI. The AI is not making the final publishing decision. It is helping the writer see possible structures.

An AI-generated outline is not automatically a good information architecture. The writer still needs to consider the audience, their tasks, the product context and the purpose of the documentation. But AI can remove some of the mechanical work involved in getting from a pile of source material to a structure that can be discussed.

3. AI-assisted authoring and editing

This is probably the most familiar family.

AI can help:

• draft a first version
• rewrite a difficult paragraph
• shorten or simplify text
• change the format of content
• suggest examples
• apply a style guide
• perform a first editorial pass
• provide inline writing assistance

There are different levels of involvement:

• At one end, the technical writer remains the main author and uses AI occasionally for suggestions.
• At the other, the AI produces much of the initial draft and the writer becomes more of an editor and verifier.

A common pattern is:

1. Trusted source material
2. AI drafting or editing
3. Human review
4. Verification
5. Publication

If the model has insufficient or unreliable context, improving the prompt will only take you so far. The quality of the workflow depends heavily on the quality of the information supplied to the AI.

This is why prompt engineering is only part of the story. Context engineering is often more important.

8. Documentation for AI readers

The final family reverses the direction of the relationship.

Increasingly, AI systems are also consumers of documentation.

Coding assistants and agents may retrieve product documentation while trying to:

• write code
• configure software
• troubleshoot a problem
• call an API
• complete a development task

That raises a new question: Can an AI agent successfully use our documentation?

Technical writers are beginning to experiment with:

• agent-friendly documentation structures
• concise reference material
• machine-readable content
• llms.txt
• product skills
• better navigation and information architecture
• documentation entry points for agents
• testing documentation with real AI agents

Dachary Carey, Tom Johnson, Sarah Deaton and others have explored aspects of this problem.

One of the more useful ideas is to test rather than guess.

Give an agent a realistic task and observe what happens.

Can it find the right page?

Does it retrieve the important part?

Does it interpret the example correctly?

Does it follow links successfully?

Does the documentation actually help it complete the task?

This is likely to become another audience consideration for technical communicators.

Not necessarily “write separate documentation for robots”, but rather make authoritative documentation easier for both people and machines to find and use.

Another way to view the eight families: autonomy

The eight families do not form a strict maturity model.

You might use several of them in the same documentation project.

However, there is another useful way to look at them: how much autonomy the AI has.

At one end, the AI mainly helps the writer think.

For example:

1. Explain
2. Suggest
3. Draft

The human is closely involved.

As workflows become more automated, the AI may begin to:

1. Edit
2. Execute
3. Monitor
4. Repair

The human role changes.

This does not necessarily mean the human disappears. Instead, the work shifts.

At lower levels of autonomy, the technical writer may inspect every output.

At higher levels, the technical writer may spend more time:

• designing the workflow
• defining trusted sources
• setting permissions
• establishing review points
• deciding what must be deterministic
• monitoring results
• handling exceptions

In other words, the role moves from performing every task towards designing and governing the system that performs the tasks.

For more information, see Managing documentation projects with AI e-learning course,