Why AI-native manufacturing operations are inevitable

Walk onto the operations floor of any mid-sized manufacturer and you'll see the same scene: a planner with three monitors, an ERP screen frozen mid-refresh, an inbox with 200 unread RFQs, and a phone that hasn't stopped ringing since 7 AM. The software was built thirty years ago for an operator who would sit, scan, click, scan, click. The operator is still doing exactly that. The volume has tripled. The headcount hasn't.

This is the gap every manufacturing-software vendor is now trying to close with "AI features" — a chat sidebar here, an autocomplete there, a recommendation engine pinned to the dashboard. None of it is wrong. All of it is insufficient. The constraint isn't that humans need help reading the screen faster. The constraint is that the screen exists in the first place.

The bolt-on era will end faster than people expect

The current wave of manufacturing AI looks a lot like the first wave of mobile apps in 2008 — desktop UIs shoved into a smaller frame, every interaction still routed through the same human-shaped pipeline. We have ERP-with-a-chatbot, MES-with-a-copilot, supplier portals that "summarize for you." The interaction model is unchanged: a person clicks, the system responds, AI sits beside them as a faster auto-complete.

This is a real productivity improvement. It is also a local maximum. Every workflow that ends in a human reading a screen and entering data into a form is a workflow that an agent can do end-to-end. The bottleneck is not summarization. The bottleneck is decision-making + action, with judgment about when to escalate.

What changes in the next 24 months is the cost curve on capable inference. Models that could draft an email a year ago can now read a CAD attachment, query an ERP, reconcile a discrepancy across three systems, and write back the answer — for a few cents per task. The economics of running an agent against your operations stack now favor the agent doing the entire loop, not handing the screen back to a human at every step.

Two failure modes of bolt-on AI

There are two failure modes we see repeatedly when AI is grafted onto workflows that were designed for humans:

1. Tab fatigue. The "AI sidebar" lives next to the existing UI. The operator still has to know where to look, what to ask, and how to act on the answer. The cognitive load goes up, not down. Speed improves at the level of the keystroke; throughput at the level of the case is unchanged.
2. Approval theater. The AI drafts the action. The human re-reads the entire context, validates it, then clicks Send. The human is now the bottleneck, the AI is the assistant, and nobody has shipped what was promised: autonomous operations.

Both failure modes collapse when you stop asking "where does AI fit in this workflow?" and start asking "what would this workflow look like if the agent owned it end-to-end, with escalation as the exception path?"

What "AI-native" actually means in operations

AI-native is an architecture commitment, not a feature label. A few things have to be true at the same time:

• The agent is the primary operator. Humans review, approve, override. The default path is the agent doing the work. The UI is built for the cases where the agent escalates, not for the cases where it succeeds.
• The system has an opinion about what should happen. Not "here are 12 open RFQs, please choose one to work on." Instead: "I've drafted quotes for 9 of them, flagged 2 for pricing approval, and one I can't classify — here's why."
• State is durable and explainable. Every action the agent takes is logged with the rationale, the inputs it consulted, and the rule or skill that fired. This is non-negotiable in operations: a missed shipment that nobody can trace is worse than a missed shipment with a clear audit trail.
• The integration model is read-and-write, not read-and-display. AI-native ops software has to write to the ERP, the CRM, the supplier portal, the email thread. Read-only AI is a research project. Read-write AI is a production system.

The product implication of all four bullets is that the visible surface area of the software shrinks. The dashboard is no longer the workflow — it's the audit trail of the workflow. The chat interface is no longer the feature — it's one of several signals (email, webhook, schedule) that wake the agent up.

Why incumbents have a hard time getting here

Existing ERP and MES vendors built their data models around forms. A purchase order is a row in a table that a human filled out. A quote is a row in a table that a human approved. The schema encodes the human-in-the-loop assumption everywhere — required fields are required because a person had to type them; states are states because a person had to click to advance them.

Retrofitting agent-native behavior onto this schema is doable but slow. Every workflow has to be re-modeled with the question "what does this state mean when no human touched it?" Most incumbents are answering this question one workflow at a time, three years late.

The greenfield opportunity is to build the schema and the agent at the same time. State transitions can be triggered by agent rationale ("supplier confirmed via email, advancing to confirmed_ship") rather than by a click. Approval gates can be expressed as tool-tier policy ("any write over $50k requires human approval") rather than hard-coded form requirements. This is much easier to do when you didn't spend the last twenty years assuming a person was at the keyboard.

What we're betting on at Korso

We started Korso with a specific posture: the agent is the operator. The case is the primary object — every open thing the system is tracking lives in an Attention Surface that the agent looks at first. Every action is logged with its skill, its inputs, and its rationale, so a human reviewing yesterday's work can answer "why did the agent do this?" in seconds, not hours.

The pieces that make this work are familiar — Temporal for orchestration, Postgres for case state, a tool layer for ERP read/write, a knowledge layer where the operating model lives as plain markdown that the agent consults at decision time. None of them are individually novel. The bet is on the architectural commitment: every workflow is built for the agent first, the human-shaped UI is what surfaces around the edges.

We think this is the right bet for one operational reason: the moment your agent can do a $200 task for $0.20, the question stops being "should we automate this" and starts being "can our software express the work in a way the agent can pick up." Vendors who can answer yes win the next decade. Vendors who can't will be wrappers around a chat input on top of forms designed in 1995.

For a longer treatment of the operating-model architecture behind this — knowledge, state, execution, tool, connector — see our thesis.

What to expect from this blog

The cadence here will be low and deep. One to two posts a month, written by the people building Korso, focused on what we're actually learning from running agents against production manufacturing operations. Expect engineering deep dives, customer stories where the operator lets us share them, and pointed opinions about where the industry is heading.

The point isn't to publish — the point is to compound. Manufacturing operations is a field where the right answer in 2026 is going to look obvious in 2030 and embarrassing in 2034. We'd rather be on the record now, with the evidence in hand, than convenient-after-the-fact when the bolt-on era ends.