Agentic AI in Manufacturing

What "agentic AI" means

Agentic AI is software that pursues a goal across multiple steps and systems — reading data, making intermediate decisions, and taking (or proposing) actions — rather than answering one prompt at a time.

A chat assistant answers the question you asked. An agent is given an outcome — "prepare today's load sheets," "do a first-pass review of this NDA against our playbook" — and works through the steps itself: pull the ship-ready orders from the ERP, apply the template, propose routing, ask when something is ambiguous, and hand the result to a human for approval.

The practical mental model we use with plant teams: treat an agent like a capable new hire. It can follow a documented process, look things up, and draft work for review. You wouldn't give a new hire the keys to the ERP on day one — and you shouldn't give an agent that either. That instinct, formalized, is most of agentic-AI governance.

Agentic AI vs. copilots vs. RPA

Manufacturers usually arrive with one or both of the other two. The differences matter because they decide what each tool can and can't fix:

Approach	What it does	Where it breaks
RPA / workflow automation	Replays a fixed sequence of clicks or steps, exactly as recorded.	Any variation — a renamed column, a new form, an exception — stops it. Good for stable, high-volume, rule-based steps; bad for judgment.
Copilot / chat assistant	Answers questions and drafts content, one exchange at a time, with a human driving every step.	It doesn't carry a task across systems or steps. The human is still the workflow.
Agentic AI	Carries a goal across steps and systems, handles variation, asks when unsure, and proposes or takes actions under defined permissions.	Without scoping and guardrails: over-broad data access, silent failures on oversized tasks, and unowned "agent graveyards." All preventable — see below.

In practice the three coexist. A useful rule from our delivery work: the language model should do the reasoning, and cheap deterministic plumbing (workflows, APIs, scripts) should do the data movement. Routing everything through the model is how token bills become surprises.

Two questions every agent asks

Under the hood, every well-designed agent separates two concerns:

"What do I need to know?" — retrieval: reading your documents, manuals, and records, and answering with sources. This is where knowledge assistants and quality/spec lookups live.
"What do I need to do?" — action: live reads and writes into ERP, CRM, and other systems of record, under explicit permissions.

Keeping the two separate is what makes an agent both grounded (it cites what it knows) and safe to connect to real systems (its actions are individually permissioned). Most first-wave manufacturing agents are heavy on know and deliberately light on do.

The autonomy ladder

The single most useful governance tool we use: an agent earns authority in explicit rungs, and moves up only after measured performance at the current rung.

1 · Read

The agent can look, not touch. It reads systems and documents and answers questions with citations. Nearly every first agent should start here.

2 · Recommend

The agent drafts; a human approves. Load sheets, contract redlines, incident classifications — prepared by the agent, reviewed and released by a person.

3 · Modify

The agent changes non-critical records within defined limits, with logging and rollback — after it has proven reliable at recommending.

4 · Commit

The agent completes transactions end-to-end in bounded, well-measured cases. Few agents need this rung; none should start on it.

Rollout follows the same logic: shadow mode first (the agent works alongside the human, output compared, nothing released), then approval mode, then limited autonomy. The most common failure pattern we see is the reverse — giving an agent broad access before it has proven reliability.

Field lessons that don't appear in vendor decks

Decompose big jobs into small agents. In one build we worked on, a single giant prompt spanning multiple large tables failed silently — fabricating output past a certain row count. Splitting the job into three specialized agents with validation between them turned garbage into usable output. One agent, one job.
Watch the runtime. A practitioner heuristic from our delivery teams: an agent regularly running more than ten to twenty minutes on a task is usually a sign the task is mis-scoped — split it.
Scope data access like you mean it. Pointing an agent at an entire multi-terabyte document store is both a security problem and a cost problem. Index what the use case needs, under the user's own permissions, and nothing more.
Plan for maintenance or plan for a graveyard. Agents that ship without an owner and a review cadence decay as processes change. An unmaintained agent can cost more to resurrect than it did to build. Every agent needs a named business owner — not a team, a person.
Some of your worst pain isn't an agent problem. In a recent sprint, one of the nine signed initiatives was explicitly labeled "not AI" — a reporting mess whose right fix was dashboards on the existing data warehouse. Saying so is what makes the rest of the portfolio credible.

Platform note: everything above is platform-neutral by design. The same agent patterns deploy on Microsoft, Anthropic Claude, AWS, OpenAI, or Google — we've built on several, and the right answer usually starts from what a manufacturer already licenses. The logic lives in the workflow, not the vendor.

Common questions

Is agentic AI safe to connect to our ERP?

Yes — if it starts read-only under least-privilege access and earns write permissions rung by rung (see the autonomy ladder above). The unsafe version is the one that skips those steps. Your IT and security team should be in the room from the first design session, not consulted after.

Where do manufacturers usually start?

With read-only or draft-and-approve agents on quantified pain: knowledge assistants for Tier-1 IT and ERP how-to questions, document preparation (load sheets, first-pass contract review), and data prep. See our nine field-tested use cases — including the KPIs a real manufacturer's executives signed for each.

Do we need our data fixed first?

Not all of it — that's the "starting too big" trap. Some use cases run today on documents and spreadsheets you already have; others genuinely gate on integration work. Scoring each use case against data readiness, and sequencing accordingly, is the core prioritization move. Our readiness check shows which dimension is likely to constrain you first.

Will agents replace our people?

The programs that stick are augmentation programs: the same team handling more by getting manual work off their desks. In a market where experienced people are retiring faster than they're replaced, capturing their knowledge into agents is a retention strategy for expertise, not headcount reduction.

What does it cost to run?

Less than most executives expect, if the architecture is disciplined: models do reasoning only, plumbing moves the data, and retrieval indexes are scoped to what the use case needs. Run-cost estimation for your specific portfolio is a standard part of how we scope — with the assumptions written down so you can check them.