Manufacturing AI agent · Controls engineering
PLC & Automation-Code Copilot AI Agent
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.
- Typical delivery
- 4–6 weeks
- Environment
- Offline only
- Safety logic
- Out of scope
- After launch
- Agent Care
What this agent does
Reads and drafts offline, never downloads
In
- 01
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
- 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.
Reaches the engineer as a draft to review and test.
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 required
8 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 boundary
Agent 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 request
Illustrative example- Change request
- Add a dwell before the reject gate opens
- Program copy
- Offline export, rev 41
- Routine
- Uncommented ladder
- Drafted
- Two rungs, standard timer block
- Confidence
- 88%
- Downloaded
- No — never by the agent
As received
The request as written, and the exact revision it was drafted against — a stale copy is marked stale.
Evidence used
- Rev-41 cross-reference
- Site standard, timer rules
- Two prior reject routines
Why this draft
The timer block and the tag naming come from the site standard, not the model.
What the score decides
Confidence decides how hard the engineer looks, not whether a draft may run.
Action
Accept draftCorrectSend backValue
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 change request
Change system, ticket or an engineer's question
Work to the site's own standard
Use the plant's programming standard, block library, tag conventions and the revision history already in version control.
Shorten the read-in on an unfamiliar program
An engineer starts from an explained routine and a tag cross-reference instead of reading a legacy program cold.
Put the review where the risk is
Safety-adjacent touches and low-confidence drafts are marked before review, so the engineer's time goes to the rungs that can move machinery.
Build an evidence trail
Retain the request, the revision read, the sources used, the draft, the simulator result and the engineer's correction — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent, and read-only or offline access is the point. Which of them are in scope is decided in discovery.
Engineering workstation
- Studio 5000
- TIA Portal
- CODESYS
- Unity Pro
- project exports
Version control
- Git
- Copia
- MDT AutoSave
- Octoplant
- revision history
Simulation & test
- Emulate 3D
- PLCSIM
- CODESYS simulation
- Test benches
- digital twins
Agent
PLC & automation-code copilot
- Reads offline copies
- Drafts standard logic
- Stops at safety
Change management
- SAP PM
- Maximo
- eMaint
- Change requests
- approval records
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
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 defence
Inward → L1 · closest to the model
- L1 – L2
- Keep the agent off machines and off safety
- L3
- Decides whether a draft fits your standard
- L4 – L5
- Keep commissioning with a person, trail intact
- L6
- Pulls 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
- 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 lifecycle
Direction of processing →
01 · Retrieval
2 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 reads
The program copy, the tags, the standard and the history
02 · Reasoning
2 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 drafts
The explanation, the rungs and the assumptions made
03 · Package / file
1 mode
- PL-05
Interlock touched quietly
A change that looks standard but sits on a permissive.
Stage files
The draft and the diff, written to the engineering copy
04 · Output
1 mode
- PL-06
Documentation drifts
Comments describe intent, not what the code does.
Stage returns
The explanation and the draft the engineer reads
05 · Change / Version
1 mode
- PL-07
Silent standard regression
A library or standard update changes drafts unnoticed.
Stage tracks
Model, prompt, site-standard and block-library changes
- Sev-1 · machinery could move wrongly
- Sev-2 · the draft rests on a stale program
- Sev-3 · documentation degrades, rework rises
Affected slices
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 aggregate
Illustrative 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 stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Corrections, simulator failures and post-change line stops cluster on one platform.
- 02
Diagnose
Traced to the program copy, a missed cross-reference, the site standard, or a state the routine can be in.
- 03
Improve
The retrieval rule, the drafting constraint or the block-library entry is changed and version-linked.
- 04
Verify
Re-run against held-out routines from that platform, in the simulator, including the ones that failed.
- 05
Learn
That routine joins the regression set and the reason it failed enters the review checklist.
Learn → Detect
The 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.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Workflow discovery and boundary definition.Week 1
- 02Engineering-workstation and export assessment.Week 1, Week 2
- 03Site programming standard and block library.Week 1, Week 2
- 04Version-control and revision-freshness checks.Week 2
- 05Program parsing and cross-reference index.Week 2, Week 3
- 06Routine explanation and documentation.Week 3
- 07Drafting against the site standard.Week 3, Week 4
- 08Safety-adjacency detection and stop rules.Week 4
- 09Evaluation suite and held-out routines.Week 4, Week 5
- 10Offline simulator or twin test harness.Week 5
- 11Change-package and change-system workflow.Week 5, Week 6
- 12Observability, deployment 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 platform, one line | ProductionProduction engineering stack | AdvancedMulti-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 price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on platforms in scope, program size and condition, version-control and simulator access, review workflow 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 programming standard and approved block library
→Site programming standard and block library
Week 102Offline exports of the programs in scope
→Engineering-workstation and export assessment
Week 203Version-control access and how a revision is frozen
→Version-control and revision-freshness checks
Week 204Where your safety logic sits and what counts as safety-adjacent
→Safety-adjacency detection and stop rules
Week 405Changes that went wrong before, including the near misses
→Evaluation suite, regression cases and failure-mode testing
Week 406A simulator, emulator or twin we can test drafts against
→Offline simulator or twin test harness
Week 507Named controls engineers to review drafts
→Change-package workflow, then pilot changes under your change process
Weeks 5–6
Nothing else is required
Deployment, 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.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Workflow discovery, boundary definition and your programming standard
W2Offline exports, version-control access and the cross-reference index
W3Routine explanation, documentation and drafting to your standard
W4Evaluation suite, held-out routines and safety-adjacency testing
W5Simulator harness, first change packages and targeted corrections
W6Your engineers review, test and commission under your change process
- Reading the band
- Safety-adjacency stop rules are tested in week 4, before any draft is packaged for review in week 5.
- At the end of W6
- Drafts have been reviewed, tested and commissioned by your own engineers under your change process, then Agent Care takes over monitoring.
- Duration
- Six-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.
- Typical delivery
- 4–6 weeks
- Environment
- Offline engineering copy
- Safety logic
- Out of scope, always
- After launch
- Agent Care available
Nestack Agents · PLC & automation-code copilot
AGT-MFG-07 · Agent Care available after launch