We built an AI agent for manufacturing: here's what it cost and what it does

The build, decoded

We've published a case study on the Multi-Agent Manufacturing System we shipped — 31% downtime reduction, 90 days, etc. The numbers there are real. This post unpacks what's underneath them: cost, complexity, what worked first try, what didn't.

What it actually does

Six specialized agents — Production Monitor, Maintenance Scheduler, Quality Anomaly, Inventory/Reorder, Energy Optimization, Shift Briefing — running 24/7 across a 40-machine sheet metal plant. They communicate through a shared event bus (Postgres). Every alert routes to a human via WhatsApp and the existing supervisor dashboard.

No agent takes physical action on its own. Humans always pull the trigger.

Why six agents and not one

The obvious question from anyone who has read a framework tutorial: why not one agent with six tools? We tried that shape first on an earlier build and moved away from it deliberately.

One agent with six jobs degrades at all of them. A single system prompt carrying production monitoring, maintenance scheduling, quality anomalies, reordering, energy, and shift handoffs is a prompt in which every instruction competes with five others. Accuracy on each individual job was measurably worse than the same job handled by a dedicated agent, and the failures were the unhelpful kind — it would do the most recently mentioned task well and quietly under-serve the rest.

Separate agents mean separate evals. Each has its own golden set, its own failure history, and its own regression signal. When quality moves you know which capability moved, which turns an investigation into a lookup. With one agent, a drop in the aggregate tells you nothing about where to look.

Blast radius. The Maintenance Scheduler writes to a calendar humans depend on. The Energy agent reads meters and suggests. Those deserve different permissions and different escalation thresholds, and that is far easier to enforce across process boundaries than inside one prompt.

The org chart is the interface. Operators already understand who does what on a shift. Mirroring that structure meant the mental model needed no explanation — the maintenance agent is the one that talks about maintenance. A single assistant would have needed the operators to learn a new abstraction during a shift, which is exactly the wrong moment to ask.

The cost of this choice is real: six sets of prompts, evals, and observability hooks rather than one. Agents two through six were far cheaper than the first, but not free.

Build cost

Fixed-fee Sprint: 12 weeks. Total build cost was in the range of $90K–$120K loaded. Engagement-specific factors moved the number:

• Data integration work. SCADA, ERP, operator tablets — three systems with three different access patterns. The first month was almost entirely data plumbing.
• On-prem edge gateway. Latency and data-residency requirements meant we deployed an edge gateway. Hardware was minor (NUC-class), but the deployment work added 2 weeks.
• Six agents instead of one. Each agent is a separate LangGraph workflow with its own tools, eval suite, and observability hooks. The marginal cost of agents 2–6 was much lower than agent 1, but it's still real.

Run cost

Monthly operating cost (after launch) is roughly $1,800/month:

• Anthropic API spend: $1,200/month (varies with shift volume)
• Edge gateway compute + cloud reasoning: $400/month
• Observability + logging: $200/month

A Monthly Retainer ($X — call it 60 hours/month) layered on top, used for: weekly model retraining, eval coverage as the plant added new machines, two new agent additions in the second quarter.

The 90 days, week by week

The timeline is the part clients most want and most rarely see, so here is roughly how the twelve weeks went.

Weeks 1–4: data plumbing, and almost nothing else. SCADA over an industrial protocol, ERP through a vendor API with rate limits, and operator tablets writing to a database nobody had documented. No agent work happened in this month, and trying to start it earlier would have wasted the effort — every agent decision depends on knowing what the data actually looks like, and the answer was different from what the documentation claimed in three of the three systems.

Weeks 5–6: the first agent, end to end. Production Monitor only. Event bus, prompt, eval suite, WhatsApp routing, observability. The point was not the agent; it was proving the whole path from sensor to a supervisor's phone, so that the remaining five agents were a content problem rather than an infrastructure problem.

Weeks 7–9: agents two through five. Each roughly two to three days of build plus a day of eval work, running in parallel with the edge gateway deployment. This is where the marginal-cost argument showed up: the scaffolding was already there.

Weeks 10–11: shadow running. All six live, alerting into a channel only the project team could see. Supervisors reviewed the alerts they would have received. This is where the Maintenance Scheduler's eval gap surfaced, and where the Shift Briefing format got rewritten twice.

Week 12: cutover and handover. Alerts moved to the real operator channels, with the retraining runbook and eval ownership handed to the plant's systems lead.

Nothing about that sequence is manufacturing-specific. The month of plumbing before any AI work is the part that generalises.

What worked first try

• One agent per role. Mirroring the org chart turned out to be the right mental model. Operators understood it immediately.
• WhatsApp routing. Operators don't read email and don't sit at a dashboard. WhatsApp was the only channel that mattered.
• Postgres as the event bus. Kafka was overkill. Postgres was already in the stack. Skipping Kafka saved 2 weeks.

How the 31% was actually measured

A number like "31% downtime reduction" deserves scepticism, including from the people who published it, so here is how it was arrived at and what it does not cover.

