The more a business automates, the bigger a specific, quiet risk grows: nobody quite remembers what runs where, what each workflow actually touches, or what would break if it stopped. It's a strange failure mode, because it's caused by the automation succeeding — the more workflows quietly do their job without anyone thinking about them, the easier it becomes for the knowledge of how they fit together to live in exactly one person's head.
The problem shows up at the worst possible moments
Nobody notices a documentation gap while things are running smoothly. It shows up during a handover, when a new hire has to take over a stack of automations nobody wrote down. It shows up during an audit, when someone needs to explain what happens to customer data and the honest answer requires reconstructing five different workflows from memory. It shows up the moment something breaks and the person who understood the system is unavailable. In every case, the cost of the missing documentation was there the whole time — it was just invisible until the exact moment it wasn't.
What we built instead of a wiki nobody updates
The obvious answer — "write documentation" — fails in practice because documentation written once immediately starts going stale the moment the automation it describes changes, and nobody enjoys maintaining a wiki page for a workflow they already understand. So we built an automation that documents the automations: on demand, it queries the n8n API directly for every active workflow, walks each one's triggers, connected apps, and steps, has AI draft a plain-language description of what it does and why it matters, and publishes the result to a shared Google Doc the client owns outright.
The design choice that makes this actually work, rather than becoming one more stale document, is querying the live API rather than relying on anyone's notes. The documentation reflects what's actually running right now, not what someone remembers deploying six months ago — because it's regenerated from the real system state every time it runs, not maintained by hand between runs.
Why "the client owns it" is the point, not a footnote
The output lands in the client's own Google Docs workspace — readable, shareable, and genuinely theirs, in no proprietary format and with no dependency on whoever built the automations to explain what they do. That's a deliberate stance against a specific bad pattern in this industry: a vendor whose value depends on the client not fully understanding their own systems. An automation stack that only the person who built it can explain isn't really the client's system — it's a black box with the client's name on it. Self-documentation is the concrete, checkable version of not doing that.
What to check in your own automation stack
If you're running more than a handful of automated workflows, ask two questions honestly: could someone other than the person who built them explain, right now, what each one does and what it touches — and if the answer is "not really, not without asking," that gap is worth closing before a handover or an audit forces the question at a worse time. It doesn't have to be a system as elaborate as the one described here. Even a deliberately maintained, honestly-updated list of "what runs, when, and why" beats the alternative, which is one person's memory being the only documentation that exists.