Support AI agent · Knowledge base
Knowledge-Base Maintenance AI Agent
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.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named owner
- Freshness first
- After launch
- Agent Care
What this agent does
Proposes the revision, never publishes it
In
- 01
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
- 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.
Goes to the named owner to publish.
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 required
8 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 boundary
Agent 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 article
Illustrative example- Article
- Resetting a password in the console
- Recorded as
- Overtaken by the March release
- Product
- Console, admin tools
- Evidence of record
- Release notes, 4 March 2026
- Confidence
- Held unpublished
- Held for
- The named owner, by name
As received
Read from the release notes and the article history, and it asserts nothing those two do not say.
What the record holds
- Release notes
- Article history
- Search and ticket log
Why nothing is published
Publishing a corrected answer is a judgement a named owner makes.
What the score decides
Below the configured threshold a revision gets a writer read before the owner sees it.
Action
ApproveAmendSend to writer reviewValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every article
From the release that changed it
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.
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.
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.
Build 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.
Documentation platforms
- Zendesk Guide
- Salesforce Knowledge
- Confluence
- Document360
Release and change records
- Release notes
- changelogs
- Issue trackers and version tags
Support ticket history
- Ticket themes
- reply macros
- Questions customers have actually asked
Agent
Knowledge-base maintenance
- Reads the releases
- Proposes revisions
- Holds for the owner
Search and deflection logs
- Site search
- help-centre search
- Deflection and self-serve outcomes
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six sifters between the model and the help centre
Six sifters in one column, the last the finest. What is kept back is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a revision may stand
- L3
- Leaves the publishing to a named owner
- L4 – L5
- Keep the article and the release behind it
- L6
- Marks the article unverified when signals degrade
How Nestack evaluates it
Evaluate the whole maintenance loop — not only the revision that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the answer a customer reads
- E1Final-output evaluationDid the revision cite the release that actually overtook the article?
- E2Step-level evaluationDid the agent read the right article, the right release and the live owner record?
- E3Tool evaluationDid it read and write the correct article and the correct locale?
- E4Confidence calibrationDo low-confidence revisions actually attract more owner amendments?
- E5Slice evaluationHow does performance change across specific product areas?
- E6Business outcomeHow many revisions needed an amendment before the owner published?
Floor — the corpus an answer rests on
Failure modes
Where each failure originates in the agent
Seven failure modes, set down at the stage where each first shows itself.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- PH-03
Superseded article read
The version read is not the one on the shelf now.
Stage gathers
The articles, the releases, the owners and the questions
02 · Reasoning
2 modes
- PH-04
Revision asserted, not sourced
A wording change arrives with no release behind it.
- PH-06
Retired article read as live
A withdrawn product page is worked as current.
Stage proposes
The release, the passage, the gap and confidence
03 · Tool / write
2 modes
- PH-02
Thin revision passed forward
A revision moves on without the writer read.
- PH-05
Revision bound to wrong article
The change is filed against another article.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- PH-01
Published, release unrecorded
The record shows a revision but not the release under it.
Stage returns
The article a customer reads and an agent quotes
05 · Change / Version
1 mode
- PH-07
Silent coverage drift
The questions widen while the corpus keeps its old shape.
Stage tracks
Model, prompt, freshness rules and owner records
- Sev-1 · a revision goes out unreviewed
- Sev-2 · a stale article answers a customer
- Sev-3 · source degrades, revision held back
Affected slices
Recent releases carry the amendments
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 aggregate
Illustrative 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 threshold
2 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 stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Amendment rate rises on recently released features.
- 02
Diagnose
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.
- 03
Improve
Number the change; the articles that drove it are filed beneath it.
- 04
Verify
A single red article case stops the whole release.
- 05
Learn
One case joins the suite, one line joins the authoring rules.
Learn → Detect
The 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.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Article-corpus discovery and automation-boundary work.Week 1
- 02Release, ticket and search source review.Week 1, Week 2
- 03Question-to-article and release-coverage gap mapping.Week 1, Week 2
- 04Article-corpus ingestion.Week 2
- 05Release binding and article matching.Week 2, Week 3
- 06Confidence scoring and review routing.Week 3
- 07Owner publication workflow.Week 3, Week 4
- 08Documentation-platform integration.Week 5
- 09Freshness and coverage cases.Week 4, Week 5
- 10Guardrails and republication controls.Week 4
- 11Article-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final 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 tier | PilotOne product area, one cycle | ProductionProduction documentation workflow | AdvancedMultiple 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 price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, corpus size, approval controls and deployment requirements.
- Separate from build
- Build 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 bring
We build with it
01Your live corpus and the owner each article is on
→Owner capture and freshness versioning
Week 102Representative releases, tickets and search logs
→Release binding, matching logic and the freshness baseline
Week 203Your release calendar and the owners it names
→Freshness rules, owner mapping and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Release, ticket and search source assessment, then integration setup
Week 205Articles you would not want cited
→Freshness cases and failure-mode testing
Week 406What no article may promise
→Confidence scoring, review routing, guardrails and release controls
Week 307A named documentation owner who publishes
→Release to the named owner, then pilot and production validation
Weeks 5–6
Nothing else is required
Deployment, 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.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Corpus discovery, owner mapping and the automation boundary
W2Source integration and the article-inventory baseline
W3Revision workflow, matching logic and release controls
W4Evaluation suite, freshness cases and failure-mode testing
W5Documentation-platform integration, pilot revisions and targeted corrections
W6One release cycle run under the documentation owner, then Agent Care handover
- Reading the band
- A bar spans only the weeks its own work is named in, and the fifth week is shared because it is.
- At the end of W6
- When the article record validates, Agent Care picks the agent up.
- Duration
- Six-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.
- Typical delivery
- 4–6 weeks
- Deployment
- Your live corpus
- Named owner
- Freshness first
- After launch
- Agent Care available
Nestack Agents · Knowledge-base maintenance
AGT-SUP-06 · Agent Care available after launch