Operations AI agent · SOP documentation
SOP & Process Documentation AI Agent
Separate approval from effectivity, show what changed between two revisions in the steps, not the formatting, and mark who is still on the one before — approval stays with a named process owner.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Owner approval
- Effectivity
- After launch
- Agent Care
What this agent does
Drafts and versions, never approves
In
- 01
A procedure is written from the way the work is actually run, and each step keeps the source it came from.
- 02
A revision is drafted, and what moved in the steps is shown apart from what moved in the formatting.
Reason
- 03
A step changes, and the older wording and the newer one are held side by side rather than overwritten.
- 04
A revision is approved, and the day it takes effect is carried as its own date, not the day of approval.
- 05
A procedure reaches one site before another, and each site is marked with the revision it is running.
Decide
- 06
A person is trained, and the acknowledgement is tied to the revision number that person was shown.
- 07
A superseded copy is still on a wall or in a drawer, and it is listed for withdrawal by place.
Out
- 08
A procedure describes a system that has since been replaced, and that is raised as a finding.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Drafting, diffing, versioning and chasing belong to the agent. Approval belongs to a named process owner, who decides that a step is safe and correct.
Example workflow
One procedure, draft to effective
- 1Change request receivedA process owner request, a review finding, a line change or a procedure falling due
- 2Current text assembledThe revision now in force, the steps as they are run, the records the procedure touches and the sites it covers
- 3Revision draftedThe redrafted steps, the diff against the live revision, the training impact and confidence
- 4Controls appliedStep-level diff checks, numbering and format rules, training-impact checks and drafting confidence
No human action required
Stages 1 to 4 run unaided, and nothing takes effect at any of them — the agent is drafting, and the owner lane opens at the approval gate.
Goes to the named process owner to approve.
Adds a subject-matter read first.
Owner approval
The revision is held with its diff, its training impact and the sites it would reach.
Approve · Amend · Send to subject-matter review
Approved — by the named process owner
- 6Document and training records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedEffective dates met, acknowledgements returned, owner amendments and what review found
Amendments
Each 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
- Approving a procedure for use.
- Setting the day a revision takes effect.
- Deciding that a step is safe and correct.
- Signing off training for a role.
Automation boundary
Agent acts unaided
- ✓Draft the procedure from how the work is run.
- ✓Flag a revision approved but never made effective.
- ✓Show what changed in the steps, not in the numbering or layout.
- ✓Track which revision each site is running, and who acknowledged it.
Nothing takes effect except by a named process owner, inside the agreed boundaries.
- Judging whether a procedure is still fit.
- Telling a reviewer a procedure was followed.
- Retiring a procedure that is still in use.
- Changes to numbering, approval or training rules.
Example output
One revision, annotated
This serves an operations team who may be asked years later which revision a person was working to; below is one revision exactly as the agent leaves it.
Procedure output · single revision
Illustrative example- Procedure
- Line changeover, packing station
- Recorded as
- Two steps changed, wording only elsewhere
- Revision
- Revision five, drafted
- Effective from
- Not yet set
- Confidence
- Held unapproved
- Held for
- The named process owner
As received
Built from the revision in force and the way the step is run today, and it asserts nothing past them.
What the record holds
- Revision in force
- Step-level diff
- Training list
Why no approval here
Deciding a step is safe is a judgement the process owner makes.
What the score decides
Below the threshold a revision picks up a subject-matter read before the owner sees it.
Action
ApproveAmendSend 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
Every procedure
From the store it is kept in
Where the source is used
The agent does not vouch for a step, only for what the revision in force says, what a draft would change and who has acknowledged which version.
A procedure people actually run
The sheet at the bench, the intranet page and the file in the shared drive can each be called current and still disagree, with nobody having lied.
What was checked, and not found
No statute governs the standard operating procedures of an ordinary company, and none was found for this one, so what binds here is the authoring and approval rules the company wrote for itself and applies.
Build an evidence trail
The procedure, the version people were trained on and the author who issued it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Document management
- SharePoint
- Confluence
- Controlled document libraries
Training records
- LMS
- training registers
- Acknowledgements by revision
Delivery to the floor
- Line tablets
- intranet
- Printed and posted copies
Agent
SOP drafting and versioning
- Reads the live revision
- Drafts the change
- Holds for the owner
Change and review records
- Change requests
- findings
- Improvement and review actions
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six sieves between the model and the floor
Six sieves in a line, the last the finest. What comes through 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 approval to a named process owner
- L4 – L5
- Keep the procedure and the training behind it
- L6
- Serves the last approved version when signals degrade
How Nestack evaluates it
Evaluate the whole drafting cycle — not only the procedure that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the procedure read at the bench
- E1Final-output evaluationDid the draft describe the step the way it is actually run?
- E2Step-level evaluationDid the agent read the revision in force, the right site and the current rules?
- E3Tool evaluationDid it read and write the correct procedure and the correct revision?
- E4Confidence calibrationDo low-confidence drafts actually attract more owner amendments?
- E5Slice evaluationHow does performance change across specific procedure groups?
- E6Business outcomeHow many drafts needed an amendment before the owner approved?
Floor — the step somebody performs
Failure modes
Where each failure originates in the agent
Seven failure modes, each placed at the stage it first shows up.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- MO-03
Superseded copy read
The copy read is not the revision now in force.
Stage gathers
The revision, the steps, the sites and the roles
02 · Reasoning
2 modes
- MO-04
Step written for a dead system
The procedure names a system since replaced.
- MO-06
Ambiguous step wording
One step reads three ways away from its author.
Stage proposes
The diff, the training impact and the confidence
03 · Tool / write
2 modes
- MO-02
Step change passed forward
A changed step moves on without the subject read.
- MO-05
Draft filed to wrong procedure
The revision is attached to another procedure.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- MO-01
Approved, never made effective
The revision is approved and never reaches the floor.
Stage returns
The procedure a person works to at the bench
05 · Change / Version
1 mode
- MO-07
Translation drift
A translated copy drifts from the source revision.
Stage tracks
Model, prompt, authoring rules and effective dates
- Sev-1 · a step changes with no approval
- Sev-2 · a superseded copy stays in use
- Sev-3 · source degrades, draft held back
Affected slices
One site can be a revision behind
A site-level effectivity figure can read clean while most of the superseded copies sit in a few kinds of procedure. Nestack reports the stale-revision rate by procedure group, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Multi-site procedures | 8.5% | 3.7× | Review | |
| Recently replaced systems | 6.1% | 2.7× | Review | |
| Translated procedures | 3.8% | 1.7× | Watch | |
| Stable back-office procedures | 2.0% | 0.9× | Normal |
Bar: stale-revision-rate lift vs. back-office baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What a superseded sheet costs
A cycle ends when the procedure trained on a dead version is a standing case. That suite is what the next issue published is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Stale-revision rate rises across multi-site procedures.
- 02
Diagnose
The laminated sheet at the bench that was superseded two revisions ago is worked backwards until one cause is left standing.
- 03
Improve
Every change ships numbered, and the procedures behind it ride along.
- 04
Verify
One procedure case still failing is enough to hold the release back.
- 05
Learn
It is kept for good, and the authoring rules are amended in the same commit.
Learn → Detect
The return edge. The next issue 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, drafting workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Procedure-inventory and automation-boundary work.Week 1
- 02Document and training-record sources.Week 1, Week 2
- 03Procedure-to-owner and training-record mapping.Week 1, Week 2
- 04Procedure and revision ingestion.Week 2
- 05Diff, effectivity and training binding.Week 2, Week 3
- 06Confidence scoring and review routing.Week 3
- 07Owner approval workflow.Week 3, Week 4
- 08Document-system integration.Week 5
- 09Procedure and effectivity cases.Week 4, Week 5
- 10Guardrails and approval controls.Week 4
- 11Procedure-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 site, one procedure set | ProductionProduction document workflow | AdvancedMultiple sites / languages |
|---|---|---|---|
| Introduced at Pilot | |||
| Drafting to your procedure format | ✓ | ✓ | ✓ |
| Named owner approval | ✓ | ✓ | ✓ |
| Procedure-inventory baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by procedure owner | — | ✓ | ✓ |
| Owner review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Document-management integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-language procedure sets | — | — | ✓ |
| Multi-stage approval chains | — | — | ✓ |
| Large procedure libraries | — | — | ✓ |
| Multi-site effectivity controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, procedure volume, 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 procedures and the owner each one answers to
→Procedure capture and revision versioning
Week 102Representative procedures and their training records
→Source binding, diff logic and the drafting baseline
Week 203Your approval route and the roles it names
→Procedure mapping, owner binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Document and training-system assessment, then integration setup
Week 205Procedures you would not want audited
→Effectivity cases and failure-mode testing
Week 406What no procedure record may establish
→Confidence scoring, review routing, guardrails and approval controls
Week 307A named process owner who approves the revision
→Release to the process 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
The bands below are measured, not spaced for looks; week five carries two phases because it does.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Procedure discovery, owner mapping and the automation boundary
W2Document and training integration and the procedure baseline
W3Drafting, diff logic and effectivity controls
W4Evaluation suite, effectivity cases and failure-mode testing
W5Document-system integration, pilot procedures and targeted corrections
W6One revision cycle run under the process owner, then Agent Care handover
- Reading the band
- A band sits on the weeks its own work is named for and nowhere else; week five genuinely carries two.
- At the end of W6
- When the procedure 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 · Operations AI agent
Build an SOP agent around the revision your floor is actually running.
Show us one procedure that lives in more than one place and the day each copy was last revised. If the sheet at the bench is not what the document store calls current, then the floor is running a revision nobody approved. No statute governs this; the rules you wrote do.
- Typical delivery
- 4–6 weeks
- Deployment
- Your live procedures
- Owner approval
- Effectivity
- After launch
- Agent Care available
Nestack Agents · SOP documentation
AGT-OP-01 · Agent Care available after launch