Superintelligence in Manufacturing: Prepare Processes and Records

Superintelligence in Manufacturing: Prepare Processes and Records

Superintelligence in manufacturing, today, is less a product you buy and more a condition you prepare: written process knowledge, reliable records and clear limits on what an agent may decide. Plants that organize this now get useful agents immediately and are ready for more capable models later. Safety and quality decisions stay with authorized people, whatever the model can do.

Key takeaways

• Superintelligence is a hypothesis about the future. What the plant controls today is the quality of the knowledge and records that any agent will consult.
• Procedures, acceptance criteria and exceptions need to be written, versioned and owned, not kept only in the head of the most experienced operator.
• An agent can read, summarize, compare and propose. Releasing a lot, approving a deviation and changing a safety parameter stay with humans.
• The more capable the model, the more minimum permissions, a record of every action and testing before widening scope matter.
• The safe path is to map, limit, pilot one real workflow and only then decide whether to expand, adjust or stop.

What does superintelligence in manufacturing mean in practice?

The term describes systems that would outperform people at nearly all cognitive tasks. No plant runs anything like that today, and it helps to separate three levels: what vendors' official documentation describes, what you observe when deploying agents in real processes, and what is hypothesis about the future. This article uses the third category only as a reason to prepare, not as a promise. For the difference between the concepts, see the difference between AGI, ASI and AI agents.

For anyone running a plant, the question is simple: if a far more capable agent had access to our orders, production orders and inspection reports tomorrow, would it find information that is correct, current and bounded? If the answer is no, the problem is not the model. It is the foundation the model will read.

That is why the preparation is the same for a modest agent today and a very capable one tomorrow: organized knowledge, restricted access, logged actions and critical decisions under human responsibility.

What process knowledge needs to be written down?

Much of what holds quality together in a plant is tacit knowledge: the operator who hears that a machine is off its setpoint, the supervisor who knows which customer accepts which tolerance. An agent cannot reach that. It only works with what has been recorded in a readable form.

The minimum set usually includes:

• Work instructions and procedures by line or cell, with a revision date and an owner.
• Acceptance criteria by product and by customer, including tolerances and agreed exceptions.
• Order routing rules: what requires engineering review, what depends on raw material stock, what carries a contractual deadline.
• A tree of known causes for recurring failures, with what has already been tried.
• A list of what counts as a safety or quality decision, and who has the authority to make it.

The goal is not to write everything at once. It is to start with the workflow that will be the pilot and give each document a clear current version. Duplicate documents, old drafts and personal spreadsheets are the biggest risks, because the agent cannot tell which one is valid.

As for how to give this material to the model, the common technique is to retrieve relevant passages at the moment of the question rather than training the model on everything. AWS guidance on retrieval-augmented generation compares retrieval with fine-tuning. For a plant, retrieval has a practical advantage: when a procedure changes, you only update the document.

How do you prepare order, production and quality records?

A procedure says how things should be. A record says what happened. An agent that helps with orders and quality needs both, and the second is usually messier.

Issues that show up often in plants of any size:

• Identifiers that do not match: the order number in the ERP, the production order number and the lot number on the inspection report follow different formats.
• Free-text fields with internal abbreviations, which need a glossary.
• Nonconformance records with no cause, corrective action or closure.
• Sensor and inspection data in separate systems, without comparable timestamps.
• Edits with no trail, where nobody knows who changed a value or when.

The preparation is simple data engineering: a common key across order, production order and lot, a glossary, required fields and a change history. This is worth doing even without AI. For the context the agent receives, Anthropic's guidance on context engineering for agents reinforces a useful principle: provide little information, make it relevant and well labeled, and do not dump everything into the conversation.

When records contain personal data, such as identified operators or customer data, LGPD applies. The practical rule is to separate what the agent needs to see from what it does not, and to mask the rest.

Which decisions does the agent never take?

A model's capability is not authority. A good policy separates what the agent does alone, what it proposes for approval and what stays out of its reach. A decision guide in list form:

• Can do alone: look up information in procedures, summarize an order's history, compare an inspection report with the acceptance criterion and flag differences, draft an internal notice.
• Can propose, with human approval: reschedule orders within defined rules, suggest the probable cause of a nonconformance, open a deviation record with the fields filled in.
• Out of reach: release or block a lot, approve a specification deviation, change an equipment parameter, disable an interlock or alarm, decide the segregation of suspect product.

