The AI Prototype Worked. Now Comes the Manufacturing Execution Problem.
The AI prototype worked.
A supplier email arrived. The model identified the purchase order, extracted a revised delivery date, explained the change and called an API.
For a manufacturing technology team, that can be an important proof point. It demonstrates that modern models can understand unstructured operational information and take useful action.
It does not yet prove that the transaction can run in production.
The prototype proves intelligence. Production has to prove execution.
The first demo removes the easy uncertainty
Before generative AI, many operational workflows appeared difficult because software struggled with messy language, documents and exceptions. Modern models change that. They can interpret email, PDFs, messages and free-form instructions with remarkable flexibility.
That removes one major barrier.
But manufacturing execution introduces a different set of questions that are less visible in a demonstration:
- What is the current transaction state?
- Which source is authoritative?
- What action is the agent permitted to take?
- What happens if the API call succeeds but the downstream operation fails?
- What if a second message contradicts the first?
- Who approves a material commercial deviation?
- How does the system recover after partial execution?
- How is evidence preserved for audit?
- When can the transaction be declared complete?
These are execution questions, not model questions.
A simple supplier-update demo becomes a transaction problem
Suppose a supplier initially commits to 10,000 units on Friday.
The supplier later sends an email: 7,500 will arrive Friday, 2,500 Monday. The prototype extracts the two dates correctly.
Now add production reality.
One line feeds a plant with only two days of inventory. Logistics already booked a vehicle for the full quantity. The alternate supplier has limited stock. An expedite exceeds the buyer's approval threshold. Quality requires a certificate before substitution. Finance has already accrued the original movement.
The next step cannot be reduced to “update the PO date.” The transaction must be interpreted against policy and downstream impact.
This is where the Operational Fragmentation problem becomes visible. Each system may know its own part of reality while no system owns the complete response.
The production stack below the agent
A production-grade execution layer needs capabilities that rarely appear in the first prototype.
Persistent transaction state
The system must know what was requested, what was committed, what changed, which downstream obligations exist and which version is current.
Identity and authority
Reading an email is different from amending a PO, rebooking freight or approving a financial exception. Every action needs explicit authority.
Deterministic policy
Models can interpret ambiguity. Tolerances, approval limits, segregation of duties, compliance constraints and mandatory controls should remain deterministic where appropriate.
Exception recovery
Real workflows fail midstream. A carrier rejects capacity. ERP rejects a write-back. A document is missing. A supplier reverses a commitment. The system needs a recovery path rather than another alert.
Idempotency and retries
If an API times out, repeating an action must not create duplicate POs, bookings, approvals or postings.
Audit evidence
The enterprise must be able to reconstruct what signal arrived, what the system believed, which policy applied, what action occurred and who approved it.
Outcome verification
Sent is not acknowledged. Booked is not picked up. Filed is not released. Approved is not posted. Execution ends when the intended business outcome is verified.
Production complexity grows at the handoffs
A procurement agent can be very effective within procurement. A logistics agent can be very effective within logistics. A finance agent can be very effective within finance.
The manufacturing transaction still moves between them.
That is why building several successful agents can create a new architecture problem. Each agent needs access to the transaction's current state, and each change must be propagated without forcing people to reconstruct context.
A Multi-Enterprise Execution architecture treats the transaction as the persistent object. Specialized agents act against the same governed state rather than creating separate interpretations.
ERP write-back is not a technical afterthought
Manufacturers need authoritative systems. SAP, Oracle, Dynamics and other ERPs remain critical because financial integrity, master data, approved documents and auditability depend on governed records.
An AI workflow is not complete because an agent reached a conclusion. The verified outcome must reach the System of Record safely.
If write-back fails, the transaction remains incomplete. If the agent writes an intermediate interpretation before required validation, the authoritative record can become wrong faster.
AI should not make ERP less important. It should make what reaches ERP more complete and more verified.
The operational memory problem begins after go-live
Once execution runs in production, another question appears: what should the system remember?
A model transcript is not enough. The useful evidence is the full loop: signal, state, decision, policy, action, external response and verified outcome.
This is Operational Memory. It allows future transactions to use evidence about what actually worked rather than simply retrieving previous conversation.
What a manufacturer should prove before scaling an internal agent
Before moving from prototype to production, test the system against uncomfortable conditions:
- conflicting supplier messages;
- partial delivery and quantity splits;
- approval thresholds;
- duplicate events;
- API timeouts;
- ERP rejection;
- missing documents;
- late downstream events;
- human override;
- cross-functional exception recovery.
The goal is not to prove that the model always has an answer. The goal is to prove that the transaction remains governed when the model, partner or system encounters uncertainty.
Where Lasya fits
Lasya AI is Settyl's System of Execution for supply chains. It is designed around the production layer beneath and around agents: transaction state, governed actions, Multi-Enterprise Execution, exception handling, evidence, Operational Memory and verified ERP outcomes.
Manufacturers can still use their preferred models and internal AI capabilities. The architectural question is whether every new agent should also require the enterprise to recreate the execution substrate around it.
The harder test
The first AI demonstration asks:
Can the agent understand the task?
Production asks:
Can the transaction survive real operations until the outcome is verified?
That second test is where enterprise AI becomes an execution architecture.
Frequently Asked Questions
Why do AI prototypes struggle in production?
Because the prototype often proves reasoning and tool use while production requires durable state, permissions, policy, recovery, audit evidence, observability and reliable integration.
What should manufacturers test before scaling agents?
Test contradictory signals, partial failures, approvals, duplicate events, retries, ERP rejection, human override and cross-functional exceptions—not only the happy path.
Related Reading
Bring last month's exceptions.
Leave with the ROI model.
30-minute working session for the CFO and Controller. We'll run your real exception backlog through Lasya, project the working-capital release, and walk through the audit-trail evidence your InfoSec team will request.
