Engineering AI agent · Documentation
Software Documentation AI Agent
Date every page against the release it was true of, run the code examples rather than proofread them, and hold each revision for the named owner who publishes it.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named owner
- Release-dated
- After launch
- Agent Care
What this agent does
Drafts and dates the page, never publishes it
In
- 01
A page is published, and the release it was true of is recorded against it.
- 02
A claim is made about a security control, and the evidence that would back it is named beside it.
Reason
- 03
A code example is executed against the release it claims to describe, rather than read for sense.
- 04
A runbook command is run on a schedule, so a command that no longer exists surfaces before it is needed.
- 05
A method is renamed, and each page whose example calls it by the old name is listed for revision.
Decide
- 06
A sunset date is drafted, and the notice period the contract promises is checked against it.
- 07
A regulated instruction set keeps each superseded version published, under Regulation (EU) 2021/2226.
Out
- 08
A page passes its currency term unrevised, and it is marked unverified rather than left standing.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Drafting, dating and flagging belong to the agent. Publication belongs to a named documentation owner, who holds editorial responsibility for the page and answers for it once it is live.
Example workflow
One page, change to publication
- 1Source change receivedMerged pull request, release tag, schema change or scheduled documentation review
- 2Sources assembledThe diff, the release it lands in, the pages that cite it and the evidence each claim rests on
- 3Page drafted and datedThe revision, the release it is dated to, the claims flagged for review and confidence
- 4Controls appliedExample execution, claim-to-evidence checks, notice-date checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing is published at any of them — the agent is drafting, and the owner lane opens at the publication gate.
Goes to the named owner to publish.
Adds a subject-matter read first.
Owner publication
The page is held with its evidence, its flagged claims and what the controls returned.
Publish · Revise · Send to subject-matter review
Published — by the named owner
- 6Documentation and site records updatedOnly where write access and publishing policy allow it
- 7Outcome evaluatedClaim currency, example failures, owner corrections and what readers reported after publication
Corrections
Each owner correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Publishing any page to a customer-facing site.
- Drafting a customer incident notice.
- Asserting that a security control is in place.
- Setting the end-date of a support period.
Automation boundary
Agent acts unaided
- ✓Date each page against the release it describes.
- ✓Execute the code examples a page publishes against that release.
- ✓Name the control that would evidence a claim on a security page.
- ✓Mark a page unverified once its evidence goes stale.
Nothing reaches a published page except by a named owner, inside the agreed boundaries.
- Signing a regulated technical file or a submission.
- Deciding that a deprecation notice has been given.
- Holding editorial responsibility for a published page.
- Changes to publishing rules or currency thresholds.
Example output
One page, annotated
An SOP agent writes the procedures a floor runs on; this one writes what a developer reads and what a regulator later quotes back. Below is one page as the agent leaves it.
Documentation output · single page
Illustrative example- Page
- Authentication reference page
- Recorded as
- Rate limits described, examples executed
- Release
- Dated to release
- Evidence of record
- Release record, 3 August 2026
- Confidence
- Held unpublished
- Held for
- The named owner, by name
As received
Taken from the source tree and the release record — the agent vouches for the date, not the design.
What the record holds
- Source diff
- Executed example
- Release record
Why no publication here
Publishing a page is a representation the named owner makes and owns.
What the score decides
Below the configured threshold a page gets a subject-matter read before the owner sees it.
Action
PublishReviseSend to subject-matter 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
Each page
From the change that moved it
Where the evidence is used
The same sentence is an engineering aid to a developer, a representation to a regulator and a description a buyer can hold you to; what changes with the reader is who can sue.
True when it was written
One public security statement was described by an employee as aspirational; a page can also decay honestly, because a rename seldom triggers a documentation update.
What was checked, and not found
No enforcement action consulted turned on a page nobody wrote. Blackbaud was charged over statements it chose to publish and over one incident notice charged twice, as unfair and as deceptive, and it settled without admitting or denying. The Cyber Resilience Act does not bite until December 2027.
Build an evidence trail
The sentence, the code it describes and the owner who published it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Source and schemas
- GitHub
- GitLab
- Bitbucket
- OpenAPI and protobuf schemas
Documentation platforms
- Read the Docs
- Docusaurus
- Mintlify
- MkDocs
- Sphinx
Knowledge and runbooks
- Confluence
- Notion
- Backstage
- PagerDuty runbooks
- repository wikis
Agent
Software documentation
- Reads the change
- Drafts and dates
- Holds for the owner
Publishing and review
- Netlify
- Vercel
- static sites
- Docs review and translation systems
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six filters between the code and the page
Six filters down one channel, the last the closest. What is published is set out in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a page may stand
- L3
- Leaves the publication to a named owner
- L4 – L5
- Keep the page and the release behind it
- L6
- Marks the page unverified when signals degrade
How Nestack evaluates it
Evaluate the whole publishing chain — not only the page that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the page a developer reads
- E1Final-output evaluationDid the page record the release it was actually drafted against?
- E2Step-level evaluationDid the agent read the right diff, the right schema and the live publishing rules?
- E3Tool evaluationDid it read and write the correct page and the correct section?
- E4Confidence calibrationDo low-confidence pages actually attract more owner corrections?
- E5Slice evaluationHow does performance change across specific page classes?
- E6Business outcomeHow many pages needed a correction before the owner published?
Floor — what a regulator later reads
Failure modes
Where each failure originates in the agent
Seven failure modes, each set at the stage where it first shows.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- QW-03
Stale source read
The schema read is not the one now shipped.
Stage gathers
The diff, the schema, the pages and the release
02 · Reasoning
2 modes
- QW-04
Claim asserted, not evidenced
A sentence appears with no control behind it.
- QW-06
Superseded page read as current
A retired revision is worked as the live one.
Stage proposes
The revision, the flagged claims and the release
03 · Tool / write
2 modes
- QW-02
Thin page passed forward
A page moves on without the subject-matter read.
- QW-05
Revision bound to wrong page
The text is filed against another page.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- QW-01
Published, release unrecorded
The record shows a page but not the release under it.
Stage returns
The page a developer reads and a regulator may quote
05 · Change / Version
1 mode
- QW-07
Silent currency drift
A control lapses while the page keeps the old claim.
Stage tracks
Model, prompt, publishing rules and evidence dates
- Sev-1 · a page published on no evidence
- Sev-2 · a stale claim reaches a reader
- Sev-3 · evidence degrades, page held back
Affected slices
Security pages absorb the corrections
A set-level currency figure can read clean while security and trust pages carry most of the corrections. Nestack reports the correction rate by page class and by release, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Security and trust pages | 11.7% | 3.7× | Review | |
| Runbooks and on-call steps | 8.3% | 2.6× | Review | |
| Deprecation and release notes | 5.2% | 1.6× | Watch | |
| Settled reference pages | 2.6% | 0.8× | Normal |
Bar: correction-rate lift vs. settled-reference baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What the security page still claimed
A cycle shuts when the promise no release still keeps is a regression case. That suite is what the next page published is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Correction rate rises on security and trust pages.
- 02
Diagnose
The security page that was true at the last audit and has been a representation ever since is read back against the controls it names until one cause is left standing.
- 03
Improve
Changes ship numbered, and the pages behind them travel attached.
- 04
Verify
Each touched page case is run again, and one red holds it back.
- 05
Learn
The case is kept, and the publishing rules are amended in that same commit.
Learn → Detect
The return edge. The next page published 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, publishing workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Doc-set discovery and automation-boundary definition.Week 1
- 02Source, schema and platform assessment.Week 1, Week 2
- 03Claim-evidence and documentation-policy rule mapping.Week 1, Week 2
- 04Change and schema ingestion.Week 2
- 05Claim binding and drafting logic.Week 2, Week 3
- 06Confidence scoring and review routing.Week 3
- 07Owner publication workflow.Week 3, Week 4
- 08Documentation-platform integration.Week 5
- 09Currency and claim cases.Week 4, Week 5
- 10Guardrails and publishing controls.Week 4
- 11Page-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 doc set, one release train | ProductionProduction publishing workflow | AdvancedMultiple doc sets / audiences |
|---|---|---|---|
| Introduced at Pilot | |||
| Drafting and dating to your release records | ✓ | ✓ | ✓ |
| Named owner publication | ✓ | ✓ | ✓ |
| Document-inventory baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by page class | — | ✓ | ✓ |
| Subject-matter review workflow in your systems | — | ✓ | ✓ |
| Approved publishing write-back | — | ✓ | ✓ |
| Repository-and-site integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-language doc sets | — | — | ✓ |
| Cross-audience publishing packs | — | — | ✓ |
| Large documentation estates | — | — | ✓ |
| Multi-audience publishing controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, page volume, publishing 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 doc sets and the release each one is dated to
→Page capture and release-date versioning
Week 102Representative pages, schemas and runbooks
→Source binding, claim logic and the currency baseline
Week 203Your publishing calendar and the owners it names
→Claim-evidence mapping, page binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Repository, schema and platform assessment, then integration setup
Week 205Pages you would not want quoted back
→Currency cases and the evaluation round
Week 406What no page may promise
→Confidence scoring, review routing, guardrails and publishing controls
Week 307A named owner who publishes the page
→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
A band here is as wide as the phase costs, so the fifth week shows a pair and not a tidier blank.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Documentation discovery, publishing rules and the automation boundary
W2Repository and platform integration and the document-inventory baseline
W3Claim binding, drafting logic and publishing controls
W4Evaluation suite, currency cases and failure-mode testing
W5Platform integration, pilot pages and targeted corrections
W6One publishing cycle run under the documentation owner, then Agent Care handover
- Reading the band
- Each band covers only the weeks its own work is named for, and the fifth week is shared by design.
- At the end of W6
- Once the page record validates, Agent Care takes the agent on.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Engineering AI agent
Build a documentation agent around the page your last release never revised.
Silence carries no legal risk, and each true sentence you publish carries a standing obligation to remain true. Show us your security page and the release it was written for. The only defensible position left is documentation that is maintained.
- Typical delivery
- 4–6 weeks
- Deployment
- Your doc sets
- Named owner
- Release-dated
- After launch
- Agent Care available
Nestack Agents · Software documentation
AGT-ENG-04 · Agent Care available after launch