The test for the third category is direct: if a mistake could hurt someone, contaminate product, trigger a recall or break an applicable standard, the decision is human. This does not depend on the model being right most of the time. It depends on there being a person with formal responsibility. When an automated decision affects data subjects, it is also worth knowing the right to review under Article 20 of LGPD.

In technical practice, this becomes permissions: the agent gets read-only credentials wherever possible, and tools that write to systems require approval. OWASP's authorization guidance describes the principle of least privilege, which applies equally to people and to agents.

Illustrative scenario: an urgent order and an inspection report outside the criterion

Imagine, as an illustrative scenario, a parts manufacturer that receives an urgent order from a customer with a tight dimensional tolerance. The planner consults the agent.

What it does: it finds the order, cross-checks it against the production order and the history of earlier lots of the same item, and retrieves that customer's acceptance criterion. It notices that the last inspection report came close to the limit and that two open nonconformances on the same machine have no recorded cause. It builds a summary with the sources cited and suggests that the planner talk to quality before promising a delivery date.

What it does not do: promise the date to the customer, release the lot or suggest ignoring the tolerance. A deviation request, if one is needed, is opened as a draft and goes to the quality manager with the history attached. Every query and every draft is logged.

The value is in saving the search across several systems and in raising a risk that would otherwise go unnoticed. The decision stays where it has always been.

How to start: map, limit, pilot, hand over

The method I apply in AI projects follows four moves, and they fit manufacturing well. For the most common starting point, see also how to start with maintenance and quality.

• Map: describe the current flow of one process (for example, reviewing urgent orders), who decides each step, which documents and systems are consulted and how the result is measured today. This is the baseline.
• Limit: define which data the agent sees, which actions it can run and which decisions are off limits. Start with read access and human approval on anything that writes.
• Pilot: run one real workflow, not several, with logs of every query and action and a success metric agreed in advance, such as time to prepare an analysis or the share of drafts accepted without rework.
• Hand over: give the team the documentation, the logs and the operating procedure, and decide explicitly whether to expand, adjust or end the project.

Ongoing operation, when it makes sense to outsource it, can be handled through Be Human (be-human.ai), with monitoring and maintenance of the agent. The decision about what the agent may do, however, stays with the plant.

How do you test and monitor before widening scope?

A more capable agent makes less obvious mistakes. That is why testing stops being optional. Three practices give you a base:

• A set of real, anonymized cases with the expected answer defined by quality, including trap cases where the correct response is to refuse or escalate.
• A test environment with simulated data and fake tools, to check what the agent would try to do without touching real systems. There is a guide on testing agents with mocks and a sandbox.
• A searchable decision log: which question, which sources, which proposal, who approved.

On evaluation, Anthropic describes how to structure evals for agents, and the NIST AI Risk Management Framework offers vocabulary for mapping, measuring and managing risk in an organized way. For architecture, the advice in Anthropic's guide to building effective agents is to start with the simplest solution and increase autonomy only when there is evidence that it pays off.

Another point of care is untrusted text input, such as supplier emails or customer attachments, which can contain hidden instructions. Treat that content as data, never as a command, and limit the tools the agent can trigger from it.

Frequently asked questions

Does superintelligence already exist in manufacturing? There is no public evidence of such systems running in plants. What exists are useful agents on bounded tasks, such as looking up procedures and supporting analyses. Preparing the foundation now serves those agents and any more capable ones that may come.

Where should a manufacturer start? With the workflow where information is scattered and mistakes are cheap to fix, such as reviewing urgent orders or consulting nonconformance history. Pick one, map the current process, define the metric and run a pilot with human approval on anything that writes to systems.

Can the agent release a lot or approve a deviation? It should not. Lot release, deviation approval and changes to safety parameters are decisions with formal responsibility and need an authorized person. The agent can gather evidence and draft the request for that person to decide.

Do I need my own model trained on my data? Usually not to start. Retrieving passages from up-to-date documents is typically enough and is easier to maintain and audit than training a model. The choice should be tested on your own case, and the handling of personal data should follow LGPD.

Sources

• NIST: AI Risk Management Framework
• Anthropic: Building effective agents
• OWASP: Authorization Cheat Sheet
• Anthropic: Demystifying evals for AI agents