Inflect Systems/Manufacturing
Give every machine a voice.
I turn plant-floor signals into answers people can use: PLC monitoring, downtime context, shift handoffs, maintenance trails, and a scoped model that reads the line without taking control of it. Start read-only. Learn the real failure modes. Then connect the work back to SAP, MES, CMMS, and the people responsible for the shift.
The floor already knows. The system usually doesn't.
Machines trip, crews recover, supervisors chase the story, and the business system gets a thin summary hours later. I close that gap without asking you to rip out the line.
Watch before you write
Read PLC tags, alarms, historians, exports, and old-machine outputs first. Around live equipment, monitoring is not the same thing as control.
Turn events into context
A fault code is not a root cause. Agents connect alarms, trends, manuals, work orders, line notes, and prior fixes into a ranked trail.
Put the answer where work happens
Shift handoffs, downtime logs, maintenance tasks, production feedback, and reports can land in the system people already use.
Where it starts paying back
This is not a generic chatbot over a plant wiki. It is machine intelligence tied to the messy work of keeping a line moving.
Line downtime visibility
Track not just that the line stopped, but what changed around the stop: alarm sequence, upstream state, operator note, maintenance action, and return-to-run.
OEE without another spreadsheet
Connect availability, rate, quality signals, production counts, and crew notes so OEE is a living view instead of a manual end-of-shift ritual.
Old-machine retrofits
When the OEM is gone or the source is missing, start with the signals you can safely read: IO, serial, exports, sensors, counters, and operator workflow.
Maintenance diagnosis
Ask why a fault tripped and get a ranked trail across manuals, drawings, PLC snapshots, prior work orders, spare parts, and symptom history.
Shift handoffs that carry evidence
Turn the outgoing crew's knowledge into structured context: what changed, what was bypassed, what is still suspect, and what the next crew needs to watch.
SAP / MES / CMMS feedback
Bridge production reality back into job, order, maintenance, and reporting systems without re-keying the same facts into four places.
If you want that priced against your own line rather than described: send me your last ten unplanned stops, and I will tell you which ones this would have shortened.
From machine signal to shift decision
The safest first deployment is usually read-only: collect the signal, explain the state, ask for human approval, and then write only to approved business or controls paths.
PLC / sensor / old machine
Tags, alarms, counters, recipes, serial output, files, or the awkward signal nobody has wired into reporting yet.Monitor / historian
Read-only collectors turn changes into history without putting commands on the machine network.Local or scoped model
The agent sees tags, manuals, drawings, work orders, and prior fixes together instead of in separate silos.Operator / maintenance / manager
A person gets the explanation, evidence, and next safest action before anything changes.MES / SAP / CMMS / shift log
Approved output becomes downtime, maintenance, production feedback, or the note the next crew can trust.Plant-floor useful. Plant-floor careful.
A useful system near machines has to respect the difference between seeing, suggesting, and changing. I keep those lines visible.
Read-only near machines by default
Monitoring a PLC is not writing to it. Writes require an engineered path: simulation, review, approval, rollback, and a human owner.
The connection budget gets counted first
Monitoring is not free because it only reads. A poller takes a CIP connection from the same finite pool the I/O connections come from, plus a TCP socket against a separate limit, and a bridge at either ceiling refuses the next connection request — including the one a module needs to come back after a swap. The count comes before the tag list, and poll intervals get sized to what actually changes.
OT-aware networking
Designed around segmentation, least privilege, audit trails, Purdue-model realities, and the fact that production safety matters more than clever software.
Local / on-prem deployment
Run local models and collectors on your own hardware when data, drawings, or machine context cannot leave the building.
Audit trails for decisions
Track what the agent saw, what it recommended, who approved it, and where the output landed.
No open-ended agents
Launch agents for scoped work with curated tools, capped budgets, server-side secrets, and observable terminals.
Works with ugly reality
CSVs, PDFs, historian exports, old HMIs, drawings, manuals, operator notes, and half-documented machine behavior are valid inputs.
Built for the seam between mechanics and data
The hardest manufacturing problems are often not purely mechanical, electrical, controls, or software. They live in the handoff between them: the part moved, the logic looked clean, the report was wrong, and nobody could prove where the truth diverged.
I build for that seam. Start with the signals, preserve the evidence trail, and give the people closest to the line a machine-speed helper that still respects human judgment.
Make the line easier to understand.
Bring a plant-floor problem that needs machine intelligence without unsafe control, and we will talk it through before anyone touches a PLC.