The baseline was already good. This plant logged unplanned downtime by machine and cause before we arrived, with about fourteen months of history. That is unusual, and it is the only reason a credible before-and-after was possible at all. Where a client has no baseline, the honest answer is that the first quarter of any build is baseline collection, not improvement.

The comparison window was ninety days against the same ninety days the prior year, which controls for the seasonal maintenance shutdown but not for everything. Order volume was higher in the measured period, which cuts against the result, and two machines had been replaced, which cuts in favour.

Attribution is partial and we said so. Some of the improvement is the agents catching anomalies earlier. Some is the Hawthorne effect of a plant paying closer attention to downtime because a project was running. We did not attempt to separate those, and anyone claiming a clean separation on a single-site deployment is guessing.

What the number excludes. It counts unplanned downtime only. Planned maintenance went up slightly, which is the intended trade — the Maintenance Scheduler moves work earlier. Measured on total machine hours available the improvement is smaller and, we would argue, more honest.

We publish the 31% because it is what the client's own system recorded. We would not defend it as a figure that transfers to another plant, and we tell prospects the same thing on the first call.

What we'd do differently

• Heavier discovery on shift handoffs. The Shift Briefing Agent was the dark-horse win, but we underspeced it. Two weeks more discovery would've gotten the format right faster.
• Tighter eval on the Maintenance Scheduler. This agent makes calendar decisions; the eval signal was lagging. We bolted on a synthetic test harness in week 8 — should've been week 1.
• Skipped LightGBM in v1. We layered classical ML for downtime prediction. In hindsight, simple thresholding would've covered 80% of value in v1, and ML could've come in v2 once the agent was trusted.

What the operators actually experienced

The technical rollout was the easy half. The part that decided whether this stuck was what happened on the floor.

Alert fatigue was the first real risk. The initial thresholds produced far too many alerts in week one of shadow running — technically correct, operationally useless. An operator who receives fourteen notifications a shift stops reading them by the third day, and no amount of accuracy recovers that attention afterwards. We spent most of week ten raising thresholds rather than improving detection.

The channel mattered more than the content. WhatsApp worked because it was already open on every supervisor's phone. A dashboard, however good, requires someone to go and look. This is the least sophisticated finding of the project and probably the highest-leverage one.

Trust was earned per-agent, not for the system. Supervisors trusted the Production Monitor within days because they could verify its claims immediately against the machine in front of them. The Maintenance Scheduler took the longest, because its suggestions were about the future and could not be checked on the spot. Verifiability drove adoption far more than accuracy did.

Nobody lost a job, and we said so early. The question came up in week two, from the floor rather than from management. Answering it plainly and immediately — the agents watch, humans decide, headcount is unchanged — removed a source of quiet resistance that would otherwise have shown up as unreported false alarms.

If you take one thing from this section: budget time for the human rollout separately from the build. It is not the same work, and the build being finished does not mean the deployment is.

What to ask before you green-light a build like this

1. Is your data accessible? SCADA + ERP + operator inputs all needed plumbing. If yours is locked behind vendors, double the timeline.
2. Do you have a human-in-loop owner? The supervisor on shift is the one who acts on the agent's signals. If that ownership isn't clear, build a dashboard first, an agent later.
3. Are you ready to run it? Monthly retraining and eval coverage is a 5–15 hour/month commitment. If no one owns that, the model drifts and you blame the agent.
4. Is the downtime cost honest? Our client knew their hourly downtime cost to the penny. That made the ROI math obvious. If you can't ballpark yours within 20%, do that first.

The parts that don't transfer

Case studies invite the reader to assume their situation is the same one. Several things about this build were specific, and pretending otherwise would set up the next project to disappoint.

The data was unusually good. Fourteen months of labelled downtime history, machine-level granularity, and a client who knew their hourly downtime cost precisely. Most plants we assess have some of that. The ones with none of it need a measurement project before an agent project, and that is a genuinely different engagement.

The client had a named owner from day one. The systems lead was in every weekly call, took the retraining runbook seriously, and still owns the evals. Where that person does not exist, the system degrades within two quarters regardless of how well it launched — we have watched it happen.

Forty machines is a helpful size. Large enough that the manual monitoring burden justified the build, small enough that a supervisor could sanity-check any given alert. Very small plants struggle to justify the fixed cost; very large ones need a different architecture, because six agents watching four hundred machines is not the same problem.

Sheet metal is forgiving. Discrete parts, well-understood failure modes, and tolerances that make anomalies reasonably crisp. Process manufacturing — chemicals, food, anything continuous — has noisier signals and would need more classical modelling and less agent reasoning.

None of this makes the approach unusual or fragile. It just means the honest version of "what would this cost for you" starts with a conversation about your data and your owner, not about your machine count.

What it'd cost for you

A scoped version of this — say 2–3 agents instead of 6, no on-prem requirement, cleaner data — runs $50K–$75K loaded over 8–10 weeks. With on-prem, multi-site, or a heavier ML component, plan on $90K–$150K.

If the math doesn't work, it doesn't work. We'll tell you on the call.