Find where a line loses time to changeovers, minor stops and unplanned downtime, name the revalidation each suggestion would trigger, and hold every proposal for the engineer who accepts it.
Run data, changeover logs and cleaning records, ingested from supported historian, MES or plant sources.
02
Tag names and units, normalised, each value carried forward against the run it was read from.
Reason
03
Losses by cause — changeover, minor stops, unplanned downtime, utilisation — separated and sized.
04
Parameter classes, cleaning records and change-control rules, applied as configured for that line.
05
Every suggestion tested against the class of each parameter it would touch, and marked.
Decide
06
Regulated parameters, capped speeds and sanitation documents flagged with what a change triggers.
07
The whole proposal routed to the named engineer, with the signature it would need attached.
Out
08
Run data, suggestions, amendments and acceptances retained for the retention period.
09
Write actions executed only inside the approval boundaries agreed during implementation.
→Product statement
The agent proposes and prices; a named engineer accepts, and the on-site signature a sanitation change needs is never the software's.
Example workflow
One suggestion, run data to signature
AgentHuman
1Run data receivedHistorian tags, changeover logs, cleaning records or MES events
2Losses assembledMinor stops, changeovers, unplanned downtime and utilisation, each with its source
3Suggestion draftedSuggested change and parameters touched
4Controls appliedParameter classification, the revalidation a proposal triggers, held-act checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing reaches a controller at any of them — the agent is modelling, and the engineer's lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to the process engineer to accept.
Low confidence
Adds a processing-authority read first.
Engineering acceptance
The suggestion is held with the parameters it touches and the confidence.
Accept · Amend · Send to food-safety review
Accepted — it enters your change control▼
6Historian and MES updatedOnly where write access and approval policy allow it
7Outcome evaluatedEngineer amendments, parameter-flag outcomes, revalidations triggered and corrections after the run
Amendments
Every engineer amendment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Modifying a sanitation SOP or shortening a cycle.
Changing a critical limit or a critical factor.
Altering a scheduled process on a canned line.
Setting or raising a line speed under inspection.
Automation boundaryAgent acts unaided
✓Model where a line loses time, and quantify the case for it for the named owner.
✓Carry every suggestion with the parameters it would touch.
✓Name the revalidation and the signature a proposal triggers.
✓Assemble the evidence pack, and hold it for the named engineer.
Any write happens inside the boundaries agreed at implementation, and never to a regulated parameter.
Signing the sanitation SOP after a modification.
Deciding that a change needs no revalidation at all.
Reanalysing the food safety plan after a change.
Changes to limits, cycle scope or approval rules.
Example output
One suggestion, annotated
Everything the agent suggests is attached to the run data it was drawn from.
Copilot output · single suggestionIllustrative example
Line
Suggested change
Time recovered
Parameter class
Confidence
What it triggers
Filling line, changeover
Sequence the changeover so the shortest wash follows the run
18 minutes
Efficiency, not a limit
87%
SOP re-signature before any use
As receivedTaken from the historian and the plant's own cleaning records — nothing on this side is written by the agent.
Source records usedHistorian run dataCleaning recordChangeover log
Why it stops hereA cleaning control often sits outside the validation rule; the signature on the modified.
ActionAcceptAmendSend to food-safety review
What the score decidesBelow the configured threshold the suggestion picks up a further read first.
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 runFrom the line's own data
03Modelling
Model from the run data
Draw on the historian, the changeover logs and the cleaning records already kept — federal line-speed caps stand, and an inspector may still lower one.
01Approved path
Suggest it, revalidate it
Routine loss analysis arrives modelled, sourced and sized against the run.
02Human review
Send the engineer to the regulated ones
Anything touching a limit, a cleaning document or a capped line goes to a person; if a run later goes wrong, the trail shows what was suggested and who signed.
04Build an evidence trail
The suggestion, the validated parameters it touches and the engineer who accepted it stay on the line record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Historian and process dataOSIsoft PI · Ignition AVEVA · Canary
MES and productionRockwell · Siemens Opcenter Batch records · OEE systems
Sanitation and qualitySafetyChain · Intelex SSOP records · CIP skid logs
Agent
Line and CIP copilot
Reads the run data Models the loss Holds for the engineer
Documents and recordsDocument capture · e-forms Record archives · retention sets
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the line
The controls sit inside one another. What none of them catches is set out below.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeNarrow the agent to performance reporting when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, parameter-class and line-config changes.Track
L4Run trailRecord the run data, the suggestion, the parameters and the acceptance.Record
L3Engineer acceptanceHold the suggestion for a named engineer; the hold governs release, not whether the change is sound.Gate
L2Parameter guardrailsTest each suggestion against the parameter classes and the held-act list; a failure returns it. A warning on screen is not tested; the class boundary is.Restrict
L1Confidence thresholdsRoute low-confidence suggestions to a food-safety read before the engineer sees them.Require review
Model coreSuggestion drafted — change, parameters touched, what it triggers and confidence
L1 – L2Test whether a suggestion may stand
L3Puts the change in an engineer's hands
L4 – L5Keep the suggestion and the parameters it touches
L6Narrows to performance reporting when signals degrade
How Nestack evaluates it
Evaluate the modelling workflow — not only the suggestion that landed.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the change an engineer reads
Depth of coverage ▼
E1Final-output evaluationDid every suggested change match the run data behind it?
E2Step-level evaluationDid the agent use the right line, parameter class and cleaning record?
E3Tool evaluationDid it read and write the correct line and the correct tag?
E4Confidence calibrationDo low-confidence suggestions actually attract more engineer amendments?
E5Slice evaluationHow does performance change across specific line types?
E6Business outcomeHow many suggestions needed an amendment, or a correction after the run?
Floor — the line the plant answers for
Failure modes
Where each failure originates in the agent
Seven ways a suggestion goes wrong, placed by stage.
Agent lifecycleDirection of processing →
01 · Retrieval1 mode
BP-03
Superseded SOP read
A cycle is read from a sanitation SOP that was later revised.
Stage gathersRun data, changeover logs, cleaning records and limits
02 · Reasoning2 modes
BP-04
Cycle called validated
A cleaning control is described as validated where the rule exempts it.
BP-06
Class boundary crossed
A gain is drawn from a parameter that supports a critical limit.
Stage proposesSuggested change and parameters touched
03 · Tool / write2 modes
BP-02
Suggestion released early
A proposal moves on with its flagged parameters unresolved.
BP-05
Duplicate suggestion
The same loss is raised and costed twice on one line.
Stage writesOnly where write access and approval policy allow it
04 · Output1 mode
BP-01
Speed implied as available
A throughput gain is shown where a federal cap still stands.
Stage returnsThe suggestion an engineer accepts or amends
05 · Change / Version1 mode
BP-07
Silent scope regression
A model or rule change widens which parameters it will touch.
Stage tracksModel, prompt, parameter classes and line config
Sev-1 · a change reached a controllerSev-2 · a limit is touched by a proposalSev-3 · source degrades, suggestion held back
Lines do not start from the same place. A changeover-heavy line carries a higher amendment rate before anything is suggested, so read each slice against its own base rather than against the total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Changeover between allergens
7.3%
3.3×
Review
Cleaning-cycle suggestions
5.3%
2.4×
Review
Lines inside a scheduled process
4.2%
1.9×
Watch
Long runs, single product
2.0%
0.9×
Normal
Bar: engineer-amendment-rate lift vs. long-run baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A cycle ends in a case, not a meeting
The cycle ends when a case exists in the suite, not when the miss was discussed. That suite is what the next change suggested to a line is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Engineer-amendment rate rises in a line slice.
02Diagnose
Within the same campaign, the runs and the suggestions drawn off them are read until the cause narrows to one.
03Improve
Changes carry a version and the runs that prompted them.
04Verify
Release is held until the affected cases pass.
05Learn
The case is kept permanently, and the sanitation notes move with it.
Learn → DetectThe return edge. The next suggestion meets 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, modelling workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Line and cleaning workflow discovery with your engineering team.
02Historian, MES and CIP source assessment.
03Parameter classification and change-control mapping.
04Run-data ingestion and normalisation.
05Loss modelling and parameter binding.
06Confidence scoring and safety routing.
07Engineering acceptance workflow.
08Historian and MES integration.
09Parameter-boundary cases.
10Guardrails and change controls.
11Run-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 line, one productProductionProduction plant systemsAdvancedMultiple plants / lines
Introduced at Pilot
Modelling to your run data and records✓✓✓
Engineering acceptance✓✓✓
Suggestion-quality baseline✓✓✓
Introduced at Production
Reporting by line and product—✓✓
Acceptance workflow in your systems—✓✓
Approved write-back—✓✓
Historian and MES integration—✓✓
Introduced at Advanced
Multi-regime change rules——✓
Multi-stage engineering approvals——✓
High line count——✓
Multi-plant line controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, line count, 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 run data and the tags each line carries→Run-data ingestion and tag mappingWeek 1
02Representative campaigns and changeovers→Loss-modelling baseline, tag extraction and parameter bindingWeek 2
03Your cleaning records and parameter classes→Parameter classification and change-control mappingWeek 1
04Access to relevant APIs, feeds or exports→Historian, MES and CIP assessment, then integration setupWeek 2
05Changes you would not want run→Boundary cases and failure-mode testingWeek 4
06What no suggestion may change without revalidation→Confidence scoring, safety routing, guardrails and change controlsWeek 3
07Named engineers to accept suggestions→Acceptance workflow, 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
The bands follow the actual work, which is why the fifth week doubles rather than pads.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Line workflow discovery, parameter classing and the automation boundaryW2Source integration and the loss-modelling baselineW3Modelling workflow, confidence logic and acceptance controlsW4Evaluation suite, parameter guardrails and failure-mode testingW5Historian and MES integration, pilot lines and targeted correctionsW6One production campaign supported under engineering, then handover
Reading the bandA bar covers the weeks its work is actually named in; the fifth carries two because they overlap.
At the end of W6The campaign closes validation and Agent Care owns the running agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Food & Beverage AI agent
Build a line and CIP copilot around your own change control.
Show us one line, its run data and its cleaning records. Get this wrong and the cost is not a slower line — it is a sanitation document signed without the revalidation it carried, and a speed that was never yours to move; worker-safety exposure sits with OSHA either way.
