Hybrid Intelligence for Manufacturing OT

What is hybrid intelligence for manufacturing OT?

Hybrid intelligence for manufacturing OT, often called hybrid AI, splits an AI system in two. A cloud agent does the reasoning: it understands the request, retrieves the governed procedure, and plans. A small local agent on the plant network holds the authority: it validates every step against physical limits before a machine moves. Reasoning goes where the compute is. Authority stays where the machine is.

In short:

• Onboard robot intelligence will always lag the state of the art. The hardware ships once; the models do not.
• Cloud-only control of OT is the wrong answer. Plant security teams are right to reject it.
• The hybrid split lets the reasoning improve continuously without touching the machine, while safety stays local and deterministic.
• Every step is observed and recorded, which is what makes a non-deterministic shop floor measurable and improvable.

At IMTS 2026, Karini AI demonstrated this on a live kitting cell. This post explains the architecture and what the demo shows.

Why aren't smarter robots enough on their own?

Because intelligence built into a machine is frozen at the moment it ships, and the shop floor keeps changing.

Manufacturing automation has moved through three generations:

1. Pre-programmed robots repeat a taught path. They are fast and reliable until anything changes.
2. Vision-guided robots can detect a part and adjust a pick. Vision tells them where something is, not what they should do about it.
3. Robots with onboard intelligence can interpret more of their environment. This is real progress, but the models on board are sized to the hardware and updated on the hardware's schedule.

The third generation has a structural limit. Frontier models improve every few months. A controller on a plant floor is refreshed every few years, if at all. Onboard intelligence will always lag the state of the art.

There is a second limit that matters more. A robot, however smart, does not know your released work order, your current drawing revision, or what is in stock. That knowledge lives in PLM, ERP, MES and document control. Intelligence without that context produces confident actions based on stale or invented procedure.

The obvious alternative, controlling OT directly from the cloud, is worse. Plant security teams reject it, and they are right to. A network outage should never decide whether a machine is safe.

How does the hybrid architecture work?

It runs in three layers: knowledge and reasoning in the cloud, secure transport between, and authority on the plant floor.

• Source systems hold the facts: PLM for parts and engineering changes, ERP and MES for work orders and stock, document control for procedures and layouts.
• The Karini Industrial Digital Thread connects them in a knowledge graph on Amazon Neptune (semantic layer), so one query can answer which layout revision applies to which work order.
• The planning agent on the Karini platform takes the request, retrieves the governed procedure, and produces a plan that cites its sources. It proposes. It never commands.
• The Karini MCP Registry is the only way the planning agent reaches tools and equipment. Connectors are admin-approved, credentials are held by policy rather than by the agent, and every call is traced.
• Karini observability records every tool call, validation and refusal, with the rationale behind it, across both the cloud and the plant floor.
• AWS IoT Core carries plans down and results back over MQTT, with TLS and X.509 mutual authentication and per-device policies.
• The local agent runs with a small footprint on the plant network. It validates every step against the workspace envelope, sequence dependencies and cycle limits, and it can refuse. This is where authority lives.
• Vision observes the cell, reporting occupancy, part class and confidence at each step, so the local agent knows what actually happened. This closes the loop.
• The robot executes validated plans only. Each completed kit is written back to the digital thread as an as-built record.

The split falls along two lines at once. Validating a step against physical limits is computationally small, so it fits on constrained plant hardware. Language understanding and retrieval are expensive, so they run where the compute is. The piece that must be local is also the piece that is cheap to run locally.

What does hybrid intelligence look like on a real cell?

At IMTS 2026 we ran it on a kitting cell: a robotic arm, six color-coded parts, and an eight-compartment kit tray. A visitor calls a work order. The agent retrieves the kit, the arm builds it, and every placement cites the document behind it.

Kitting was chosen deliberately. It is a real process with a real cost. A wrong or missing part stops a line, and every manufacturing engineer has a story about it.

The default run

An operator asks: "Build the kit for WO-4471." The cloud agent retrieves the work order, bill of materials BOM-2200 rev B, and kit layout KIT-118 rev C, then checks inventory. It states its plan and time estimate before anything moves. Then each placement appears on screen with its source.

