Docs Your Agent Can Read: Why the Notis Help Centre Runs on Mintlify

Here's a question that didn't exist five years ago: can an AI agent read your documentation?

Not "is it on the internet." Can a model fetch it, parse it, and give a user an accurate answer without a human in the loop? Because for a product like ours, that's increasingly how people meet the docs — through an assistant, not a search bar.

The Notis Help Centre runs on Mintlify, and that turned out to matter for reasons beyond it looking nice.

Docs as code, because our docs change as fast as our code

Notis ships constantly. New channels, new tools, new integrations, new behaviour in the agent. Every one of those has a documentation consequence, and the consequence lands at the same time as the change — not in a content sprint two weeks later.

With Mintlify, the Help Centre is MDX files in a repository with a docs.json that defines navigation. That means documentation changes arrive the way code changes do: in a branch, in a diff, reviewable, revertable.

The practical effect is one I didn't predict. A coding agent can update the docs. When I hand a task to an agent and the task changes user-facing behaviour, updating the relevant .mdx file is part of the same job as changing the code. It's a file edit in a repo it already has. If the Help Centre lived in a separate CMS behind a login, that would be a second system, a second credential, and — realistically — a step that gets skipped.

Documentation rot is almost always a workflow problem rather than a discipline problem. Putting docs in the repo fixes the workflow.

What we actually built with it

Our Help Centre isn't a feature list. It's organised by what someone is trying to do: getting started, channels, core capabilities, your computer, agent routing, apps, account and settings — and a large guides section for end-to-end workflows.

That guides section is the part I'd point at. Notis connects to a lot of other tools, so a meaningful chunk of our documentation is "here is how to wire this specific product to Notis and what you get." Each one is a self-contained page with prerequisites, numbered setup steps, example prompts, and troubleshooting.

Mintlify's components do real work there. Tips and callouts separate "you must do this" from "you might like this." Code blocks carry exact server URLs and header values that people paste. Embedded video sits inline where a walkthrough helps more than prose. None of that is exotic — but building it from scratch is a week I'd rather spend elsewhere, and maintaining it is forever.

There's a lastUpdated field on pages, which sounds trivial and isn't. For an integration guide, "when was this last verified" is often the most important thing on the page.

The AI-readability part

Back to the question at the top.

A large and growing share of the traffic that reaches documentation is not a person browsing. It's a model fetching a page to answer someone's question, in ChatGPT, in Claude, or — in our case — inside Notis itself, because users ask the assistant how the assistant works.

That reframes what good docs are. Structure beats styling. A page with clean headings, explicit prerequisites, and literal values in code blocks survives being read by a model. A page whose meaning depends on layout, screenshots, or a clever visual hierarchy does not.

Mintlify's output is clean, server-rendered, semantically structured HTML. That's not a marketing feature — it's what makes the content survive extraction. And because it's MDX underneath, the source is already in the format models handle best.

The honest version of this: I don't have an attribution study proving how many conversions start in an AI answer. I can tell you it's a growing share of how people encounter documentation, and that the cheapest way to be represented accurately is to publish structured, current, checkable content. Docs-as-code makes "current" achievable. Clean rendering makes "extractable" free.

The trade-offs

Two, and both are real.

You need people who are comfortable with Git. For us that's a non-issue — it's the same repository, and agents can edit it. For a team whose documentation is written by people who've never opened a terminal, a hosted CMS may genuinely be the better tool. Pick the workflow your writers will actually use.

You're on someone else's rendering layer. Themes, components, and search behaviour are theirs. We've wanted the occasional thing that wasn't there. The counter-question is always the same: is a custom docs site something I want to own for the next five years? It isn't.

Mintlify hosts our Help Centre and we're straightforward about it — attribution is visible on the site rather than tucked away.

If you're setting up docs for an AI-era product

1. Put them in the repo. The single highest-leverage decision, because it makes updating them part of shipping.
2. Organise by user intent, not by your internal architecture. Nobody looks for "the webhooks module."
3. Write for extraction. Real headings, explicit prerequisites, literal values in code blocks, no meaning carried by pictures alone.
4. Date your integration pages. A guide to someone else's product is a perishable good.
5. Let your agents write docs. If updating a page is a file edit, it happens. If it's a separate system, it doesn't.

Notis is founder-led and moving quickly, which means our Help Centre is under constant edit. It keeps up because it lives where the code lives.

Mintlify is what makes that setup pleasant instead of a side project.