Mintlify details agent and memory design behind self-updating docs
Mintlify has published a look at the architecture behind its self-updating documentation system, which it says raised its internal docs PR accept rate from 70% to 90%. The design pairs a background agent with runner agents and relies on fixed-schema memory stored in a git-backed repo.
- Mintlify says its internal docs PR accept rate rose from 70% to 90% after rebuilding its self-updating docs architecture.
- A daily background agent edits the runner agent's triggers, skills and memory, aiming to maximize merged docs PRs while keeping the accept rate above 80%.
- Memory is kept as fixed-schema JSON files in a git-backed repo, which Mintlify says makes upkeep easier to scope and evaluate.
- Mintlify built its own harness on Vercel's AI SDK; against Pi it matched performance on an offline eval but used 50% fewer tokens, according to the company.
- The architecture powers Autopilot, which Mintlify has just launched.
A background agent supervises runner agents
According to Mintlify, the system is split into a background agent and a runner agent. Both run as an agent loop with access to a sandbox, the ability to clone repos, read access to third-party integrations, and a shared memory.
Triggers drive the work. They can be cron schedules, merges in a repo, or events in third-party tools, such as a project being marked as done in Jira. Each trigger is tied to a skill. When one fires, a job is queued for a runner agent, whose output is most often a documentation PR followed by a notification asking the right people to review it.
The background agent runs daily for each site. Its system prompt tells it to take ownership of the documentation's success, and its optimization function is to maximize the number of merged docs PRs while keeping the accept rate above 80%. It can create, read, update and delete the runner's triggers, their skills and the shared memory, using past run logs, connected integrations, docs analytics and PR acceptance data.
Mintlify gives one example. A trigger listening for PR merges in a code repo kept producing CLI docs PRs that were closed, because the CLI ships on a rolling release cycle. The background agent removed CLI changes from that skill and created a monthly cron trigger to write CLI release notes instead.
An in-house harness and fixed-schema memory
Mintlify built its own harness. The company says it had tried OpenCode and Pi but found they abstracted away too many engineering decisions to perform well in its environment and match its data models. The harness uses Vercel's AI SDK to loop LLM calls and expose tools, with custom tools for subagents, compaction, following up on other runs, forking the current session, using skills, and running shell commands piped to a sandbox. On an offline docs eval suite, Mintlify says its harness performed similarly to Pi, but Pi used 50% more tokens.
The company calls the infrastructure table stakes and says the harder part is memory design. The agent must know which team owns a change, where they discuss it, whether docs should build on a rolling release, and who should review it and how. Mintlify stores this in fixed-schema JSON memory files. A simplified release type includes code PRs, stakeholders, planning docs, whether to commit directly or open other PRs, a date before which drafting should not start, and communication details such as channels and threads.
The same granularity applies to users, style guides, site-wide settings and each integration, with files for issue management, knowledge management, support platforms, communication and code repos. A few free-form markdown files remain for areas that are hard to break down.
Mintlify argues that deciding what to remember is hard for LLMs, and that free-form files may be underused, grow verbose or lose key information. A structured schema makes memory upkeep a well-scoped task and allows offline evals, for example by labeling users in an organization and measuring the share of fields the agent gets right.
Over-the-air updates and run logs
Because each agent's setup is a web of skills, tools and memory files, even a small change to a preset skill could break a customer's setup. Mintlify addresses this by sending each background agent a plain-text description of breaking changes. The agent audits its setup for regressions, monitors going forward and updates its memory files to match new schemas.
The company says it used this to roll out support for larger code releases. Agents with connected repos deleted legacy fields, scanned codebases to index larger features, stored memory artifacts and spun off runner agents to implement them. Mintlify also suggests the same channel could introduce new products, such as automated product screenshots, by sending a document to each background agent, which could judge whether a customer is likely to enable it and whom to notify.
Run logs are stored as JSON in the memory repo. Each session is an array of messages and outputs. Forking creates a new session pointing to the latest message of the current one, so sessions form a tree mirrored as nested folders. A leaf session's full history can be rebuilt by traversing up to the root.
What it means
Mintlify says this architecture now powers Autopilot, which it has just launched. For teams that maintain documentation, the account points to a design in which agents tune their own triggers and skills against merge outcomes, with structured memory keeping them informed about owners, reviewers and release timing. The 70% to 90% accept rate is an internal figure reported by the company.
Mintlify: The Harness and Memory Architecture Behind Self-Updating Docs
