Philosophy
Information Architecture & AI
Last updated: September 2026
I don’t think the most interesting use of AI in technical content is writing content faster. It’s making sure the information underneath those sentences is worth reasoning from.
Language does more than communicate ideas; it organizes attention.
That idea shapes how I approach technical writing. On a complex product, I am rarely just explaining what something does. I am deciding what a reader needs to understand first, which concepts belong together, which distinctions must remain intact, what deserves a name of its own, and where new information fits within what the reader already knows.
In other words, I am building a conceptual map so readers can form a mental model of how the system works.
People need conceptual maps
People need those maps, and so does AI.
I saw the human side of that principle while reorganizing a large RPA documentation portfolio. The individual topics contained useful information, but having the information available did not give readers a model for navigating the product.
I reorganized the documentation around the work people actually needed to do: learn, build, manage, secure, and troubleshoot.
Structure is part of the explanation
That choice was more than navigation. It established relationships between information and showed readers what kind of information they were looking at and where it belonged in the larger system. The prose still mattered, but prose alone could not provide that structure.
I ran into the same problem in a more complicated form while documenting AI agents.
An AI agent can be described through prompts, models, tools, resources, authentication, deployment, monitoring, security, limitations, and human oversight. Every one of those subjects can be explained clearly and accurately on its own.
That still doesn’t guarantee that someone understands an agent.
The harder questions are relational.
What is the agent responsible for? What belongs to the model and what belongs to a tool? What is configured ahead of time and what happens at runtime? Where does authentication occur? Which limitations come from the underlying model, and which come from the product around it?
Clarity is not the same thing as understanding
Those distinctions help readers build a mental model. Polished prose can make a weak conceptual map harder to notice.
That matters even more when large language models enter the content workflow.
LLMs are very good at producing coherent language. Give a model enough material and it can summarize it, combine it, rephrase it, retrieve from it, and turn it into something remarkably fluent.
But coherence does not mean understanding.
What AI does with weak information
If two product concepts are named inconsistently, a model may treat them as interchangeable. If authoritative sources disagree, it may reconcile them into one smooth explanation instead of preserving the disagreement. If relationships between concepts are unclear, it may infer relationships that were never intended.
The result can be wonderfully clear and subtly wrong.
I’ve seen all three in my own work.
Good architecture makes AI better
The opposite is also true.
Give an LLM well-structured source material, intentional terminology, meaningful relationships, and clear authority, and it becomes much more powerful. It can reinforce consistency, expose information at different levels of detail, help people find what they need, and make a strong information system usable at a much larger scale.
That is why I don’t use AI to avoid information architecture. I use AI to help test and refine the architectural decisions that I make.
I don’t consider seamless prose evidence that the underlying information is sound. I don’t collapse two terms simply because a model thinks they mean roughly the same thing. And I don’t want AI to make ambiguity disappear when that ambiguity is telling me something important about the product.
An LLM sometimes reminds me of a student who has mastered the formula. It recognizes the pattern, follows the rules, and produces the expected answer. But the interesting questions come next: Why does this formula apply here? What assumptions make it valid? What changes when one of those assumptions changes? When should we use a different formula entirely?
Those questions require a model of the problem, not simply mastery of its language.
How I work
That’s the level at which I like to work.
I am a technical writer, but I work above the individual page as well: defining concepts, challenging ambiguous terminology, establishing relationships between information, organizing content around the way people need to understand a system, and creating structures that both humans and AI can reliably use.
AI gives us an extraordinary ability to generate, transform, and retrieve information at scale.
My job is to make sure the structure underneath it deserves that scale.