The source citation beside each placement carries the whole idea. The instruction came from a controlled document, the document has a revision, and the machine acted on it.

When the agent refuses

The refusals are features, and we show them on purpose.

• Material shortage. WO-4472 needs three P-1103 shims; two are on hand. The agent stops, names the approved alternate from alternates list AAL-114, notes that it is scoped to this assembly only and not in stock, and offers to flag the shortage.
• Ungrounded request. Ask for a work order that does not exist, or ask it to improvise, and it declines: no controlled document, no placement.
• Out of envelope. The local agent rejects any step outside the arm's safe workspace, without consulting the cloud.

Procedure is retrieved, not generated. If it cannot be grounded, it does not happen.

How does the system get better over time?

By observing every step and feeding what it sees back into the plan and the record.

The physical world is non-deterministic. A part sits two millimetres off. A grip slips. A plan that was correct at the start is not always correct three steps in. So a vision system on the cell watches each step, and the result returns to the agent, which can correct the plan within the run.

Every step is also recorded in Karini observability, across both tiers:

• the instruction the person gave
• the documents and revisions the agent retrieved
• the plan it proposed
• each validation and each refusal from the local agent, with its reason
• what the vision system saw when the plan met reality

That record does two jobs. It is an audit trail: any physical action traces back to the instruction and the document that authorized it. And it is the raw material for improvement: failure patterns, slow steps and recurring refusals become visible and fixable.

This is where the hybrid split pays off. Improvements land in the reasoning layer: better models, better retrieval, better policies, better knowledge in the graph. The robot on your floor gets better without a firmware update or a re-teach. Authority stays local and stable while intelligence keeps improving above it.

How can you get started with secure, intelligent automation with guardrails?

Start with one workflow, ground it in the knowledge you already have, and define the guardrails before the agent acts. Autonomy grows as the record earns trust.

1. Pick one workflow. Choose a process that is repetitive, costly when it goes wrong, and backed by controlled documents. Kitting, order entry and work instruction lookup are common first choices.
2. Connect the knowledge it depends on. Bring the relevant PLM, ERP, MES and document control sources into the Karini Industrial Digital Thread, with your existing role-based access preserved.
3. Define the guardrails first. Decide the limits, approvals and refusals the process needs. Where equipment is involved, enforce them in a local agent on the plant network, not in the cloud.
4. Keep a human in the loop, then widen autonomy. Start with people approving each plan. Use the observability record to see where the agent is reliable, and extend autonomy step by step.

Karini runs inside your own cloud environment, so your data and security posture stay where they are.

Talk to the Karini team about your first workflow

Frequently asked questions

Is it safe to connect AI agents to manufacturing OT?

Yes, if authority stays local. In a hybrid design the cloud agent only proposes plans. A local agent on the plant network validates every step against physical limits and can refuse, even with no cloud connection.

Why not run everything on the robot, like an autonomous vehicle?

Because plant hardware is constrained. Vehicles carry enough compute to run everything on board. PLCs and industrial PCs do not, so manufacturing needs a hybrid. The cut belongs at authority: deterministic validation is small enough to run locally, while reasoning runs where the compute is.

How does the cloud agent communicate with the local agent?

Through AWS IoT Core, over MQTT with TLS and X.509 mutual authentication, and per-device policies. Commands flow down, and results and state flow back.

What stops the agent from inventing a procedure?

It retrieves procedure instead of generating it. Work orders, BOMs, kit layouts, change notes and approved alternates live in the Karini Industrial Digital Thread, a knowledge graph on Amazon Neptune. If a request cannot be grounded in a controlled document, the agent refuses.

What is a manufacturing knowledge graph used for?

It connects data that sits in separate systems. Knowing which kit layout applies to a work order requires traversing PLM, ERP and document control together. No single system can answer it alone.

Does this work with robots and machines we already own?

That is the intent. The local agent adapts the plan to the machine's own control interface. Today it drives a desktop arm; in a plant it is whatever is already on the floor.

Can every action be audited?

Yes. Karini observability records the instruction, retrieved documents, plan, validations, refusals and vision observations for each step, so any physical action traces back to the instruction that caused it.