# AI automation in manufacturing: the gap between the floor and the office

Shop floor systems and business systems were never designed to talk. What crosses that boundary safely, what must not, and where the returns actually are.


Manufacturing already runs enormous amounts of automation, all of it on the production side. The gap is not on the floor — it is between the floor and everything else, where production reality and business systems meet through spreadsheets, printouts and somebody typing numbers at the end of a shift.

That boundary is where the accessible returns are, and it is also a boundary that exists for good reasons. Operational technology has safety and availability requirements that business software does not, and the first rule of crossing it is that information flows out more freely than control flows in.

## What we'll cover

- [Two worlds with different rules](#two-worlds-with-different-rules)
- [Out, not in](#out-not-in)
- [Getting data off the floor](#getting-data-off-the-floor)
- [Building it with CodeWords](#building-it-with-codewords)
- [What the office actually needs](#what-the-office-actually-needs)
- [Quality records and traceability](#quality-records-and-traceability)
- [Maintenance, and the limits of prediction](#maintenance-and-the-limits-of-prediction)
- [The people on the floor](#the-people-on-the-floor)
- [Changeovers, which is where the hidden time goes](#changeovers-which-is-where-the-hidden-time-goes)
- [Making it survive](#making-it-survive)
- [Limits worth knowing about](#limits-worth-knowing-about)
- [What to build first](#what-to-build-first)
- [Frequently asked questions](#frequently-asked-questions)

## Two worlds with different rules

**Availability outranks everything** on the production side, since a stopped line costs money by the minute.

**Safety systems are regulated** and interlocks exist to prevent harm to people.

**Equipment lifecycles are decades**, so a line may run controllers older than the engineers maintaining them.

**Patching is constrained** by validation requirements and by the cost of stopping production to do it.

**Business systems assume the opposite** — frequent change, connectivity, and downtime as an inconvenience.

**Treat them as separate domains** with a deliberate, narrow bridge rather than as one network.

## Out, not in

**Reading production data is low risk** and is where nearly all the accessible value sits.

**Writing control instructions is a different project** with safety implications and a different approval process.

**Never bypass a safety system**, in any circumstance, for any efficiency.

**Segment the networks** and keep the bridge narrow, monitored and one-directional where possible.

**A read-only historian or gateway** is the usual pattern and is the right one.

**If a proposal requires writing to the floor**, it needs the engineering and safety process rather than an integration conversation.

## Getting data off the floor

**Machines differ enormously** — some expose modern interfaces, some expose serial output, some expose nothing.

**Retrofit sensors** where the machine cannot report, which is frequently cheaper than replacing it.

**Timestamps and clocks drift**, and correlating events across machines requires them to agree.

**Units and tags are inconsistent** between machines and vendors, and normalising them is most of the integration work.

**Sample rates matter.** Storing every reading from every sensor produces volume nobody uses; aggregating loses the transient that explains a fault.

**Start with what already exists.** Most plants have more data being collected and discarded than they realise.

## Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open [CodeWords](https://codewords.agemo.ai) and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which production data, how it is aggregated, who sees it, and what raises an alert.
3. Authorize the connections — the historian or data gateway, the ERP or planning system, and your notification channel.
4. Describe the exceptions: a machine offline, a reading outside plausible range, a shift changeover, a planned stoppage.
5. Run it read-only against one line and compare its output against the shift reports for a fortnight.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the [pricing page](/pricing).

## What the office actually needs

**Actual output against plan**, in something closer to real time than a daily report typed at shift end.

**Downtime with its reason**, categorised, which is the single most valuable production number and the most inconsistently recorded.

**Scrap and rework rates** by product and by line, tied to what was running.

**Material consumption** against expected, which surfaces both waste and inventory drift.

**Order status that a salesperson can see**, so customer promises are based on reality.

**Not a dashboard of everything.** Three numbers people act on beat forty nobody reads.

## Quality records and traceability

**Traceability is a requirement** in regulated sectors and increasingly a customer demand elsewhere.

**Link batches to inputs**, so a supplier problem can be traced to affected output rather than to a whole month.

**Capture inspection results digitally**, which removes transcription errors and makes the record searchable.

**Automate the document assembly** for certificates and compliance packs, which is pure administration.

**Keep the raw record immutable**, with corrections as additions rather than edits.

**Recall scope is the test.** How precisely you can identify affected product is what traceability is actually for.

## Maintenance, and the limits of prediction

**Predictive maintenance is oversold** and occasionally genuinely valuable, and knowing which case you are in matters.

**It requires failure history**, and most plants have too few failures of any one mode to support a model.

**Condition monitoring is different** and more reliable — vibration, temperature and current are direct signals rather than predictions.

**Start with scheduled maintenance actually happening**, which is a coordination problem and is frequently the bigger gap.

**Automate the logistics**: work orders, parts availability, scheduling around production.

**Measure whether interventions prevented anything**, which is hard and is the only way to know if the programme works.

## The people on the floor

**They know why the line stopped** and the system usually does not, which is why downtime reasons are the weak data.

**Make recording trivial** — a button, a code, a tablet — rather than a form at the end of a shift.

**Do not build individual monitoring.** Automation that measures operators rather than machines will be resisted and the data will degrade.

**Show them the data**, since a team that can see its own output responds to it without being managed.

**Ask them what the line actually does** that the specification does not describe, which is where the useful detail is.

**Union and works council consultation** may be required before introducing anything that touches how work is measured.

## Changeovers, which is where the hidden time goes

Downtime gets attention because it is visible. Changeover time is planned, accepted, and frequently larger in total — and nobody reports it because it is not counted as a loss.

**Measure it**, from last good part to next good part, which is longer than the time anybody quotes.

**Break it into steps**, since the time is usually concentrated in two of them and nobody has looked.

**Separate what could be done while running** from what genuinely requires a stopped line, which is the largest single improvement available in most plants.

**Automate the preparation**: materials staged, tooling ready, documentation available before the line stops.

**Sequence orders to minimise changeovers**, which is a planning decision that needs the actual changeover matrix rather than an assumption.

**Report changeover time alongside downtime**, because a plant that only measures unplanned loss is ignoring the larger planned one.

## Making it survive

**Never let the automation affect production availability**, which is the constraint everything else is subordinate to.

**Handle machine downtime and disconnection** gracefully, since an offline machine is normal.

**Validate readings** against plausible ranges, because sensor failures produce confident nonsense.

**Buffer locally** so a network problem does not lose production data.

**Report the outcome**: machines reporting, gaps in coverage, alerts raised, and data quality by source.

## Limits worth knowing about

**Legacy equipment may be genuinely inaccessible** without retrofit hardware.

**Vendor lock-in is common**, and some systems restrict data access contractually as well as technically.

**Physical reality constrains everything** — cycle times, changeovers, material properties.

**Plant networks are frequently fragile**, and adding traffic is a change that needs engineering review.

**Automation does not add capacity.** It surfaces where capacity is lost, which is valuable and different.

## What to build first

Downtime capture with reasons, made trivial for operators to record and aggregated automatically. Downtime is the largest recoverable loss in most plants, the reasons are what make it actionable, and they are currently written on paper or reconstructed at shift end — which is why nobody trusts the number.

Two habits make the difference. Keep the bridge one-directional — data out, never control in — since that single rule keeps this an integration project rather than a safety-engineering one. And make recording a reason take one button press, because every additional step degrades the quality of the only data that makes downtime actionable.

## Frequently asked questions

### Where are the accessible returns in manufacturing automation?

Not on the line, which is already automated, but at the boundary between the floor and business systems — where production reality currently reaches the office through spreadsheets, printouts and somebody typing numbers at shift end.

### Should automation write instructions to production equipment?

No, not as an integration project. Reading production data is low risk; writing control instructions has safety implications and needs the engineering and safety process. Never bypass a safety system for any efficiency.

### What makes getting data off the floor difficult?

Machines differ enormously in what they expose, clocks drift so events cannot be correlated, and units and tags are inconsistent between vendors. Normalising them is most of the integration work.

### What should the office actually see?

Actual output against plan, downtime with categorised reasons, scrap and rework by product and line, material consumption against expected, and order status a salesperson can rely on. Three numbers people act on beat forty nobody reads.

### Is predictive maintenance worth it?

Sometimes, and it is oversold. It requires failure history that most plants do not have for any single failure mode. Condition monitoring is a more reliable starting point, and making scheduled maintenance actually happen is frequently the bigger gap.

### Why are downtime reasons such poor data?

Because operators know why the line stopped and the system does not, and recording it is usually a form at shift end. Making it one button press is what improves the only data that makes downtime actionable.

### Should operators be individually monitored?

No. Automation measuring people rather than machines is resisted and the data degrades in response. In several jurisdictions it also requires consultation before introduction.

### Can automation increase plant capacity?

No. It surfaces where capacity is being lost — downtime, scrap, changeovers — which is valuable and is a different claim.

### Why measure changeover time separately?

Because it is planned, accepted and usually larger in total than unplanned downtime — and it is not counted as a loss, so nobody looks at it. Measuring from last good part to next good part usually reveals a longer time than anybody quotes.

### What is the largest changeover improvement available?

Separating work that could be done while the line runs from work that genuinely needs it stopped. In most plants a meaningful share of changeover time is preparation that did not have to happen during the stop.

## Related reading

- [Workflow automation for supply chain](/blog/workflow-automation-for-supply-chain)
- [Workflow automation for operations teams](/blog/workflow-automation-for-operations-teams)
- [Automating API health checks](/blog/automate-api-health-checks)