The help center was always a stopgap

Why the knowledge base goes stale

Every knowledge base is a memo to your future self. You write it because you cannot be in the room when the user gets stuck. The words you leave behind are the only thing standing between them and the support queue.

The room keeps changing. Your product shipped fourteen times last week. The button that was on the right is on the left. The setting that was three clicks deep is two. The flag that was internal is GA. None of those changes are described anywhere in the docs your help center is built on, because nobody had time. They had time to ship the change. They did not have time to write a sentence about it. The product tours point at buttons that moved. The user guides describe last month's flow. The release notes cover a version nobody is running.

An article-based assistant cannot close this gap. It is trained on memos that are already stale, and the future has already happened.

What teams keep trying

We've watched teams try to pay the freshness tax on customer onboarding content. The playbooks look the same everywhere:

1. Doc CI (P1 effort, P2 outcome). Catches the obvious changes, misses the gnarly ones. A modal that moved two pixels to the left, copy that shifted from "Export" to "Download," a permissions gate that only shows up on the trial plan.
2. Required help-center updates per PR (P0 effort, P3 outcome). Writers become a release blocker. Engineering routes around them.
3. Quarterly content audits (P2 effort, P2 outcome). Finds everything. Fixes nothing in time.

Three reasons none of it holds. First, the work that breaks the docs is the work that pays for the docs team. You can't slow engineering to save docs without losing the thing that made the docs valuable. Second, audits catch what changed in the UI but miss what changed in the user's experience. Third, writers ship the wrong unit of work: articles instead of behaviors.

What we built instead

The bet is that the answer is not better discipline around documents. The answer is to stop relying on documents at all.

If your assistant has to read about the product to know it, it will always be one ship behind. So we built one that uses the product instead.

The agent learns the way an SE learns: it logs in, navigates the product, and builds its own understanding of what's where. It has the credentials, the patience to try things in the order a real user would, and the memory to notice when the product changed under it. Next time someone asks "where did the export button go?", it knows. It just used the export button five minutes ago.

What changes when the product is the source of truth

Freshness stops being a problem you manage. There is no longer a window between "we shipped this" and "the assistant knows about it." Whatever you ship, the agent observes.

The agent meets users where they actually are. Articles describe the typical case. Real users are atypical. They are on the trial plan, in the EU, with permissions you didn't anticipate. An agent that uses the product can branch into the user's actual state instead of reading them a paragraph that mostly applies.

Gaps get surfaced, not papered over. When the agent doesn't know something, it either tries the action and reports back, or it hands the conversation to a human with the context already gathered. No confident-sounding summaries of articles that were already wrong.

The slower change is culture. Once a team stops shipping documentation as a deliverable, it stops asking "what does the user need to read?" and starts asking "what does the user need to do?" That second question is better, and it leads to better products.

We don't think every team needs a help center. We think every team needs a competent agent that has actually used their product. Those two have looked the same for fifteen years but they don't have to.

If y'all are hitting this, we'd rather hear how than guess.