Agentic Loom
Governed agentic recipes for batch manufacturing
Every step admitted before it runs. Every exception decided by a person, on the record.
Agentic Loom is a recipe designer and runner for regulated batch processes. Recipes are built from what each unit of equipment declares it may do. Every phase is checked by an admission model while you write it, and again at its gate when it runs. When a step is refused, a person decides what happens next, choosing only from what the model permits. It sits beside your MES and does not replace it.
Admission blocked · a fact
| Step | Refusal |
|---|---|
| 02 · load | State IDLE: the unit is not in a state its own declaration permits for this action |
What you may do
| Accept as is | with a justification, kept beside the refusal |
| Rework | change values and ask again |
| Reject | with a reason |
From the demonstration recipe. Where the evidence does not exist, the only choice is to stop. Where the check got no answer, nothing can be accepted.
The demo, in four minutes
A recipe is built from the unit's declarations, checked live, compiled and run. At each blocked step the operator is offered only what the model permits; the run ends with a batch record and every decision on file. Then the same recipe is planned against another recipe that holds the unit, and against a lot history that carries an excluded material.
How it works
A recipe is a sequence of phases on units of equipment. Agentic Loom never lets a phase run on the strength of the recipe alone: each one is asked, before it runs, whether it may.
Recipes from declarations
Each unit's descriptor declares the actions it permits and the limits on each. The editor's palette is built from those declarations, so a recipe cannot ask a unit for something it has not declared, and every parameter shows its limit beside it.
Checked while you write
Every phase is asked the same question its gate will ask when the recipe runs, and the answer appears on the phase as you type: admitted, will pause, or undecided. Where the declarations cannot tell, the editor says so rather than guessing, and an author's assumption is marked as one and never used by a run.
Gates at run time
A refused step pauses the run. The operator sees why, and is offered only what the admission model permits for that refusal: accept as is with a justification, rework and ask again, or reject with a reason.
The record
Every decision is kept under its own name, with who signed and why: blocked, reworked, accepted as is, rejected, upheld. The refusal stays in the batch record whatever was decided.
Across recipes and lots
While you plan, Agentic Loom shows when another recipe holds the same unit over an overlapping window, and when a lot's history carries a material the procedure excludes. Today these are findings for the author; a gate at run time still asks only about its own step.
Governance by construction
The rules below are enforced by the software, not left to procedure. The screen offers what is permitted, and the server checks every decision again before it takes effect.
Nothing runs unadmitted
A refusal stops the step
No step executes past a refusal unless a person dispositions it, and that disposition goes on the record with their name.
Permissions from the model
Not every refusal can be waived
A refusal that reports a fact can be accepted, reworked or rejected. A refusal that reports missing evidence cannot be waived; signing it off would turn "we cannot tell" into "it is fine". A decision that is not permitted is refused and recorded, never applied.
Undecided is not a yes
Silence never admits
If the admission check does not answer in time, the step is undecided: it can be asked again or the run stopped. It is never recorded as a refusal, and never accepted.
Reasons on file
Overrides need justifications
Accepting a refusal as is requires a justification; rejecting requires a reason. A fix that passes the check is recorded as a fix, a different event from an override.
What was checked is what runs
Recipes compile one way
The recipe is the source. It compiles into the graph that runs, one gate per phase, and the blocks travel with the run, so the record shows exactly what was approved.
Claims kept narrow
What it is not
Not an MES: it schedules nothing and tracks no inventory. Not validated. Compliance with Part 11, Annex 11 or GAMP 5 is a site's to establish after validation; Agentic Loom makes no such claim.
The agentic approach: agents propose, a model admits, people decide
Agents and assistants are useful for drafting recipes, proposing parameters and running routine steps. In a regulated plant they need what people need: to know, before acting, what is permitted, and to leave a record when the answer is no.
The same gates for agents and people
An agent connected over the Model Context Protocol can start a run and answer a gate, but only through the same checks a person faces: an acceptance still needs a justification, and is still refused where the model does not permit it.
A model of the plant, asked every time
Admission comes from the units' declarations, not from what an agent believes about them. A phase passes because the check passed, or because a named person took responsibility for it. There is no third way through.
What has been measured
Each result below comes from a run with its setup stated beside it. None of them comes from real equipment.
In the recipe editor, each phase's live verdict matched the decision its gate made when the recipe ran.
One recipe on demonstration descriptors, local build, October 2026.
At a refused step the run paused and the operator was offered only the dispositions the model permits for that refusal; a decision that was not permitted was refused and recorded, never applied. An unanswered check could be asked again or stopped, never accepted.
Gate tests with scripted answers, plus the end-to-end run in the demo.
At the equipment, an admission gate on a real OPC UA server refused every disallowed call, none of the refused work ran, and the gate took 49.5 µs per call.
Median of 30 replicates; real OPC UA server, simulated units.
Built so far
A desktop recipe designer and runner with live checks, gates and a batch record kept in Git; an admission service; an equipment-side gate for OPC UA. Agents connect over the Model Context Protocol.
What we do not claim
It has not run on real equipment or at a real site. Contention and lot history are shown to the author but not yet enforced at run time. Without a model of how each step changes a unit's state, most later steps in a run pause today and need a person.
Talk to us
Interested in trying Agentic Loom on your own unit declarations, or in embedding an admission layer in your batch tooling? Get in touch.
Who is behind it
Agentic Loom is built by Alexander Chernov, whose work is on governed AI systems: deciding, with evidence, what an automated system may do.
About the name
A loom weaves many threads into one cloth by a fixed pattern. A batch record is woven the same way, from equipment, materials, steps and decisions, and Agentic Loom keeps every thread of it accounted for.