Retire the article a release overtook, surface the questions the corpus never answers and mark what no one owns, then hold each revision for the documentation owner who decides what is published.
An article is written, and the release it describes is recorded beside it as the version it was true of.
02
A release ships, and each article describing what it changed is proposed for revision rather than left.
Reason
03
A question arrives that no article answers, and the gap is logged against the corpus, not the customer.
04
An article loses its owner to a reorganisation, and it is marked unowned rather than assumed maintained.
05
A source article is corrected, and each translation still carrying the older wording is flagged as forked.
Decide
06
A product is retired, and the articles still describing it are listed while they go on being found.
07
An article answers through the deflection agent, and any staleness in it is repeated in a confident voice.
Out
08
An article resists an owner, and that absence is reported as the finding rather than left as a blank field.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Detection, drafting and coverage mapping belong to the agent. Publication belongs to a named documentation owner, who republishes the article and owns what it says.
Example workflow
One article, release to republication
AgentHuman
1Change record receivedRelease notes, change logs, ticket themes, search queries or the article corpus itself
2Article set matchedThe articles describing what changed, the owner on record and the day each was last verified
3Revision proposedThe passage overtaken, the suggested wording, the coverage gap and confidence
4Controls appliedOwner checks, freshness checks, duplicate-answer checks and confidence thresholds
No human action required
Stages 1 to 4 run unaided, and nothing reaches the help centre at any of them — the agent is proposing, and the owner lane opens at the confidence gate.
5DecisionSplits at the confidence threshold
High confidence
Goes to the named owner to publish.
Low confidence
Adds a senior writer read first.
Owner review
The revision is held with the release behind it, the passage it replaces and the confidence.
Approve · Amend · Send to writer review
Published — by the named owner▼
6Documentation platform updatedOnly where write access and publication policy allow it
7Outcome evaluatedFreshness after release, coverage gaps closed, owner amendments and what review found
Amendments
Each documentation-owner amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Publishing an article to the help centre.
Retiring an article or taking it off the shelf.
Deciding which of two answers is the correct one.
Approving a translated article for a locale.
Automation boundaryAgent acts unaided
✓Match each release to the articles it overtakes.
✓Record the day an article was last verified against a release.
✓Read the questions customers asked and mark the ones no article answers.
✓Mark an article unowned when the owner named on it has left.
Nothing reaches the help centre except by a named owner, inside the agreed boundaries.
Judging whether a gap is worth an article at all.
Telling a customer that an article is current.
Naming the owner an unowned article passes to.
Changes to the authoring, freshness or owner rules.
Example output
One article revision, annotated
This serves a documentation team asked long afterwards why an article still said what it said; below is one revision exactly as the agent leaves it.
Article revision · single articleIllustrative example
Article
Recorded as
Product
Evidence of record
Confidence
Held for
Resetting a password in the console
Overtaken by the March release
Console, admin tools
Release notes, 4 March 2026
Held unpublished
The named owner, by name
As receivedRead from the release notes and the article history, and it asserts nothing those two do not say.
What the record holdsRelease notesArticle historySearch and ticket log
Why nothing is publishedPublishing a corrected answer is a judgement a named owner makes.
ActionApproveAmendSend to writer review
What the score decidesBelow the configured threshold a revision gets a writer read before the owner sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every articleFrom the release that changed it
03Evidence
Where the evidence is used
The agent does not decide what is correct, only which release touched which article, when it was last verified, and which questions the corpus leaves unanswered.
01Approved path
The answer went stale quietly
Nothing announced it. The article was right the morning it was written, a release shipped in March, and the ranking never moved.
02Human review
What was checked, and not found
Nothing in the corpus records which questions have an answer, only how many articles sit on the shelf, so coverage is read from the questions customers actually asked through to the articles that answered them.
04Build an evidence trail
The article, the release that changed it and the owner who republished stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A product-level freshness figure can read clean while the articles behind one recent release carry most of the amendments. Nestack reports the amendment rate by product area, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Recently released features
7.4%
3.7×
Review
Translated article sets
5.3%
2.6×
Review
Retired product articles
3.3%
1.6×
Watch
Stable core how-to articles
1.9%
0.9×
Normal
Bar: amendment-rate lift vs. stable-core baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a quiet release costs
A loop closes when the article overtaken by a release is a standing case. That suite is what the next revision published is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Amendment rate rises on recently released features.
02Diagnose
The help article that was right on the morning it was written and has been wrong since March is worked backwards until one cause is left standing.
03Improve
Number the change; the articles that drove it are filed beneath it.
04Verify
A single red article case stops the whole release.
05Learn
One case joins the suite, one line joins the authoring rules.
Learn → DetectThe return edge. The next revision is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, revision workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Article-corpus discovery and automation-boundary work.
02Release, ticket and search source review.
03Question-to-article and release-coverage gap mapping.
04Article-corpus ingestion.
05Release binding and article matching.
06Confidence scoring and review routing.
07Owner publication workflow.
08Documentation-platform integration.
09Freshness and coverage cases.
10Guardrails and republication controls.
11Article-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne product area, one cycleProductionProduction documentation workflowAdvancedMultiple products / locales
Introduced at Pilot
Revision proposals to your corpus✓✓✓
Named owner publication✓✓✓
Article-inventory baseline✓✓✓
Introduced at Production
Reporting by article owner—✓✓
Owner review workflow in your systems—✓✓
Approved write-back—✓✓
Documentation-platform integration—✓✓
Introduced at Advanced
Multi-locale article sets——✓
Cross-product coverage packs——✓
Large article corpora——✓
Multi-product freshness controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, corpus size, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live corpus and the owner each article is on→Owner capture and freshness versioningWeek 1
02Representative releases, tickets and search logs→Release binding, matching logic and the freshness baselineWeek 2
03Your release calendar and the owners it names→Freshness rules, owner mapping and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Release, ticket and search source assessment, then integration setupWeek 2
05Articles you would not want cited→Freshness cases and failure-mode testingWeek 4
06What no article may promise→Confidence scoring, review routing, guardrails and release controlsWeek 3
07A named documentation owner who publishes→Release to the named owner, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Two phases share the fifth week because they truly do, and no band was widened to look tidy here.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Corpus discovery, owner mapping and the automation boundaryW2Source integration and the article-inventory baselineW3Revision workflow, matching logic and release controlsW4Evaluation suite, freshness cases and failure-mode testingW5Documentation-platform integration, pilot revisions and targeted correctionsW6One release cycle run under the documentation owner, then Agent Care handover
Reading the bandA bar spans only the weeks its own work is named in, and the fifth week is shared because it is.
At the end of W6When the article record validates, Agent Care picks the agent up.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Support AI agent
Build a knowledge-base agent around the release your last article never noticed.
Show us one product area and the articles that describe it. If nobody in your library owns an article and nobody has verified it against a release, then it is being trusted rather than maintained. A question the corpus cannot answer comes back as a finding.
