Read, explain and document standard control logic offline, draft rungs and blocks against your programming standard, and prepare a change package — safety logic excluded, nothing downloaded.
Read an offline export of the program — routines, tags, cross-references and comments — from version control.
02
Take the site programming standard, the approved block library and the version history as context.
Reason
03
Explain what a routine does, in order, and trace where each tag is read and where it is written.
04
Draft standard rungs, blocks or structured text against the site standard and the library in use.
05
Compare two program revisions and describe what changed, rung by rung, against the change request.
Decide
06
Stop at anything touching a safety function, an interlock or a permissive, and raise it as a question.
07
Mark low-confidence work and anything drafted against a program copy that is not the current revision.
Out
08
Assemble a change package — draft, diff, affected tags, test notes and open questions — for review.
09
Hand it to a controls engineer. Nothing is downloaded, and the agent never goes online with a machine.
→Product statement
The agent reads and drafts in an offline engineering environment. A qualified controls engineer reviews and tests every change, and the site's change process decides what runs.
Example workflow
One change request, end to end
AgentHuman
1Change request receivedFrom the change-management system, a maintenance ticket or an engineer's question
2Program copy pulledThe offline export held in version control, with its revision and date checked against the controller record
3Logic read and explainedRoutine behaviour in scan order, tag cross-references, prior revisions and the site programming standard
4Draft preparedRungs, blocks or structured text, with the tags touched and the assumptions written down beside them
No human action required
Stages 1 to 4 run without a person in the loop — reading, tracing and drafting all happen on an offline copy. A safety-adjacent touch ends that stretch on the spot.
5DecisionSplits on confidence and on whether the change is safety-adjacent
Standard logic, high confidence
Reaches the engineer as a draft to review and test.
Safety-adjacent or low confidence
Stops with a question and drafts nothing further.
Controls engineer
Reads the draft against the live program, tests it offline, then commissions it under the site's change process.
Accept draft · Correct · Send back
Reviewed — handed back▼
6Change package filedDraft, diff, affected tags, simulator result and open questions — written to the engineering copy only
7Outcome evaluatedEngineer corrections, simulator and commissioning results, and what the change did on the machine
Corrections
What the engineer rewrites is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Downloading or applying code to a controller.
Going online with a running machine.
Any change to a safety function.
Editing an interlock, permissive or e-stop path.
Automation boundaryAgent acts unaided
✓Read and explain standard routines from an offline program copy.
✓Trace where a tag is read, written and cross-referenced.
✓Draft standard logic against the site standard and the block library.
✓Assemble the change package and raise safety-adjacent touches to a person.
The agent writes only into the engineering environment. It has no path to a controller, and no scope over safety logic.
Forcing, bypassing or defeating a device.
Changing setpoints, recipes or machine parameters.
Approving a change package for commissioning.
Signing the change record after test.
Example output
One change request, annotated
Everything the agent drafts is attached to the request and the exact program revision it was read from.
Draft output · single change requestIllustrative example
Change request
Program copy
Routine
Drafted
Confidence
Downloaded
Add a dwell before the reject gate opens
Offline export, rev 41
Uncommented ladder
Two rungs, standard timer block
88%
No — never by the agent
As receivedThe request as written, and the exact revision it was drafted against — a stale copy is marked stale.
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and your controller
Each control wraps the one inside it. A draft clears every layer before an engineer reads it, and the download sits outside all six.
L6 · Outermost — last line of defenceInward → L1 · closest to the model
L6Rollback / safe modeNarrow the agent to reading and documentation if evaluation signals degrade.Roll back
L5TraceabilityRecord the revision read, sources, draft, simulator result and every correction.Record
L4Engineer gateA qualified controls engineer reviews and tests before anything is commissioned.Gate
L3Standard conformanceDrafts are held to the site programming standard and the approved block library.Constrain
L2Safety exclusionA safety function, interlock or permissive stops the draft and raises a question.Stop
L1Offline scopeThe agent reads and writes an engineering copy and holds no controller connection.Isolate
Model coreDraft produced — explanation, rungs or blocks, affected tags and confidence
L1 – L2Keep the agent off machines and off safety
L3Decides whether a draft fits your standard
L4 – L5Keep commissioning with a person, trail intact
L6Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate the reading and the draft — not only the rung at the end.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the draft the controls engineer opens
Depth of coverage ▼
E1Final-output evaluationWas the drafted logic correct for the machine and the states it runs in?
E2Step-level evaluationDid it read the right routine, the right revision and the site standard?
E3Cross-reference accuracyWas every read and every write of the affected tags found?
E4Safety-adjacency recallWas every interlock or safety-adjacent touch stopped and raised to a person?
E5Slice evaluationHow does draft quality change across platforms and code styles?
E6Business outcomeHow much was corrected in review, and what failed in the simulator?
Floor — the change a person commissions on the machine
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle. None of them reaches a machine by itself — the engineer's review, the offline test and the site's change process are the controls that stop them. If one gets through anyway, the engineer stops the line and puts the previous revision back, and the change record shows what ran and who approved it.
Agent lifecycleDirection of processing →
01 · Retrieval2 modes
PL-01
Stale program copy
Drafted against an export the controller has moved past.
PL-02
Cross-reference miss
A second place the tag is written is not found.
Stage readsThe program copy, the tags, the standard and the history
02 · Reasoning2 modes
PL-03
Wrong for the machine state
Valid rungs that misbehave at power-up, restart or changeover.
PL-04
Scan-order assumption
A race that only shows on the real controller.
Stage draftsThe explanation, the rungs and the assumptions made
03 · Package / file1 mode
PL-05
Interlock touched quietly
A change that looks standard but sits on a permissive.
Stage filesThe draft and the diff, written to the engineering copy
04 · Output1 mode
PL-06
Documentation drifts
Comments describe intent, not what the code does.
Stage returnsThe explanation and the draft the engineer reads
05 · Change / Version1 mode
PL-07
Silent standard regression
A library or standard update changes drafts unnoticed.
Stage tracksModel, prompt, site-standard and block-library changes
Sev-1 · machinery could move wronglySev-2 · the draft rests on a stale programSev-3 · documentation degrades, rework rises
Draft quality tracks the program it was drafted from
Two programs on the same site are not the same problem. A routine written to the current standard drafts cleanly; a twenty-year-old ladder program with no comments does not. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Legacy undocumented ladder
6.0%
3.5×
Review
Vendor-specific dialects
4.6%
2.7×
Review
Rebuilt or modified machines
3.2%
1.9×
Watch
Documented standard-library code
1.2%
0.7×
Normal
Bar: correction-rate lift vs. standard-library baseline · scale 0–4.0× · tick marks 2.0×2 of 4 slices over threshold
Evidence-linked improvement
A missed rung becomes a test the next draft must pass
Corrections found in review, in the simulator or at commissioning come back as regression cases against the same routine and the same platform.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Corrections, simulator failures and post-change line stops cluster on one platform.
02Diagnose
Traced to the program copy, a missed cross-reference, the site standard, or a state the routine can be in.
03Improve
The retrieval rule, the drafting constraint or the block-library entry is changed and version-linked.
04Verify
Re-run against held-out routines from that platform, in the simulator, including the ones that failed.
05Learn
That routine joins the regression set and the reason it failed enters the review checklist.
Learn → DetectThe return edge. A commissioning failure is written up and re-tested before the next change package is drafted, not after.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, program access, reading and drafting, evaluation, simulation, then review workflow and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Workflow discovery and boundary definition.
02Engineering-workstation and export assessment.
03Site programming standard and block library.
04Version-control and revision-freshness checks.
05Program parsing and cross-reference index.
06Routine explanation and documentation.
07Drafting against the site standard.
08Safety-adjacency detection and stop rules.
09Evaluation suite and held-out routines.
10Offline simulator or twin test harness.
11Change-package and change-system workflow.
12Observability, deployment 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 platform, one lineProductionProduction engineering stackAdvancedMulti-site / multi-platform
Introduced at Pilot
Routine explanation and documentation✓✓✓
Tag and cross-reference tracing✓✓✓
Offline, read-only program access✓✓✓
Safety-adjacency stop rules✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Drafting to your programming standard—✓✓
Version-control and revision checks—✓✓
Change-package assembly for review—✓✓
Observability and evaluation—✓✓
Introduced at Advanced
Simulator or digital-twin harness——✓
Multi-platform and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on platforms in scope, program size and condition, version-control and simulator access, review workflow 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 programming standard and approved block library→Site programming standard and block libraryWeek 1
02Offline exports of the programs in scope→Engineering-workstation and export assessmentWeek 2
03Version-control access and how a revision is frozen→Version-control and revision-freshness checksWeek 2
04Where your safety logic sits and what counts as safety-adjacent→Safety-adjacency detection and stop rulesWeek 4
05Changes that went wrong before, including the near misses→Evaluation suite, regression cases and failure-mode testingWeek 4
06A simulator, emulator or twin we can test drafts against→Offline simulator or twin test harnessWeek 5
07Named controls engineers to review drafts→Change-package workflow, then pilot changes under your change processWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. Week 5 carries both the simulator harness and the first change packages your engineers read.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Workflow discovery, boundary definition and your programming standardW2Offline exports, version-control access and the cross-reference indexW3Routine explanation, documentation and drafting to your standardW4Evaluation suite, held-out routines and safety-adjacency testingW5Simulator harness, first change packages and targeted correctionsW6Your engineers review, test and commission under your change process
Reading the bandSafety-adjacency stop rules are tested in week 4, before any draft is packaged for review in week 5.
At the end of W6Drafts have been reviewed, tested and commissioned by your own engineers under your change process, then Agent Care takes over monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Manufacturing AI agent
Build a PLC copilot around your controls workflow.
Show us one machine's program, your programming standard and how a change reaches a controller today. We'll explain one of your own routines, draft one standard change against your standard, and mark where your safety boundary sits.
