Mintlify's Self-Updating Docs Agent: Fixed-Schema Memory, Run-Log Trees and a 70% to 90% Accept Rate Claim

Mintlify published "The Harness and Memory Architecture Behind Self-Updating Docs" on October 30. The most reusable idea is the memory design: instead of letting an agent write free-form notes, store memory as JSON files with a fixed schema, so that "what should we remember" becomes a narrow task you can evaluate. The post also describes a second agent that tunes the first one.

Everything below is Mintlify's description of its own system. The metrics are internal and I could not check them. I read the post and one companion announcement (Mintlify Base). I did not use the product or read the linked posts on Autopilot or on why self-updating docs are a big market.

The architecture as described

Two agents, both an agent loop with a sandbox, the ability to clone repos, read access to third-party integrations and a shared memory:

• Runner agent. A trigger (a cron schedule, a merge in a repo, or an event such as a Jira project marked done) is tied to a skill. When it fires, a job is queued for a runner agent to execute that skill. Most often the output is a documentation PR, followed by a notification asking the right people to review.
• Background agent. Runs daily for each site. Per the post, its system prompt tells it to take ownership of the docs' success, and its optimization function is to maximize merged docs PRs while keeping the accept rate above 80%. It can create, read, update and delete the runner's triggers, skills and the shared memory, using past run logs, connected integrations, docs analytics and which PRs get accepted.

The post's example: a trigger on code-repo merges kept producing CLI docs PRs that got closed, because the CLI ships on a rolling release cycle. The background agent noticed, removed CLI changes from that trigger's skill, and created a monthly cron trigger for CLI release notes.

Memory is a git-backed repo of memory files, with every agent run log stored as JSON.

The harness

Mintlify says it built the harness in-house after trying OpenCode and Pi, which it found "abstracted away too many of the underlying engineering decisions". It uses Vercel's AI SDK to loop LLM calls and expose tools, plus 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, it says its harness performed similarly to Pi, while Pi used 50% more tokens. I do not know the suite, the tasks or the Pi configuration.

Fixed-schema memory

The post argues the infrastructure is table stakes and the hard part is the memory scaffolding, custom tools and preset skills. Its approach is a set of fixed-schema JSON files. For a large feature release, the simplified type includes code PRs, stakeholders, planning docs, whether to commit directly or open other PRs, a "don't start drafting before" date, and communication channels and threads. The same granularity applies to users, style guides, site-wide settings and each integration. A small number of free-form markdown files remain where the team could not break the content down.

Its stated reasons:

• Deciding what to store for future runs is hard for an agent, and the post says LLMs are not particularly good at it. Free-form markdown may get underused, grow verbose, or lose key information.
• With a schema, memory upkeep is a well-scoped task (for example, find all code PRs for a release) that can be evaluated offline. The example given is labeling a dataset of users with expected attributes and measuring what share of fields the agent gets right.
• A structured format gives developers a clearer sense of what the agent knows.

Over-the-air updates

Each agent's setup becomes a web of skills, tools and memory files, and even a small text change to a preset skill could break a customer's setup. Mintlify's answer is a plain-text description of breaking changes, sent as a prompt to each background agent, which is told to audit its setup for regressions, monitor going forward, and update its memory files to the new schemas.

The post says this was used to roll out support for larger code releases: each background agent with connected repos deleted legacy fields and started indexing larger features. It also suggests the same channel could introduce new products, by sending a document about the feature and letting the agent decide whether the customer is likely to want it and who to notify.

Run logs as a session tree

Each session is stored as an array of messages and outputs in JSON. Forking creates a new session with a pointer to the most recent message of the current one, so sessions form a tree mirrored as nested folders. A leaf session's full history is rebuilt by walking up to the root and stitching sessions together.

The numbers

• "Internally our docs PR accept rate has gone from 70% to 90%."
• Pi used 50% more tokens than Mintlify's harness on its offline eval, with similar performance.

The post closes by saying the architecture now powers Autopilot, which Mintlify "just launched", and that it is "excited to see if it holds as we scale". The accept-rate figure is internal, so it says nothing about how external customers fare.

Context from the Base announcement

The companion post of October 29, "Introducing Mintlify Base", says Base is in beta, a workspace where people and agents work from the same internal specs and runbooks. It says agents account for more than three-quarters of the traffic to docs Mintlify hosts, that pages are Markdown files, and that a controlled experiment with a large engineering team using Claude Code on monorepos found structured Markdown used about half the tokens and made agents 64% more precise. It lists page verification as "coming soon". These are also vendor claims.

What I would check

These are my untested suggestions.

1. Define "accepted" before you quote an accept rate. Is it merged, merged without edits, or merged and not reverted? The post does not say.

2. Look at the incentive. An agent asked to maximize merged PRs while holding accept rate above 80% could drift toward easy, low-risk changes. I did not see the post address this, so check what your equivalent agent stops doing.

3. Limit what a tuning agent can change. The background agent can edit triggers, skills and memory. Decide which of those need a human review, and log every change.

4. Try a schema for one memory area and score it, as the post describes for user attributes, before you move everything.

5. Treat update prompts as code. A plain-text breaking-change prompt sent to agents has no type checking. Test it on one agent first.

6. Keep run logs queryable. The tree layout only helps if something reads it.

What I would not conclude

• That fixed schemas beat free-form memory in general. The post gives reasons, not a comparison I could read.
• That a 90% accept rate will carry over to your docs. It is Mintlify's internal figure.
• That building your own harness is better than using one. Mintlify says its choice fit its data models, and the Pi token comparison is one offline eval.
• That the system runs without review. The post says the runner's output is usually a PR followed by a review notification.

Frequently asked questions

What is the background agent?

A daily agent per site that edits the runner agent's triggers, skills and shared memory, aiming to maximize merged docs PRs while keeping accept rate above 80%, per the post.

Why fixed-schema memory?

Per Mintlify, it makes memory maintenance a scoped task, supports offline evals, and shows developers what the agent knows.

How are agent changes shipped?

By sending each background agent a plain-text description of breaking changes as a prompt, and asking it to audit and update its memory.

How are run logs stored?

As JSON files in the memory repo, with forked sessions nested in folders to form a tree.

Is the 70% to 90% accept rate independent?

No. The post calls it internal.

What is Mintlify Base?

Per the October 29 announcement, a beta workspace for internal knowledge that people and agents share, with a built-in MCP server and Git-backed Teamspace.

Did you try Autopilot?

No. I did not use the product, and I did not read the linked Autopilot material.

Sources

All read on October 31, 2026.

• The Harness and Memory Architecture Behind Self-Updating Docs (Mintlify, October 30, 2026)
• Introducing Mintlify Base (Mintlify, October 29, 2026)

Not read: the Autopilot announcement, the "why self-updating external docs" post, the Base docs, and the eval suites behind the quoted figures.