> How one agent became a seven-phase pipeline of small ones, and the engineering behind each split.

Canonical: https://www.veludocs.com/blog/building-a-help-center-pipeline/

[← ALL ARTICLES](/blog/) ·ENGINEERING ·NOV 3, 2026 ·9 MIN READ 

# How Our AI Agents Write a Help Center From a Login

A

Aravind C

VELU

SHARE [𝕏](#) [in](#) 

〉 SUMMARY

How one agent became a seven-phase pipeline of small ones, and the engineering behind each split.

Every software company has the same problem: the help center is always behind the product. Screens change, buttons move, new features ship, and the docs describe last quarter’s app.

Most “AI docs” tools start from the code: connect your repo, and they read it. In practice that’s where many conversations end. Companies push back on sharing source code with an outside vendor, and they have good reasons: security reviews, IP, contracts, or simply a policy that the repo never leaves the building.

But every company that wants a help center already gives a login to new employees, QA testers and trainers. So we asked a different question: **what if a system used the product the way a new employee would, and wrote the help center from what it saw?** No repo access. Just a login.

It turns out that’s also closer to what readers need. A store manager approving the day’s cash or a buyer receiving goods never sees the code. What they need to know lives in the screens.

Give it a web address and a login, and it delivers a help center: written guides, screenshots and short videos.

It started as one agent. It’s now a pipeline of seven phases. This is the story of how it got there.

## The First Try: One Agent Does Everything

Our first version was simple. We gave one agent a browser and asked it to explore the product and write the docs.

For a small app, that almost worked. For a real business product, with dozens of areas and hundreds of screens, it broke in two ways.

The first was cost. Every screen the agent looked at went into its memory, and so did every page it wrote. And every time it took a step, it re-read all of it. So the bill didn’t just grow with the run, it grew much faster than the run. When its memory filled up, the agent started squeezing its own notes to make room. The first things it threw away were exactly what a help article needs: the exact button names, the order of the steps, the names of statuses.

The second was coverage. The agent picked where to go on its own. It spent a lot of time in some areas, barely looked at others, and stopped when it ran out of room. We had no list to compare against, so we couldn’t even tell what it had missed.

## Splitting Off Research

Both problems had the same fix: don’t ask one agent to explore and write. We made exploring its own step.

The research agent signs in and goes through the product one area at a time, working from a list. On each screen it takes notes, which we call the **map**: what’s on the screen, what each button does, and what happened when it tried things. It also writes a short summary of the business: who uses the product and which tasks matter most to them.

Exploring is mostly clicking around, reading and writing things down. There’s a lot of it, but none of it is hard, so research runs on **Haiku**, a small, cheap model. And because it works from a list, we can finally check that nothing was skipped.

The map turned out to be the most important part of the system. Everything after this step has to stick to it. If the map doesn’t say it, the docs don’t say it.

## A Better Writer

Once we had the research, we tried letting Haiku write the pages too. It was cheap, but the pages weren’t good enough. A good help page means picking what matters, getting the steps in the right order and explaining things to someone who isn’t technical. That takes judgment, and the small model didn’t have enough.

So we switched the writing to **Sonnet**. We learned something we kept coming back to: exploring and writing need different skills, and you don’t have to pay top price for both.

## One Writer Becomes Many

Then the cost problem came back. One Sonnet writer doing the whole site had to keep all the maps and every page it had already written in its head. That got bigger with every page, and so did the bill.

So we split again. First, a **planner** reads the research once and decides the topics: every page, which section it goes in, and in what order. Each page covers one task a user does, like “Cancel an order”, not one screen, like “The Orders screen”. We tried Haiku for planning first, and the plans were poor. Laying out a whole site takes judgment, so the planner runs on Sonnet too.

With the topics decided, we start one writer per page, all at the same time. Each writer only gets its own topic and the notes for the screens that page uses. Its workload stays the same size no matter how big the product is, so cost grows with the number of pages, and not faster than that. And since the pages don’t depend on each other, drafting takes about as long as the slowest page, not all of them added up.

Planning by task fixed a writing problem too. When writers worked straight from screen notes, they wrote what we started calling “screen speak”: a tour of everything on the screen instead of help getting something done. Give a writer a task instead of a screen, and the page reads the way the reader thinks.

## The Editor

AI writers fill gaps with guesses that sound right, like “click **Save**” when the button says **Submit**. And a writer checking its own page just agrees with itself.

So a separate **editor** reviews every page. It keeps the style consistent and cuts any claim it can’t trace back to the map.

But what counts as “right” changes from business to business. A bank wants a formal tone and never says “just”. A retail app calls them “stores”, not “locations”. One team wants every page to start with who it’s for, another wants straight to the steps. Some terms must never appear in public docs at all. No single set of rules fits everyone.

So the editor’s rules live in a `SKILL.md`. We ship a sensible default, and each team can make it their own.

## Mock Data

The pages needed pictures, and pictures need data on the screen. Companies usually give us a test or staging account, and the data in those is rarely pretty: customers named “test test”, orders for $0.01, half-empty lists, records nobody cleaned up. That’s fine for QA. It’s not what you want in a help center. Readers should see screens that look like a real business using the product. And if every page shows different records, the site feels pieced together.

So before any screenshot is taken, a Haiku agent uses the browser to look at how the product’s front end gets its data: which API calls each screen makes and what the answers look like. Then it creates one believable set of **mock data** for the whole product, so the same sample records show up on every screen. When we take screenshots, our browser swaps in that mock data on its way to the screen. Nothing is written back to the product: the account’s real data is never touched, and the moment the browser closes, the product looks exactly as it did before. The help center looks like a real business, stays consistent from page to page, and never shows the account’s own records.

## Screenshots and Videos

People want to see where things are. “Click **Assign** at the top right” is much easier to follow with a picture of the screen next to it, and a longer process is easier to follow as a short video.

Each draft lists the pictures it needs. A Haiku agent opens the real product, loads the mock data and captures them.

The bigger challenge comes later. Products change. A button moves or a column gets added, and the screenshot is now wrong without anyone noticing. So we keep a list of every screenshot and video, the screen addresses it goes through, and the pages that use it. When a customer tells us a screen changed, that list shows exactly which pictures and pages need updating. One changed screen means a few new captures, not starting over.

## Publishing

The last step doesn’t use AI at all. The result is a [Velu](https://veludocs.com) docs-as-code site, so we can check it the way you check code. The `velu` command-line tool checks the settings, the navigation, the links between pages and the images. If a picture couldn’t be captured, it’s taken out and marked as failed, so readers never see a broken image. Then the site goes live through the same build process as every other Velu site.

## Where It Ended Up

Looking back, we did the same thing six times: whenever an agent got too big, we split it.

| Step                 | Model                | Why we split it off                                                |
| -------------------- | -------------------- | ------------------------------------------------------------------ |
| Research             | Haiku                | One agent cost too much and missed parts of the product            |
| Planning             | Sonnet               | One writer used too many tokens, and Haiku’s plans were poor       |
| Writing              | Sonnet, many at once | Better writing, and small workloads keep cost down                 |
| Editing              | Sonnet               | Consistent style, and every claim backed by research               |
| Mock data            | Haiku                | Test data looks bad; readers need real-looking, consistent screens |
| Screenshots & videos | Haiku                | People need to see where things are                                |
| Publishing           | velu CLI             | Checked like code, shipped like code                               |

A pattern came out of it. Haiku handles the large amount of simple work in the browser: exploring, studying the data, taking pictures. Sonnet handles the parts that need judgment: planning, writing and editing.

## What We Learned

Most of what we learned is really one lesson, seen from different angles.

When an agent has to remember too much, split it up. We did that for research and again for writing, and both times it made things both cheaper and better.

Pay for judgment, not for volume. A small model is fine for clicking through a thousand screens. It’s not fine for deciding what a reader needs.

ON THIS PAGE

[The First Try: One Agent Does Everything](#the-first-try-one-agent-does-everything)[Splitting Off Research](#splitting-off-research)[A Better Writer](#a-better-writer)[One Writer Becomes Many](#one-writer-becomes-many)[The Editor](#the-editor)[Mock Data](#mock-data)[Screenshots and Videos](#screenshots-and-videos)[Publishing](#publishing)[Where It Ended Up](#where-it-ended-up)[What We Learned](#what-we-learned) 

〉 KEEP READING

[ ![](https://ik.imagekit.io/wgcu5dez6opg/VeluAstro/Velu%20Blog/Covers/document360-alternatives-cover.png?tr=w-800) Oct 24, 2026 · 18 min 8 Best Document360 Alternatives for 2026: Product Docs, Help Centers and Knowledge Bases ](/blog/document360-alternatives/)[ ![](https://ik.imagekit.io/wgcu5dez6opg/VeluAstro/Velu%20Blog/Covers/swagger-alternatives-cover.png?tr=w-800) Oct 24, 2026 · 19 min 8 Best Swagger UI Alternatives for API Documentation in 2026 ](/blog/swagger-alternatives/)[ ![](https://ik.imagekit.io/wgcu5dez6opg/VeluAstro/Velu%20Blog/Covers/docusaurus-review-cover.png?tr=w-800) Oct 10, 2026 · 14 min Docusaurus Review 2026: I Built a Site to See If It Holds Up ](/blog/docusaurus-review/)

AI content index: https://www.veludocs.com/llms.txt