Portfolio · Project 15

Alexander CHERNOV

Principal Engineer · Agentic AI & scientific data systems

← the whole portfolio
15

Agentic Loom: governed batch recipes in which every step is admitted before it runs

2026 – present · Independent work, unaffiliated with any employer.

A batch recipe usually runs on the strength of its approval. Here each step asks first, and a refused step goes to a person, on the record.

A recipe designer and runner for regulated batch processes. Recipes are built from what each unit of equipment declares, every phase is checked by an admission model while it is written and again at its gate, and a refused step waits for a person who may choose only what the model permits.

The demo as recorded: 4 minutes 22 seconds of a local build on demonstration descriptors, captions on screen and no sound. A recipe built from one unit’s declarations and checked live, phase by phase (1 admitted, 3 will pause on the unit’s recorded state); its plan followed through the unit’s PackML states; the recipe compiled one way into a graph with one gate per phase; a refused step where the panel offers exactly accept as is, rework or reject; the run’s batch record with its 9 decision entries; then the same recipe planned against another recipe that holds the unit, and against a lot history that carries an excluded material. Every number in a caption was read off the page as it was recorded. The file is the one archived on Zenodo.

Agentic Loom treats a recipe as a sequence of phases on units of equipment, written in the ISA-88 hierarchy of procedure, unit procedure, operation and phase, and lets no phase run on the strength of the recipe alone. The editor’s palette comes from the units’ own descriptors, one block per declared action with each parameter’s limit beside it, so a recipe cannot ask a unit for an action it never declared. As the author types, each phase shows the answer its gate will give at run time: admitted, will pause, or undecided. Where the declarations cannot tell, the editor says so instead of guessing, and an assumption the author makes is marked as one and never used by a run. The recipe then compiles one way into the graph that runs, one gate per phase, and the master recipe is fixed by its hash before it runs.

At run time a refused step pauses the run. The operator sees why and is offered only the dispositions the admission model allows for that refusal: accept as is with a justification, rework and ask again, or reject with a reason. A refusal that reports missing evidence cannot be waived, because signing it off would turn “we cannot tell” into “it is fine”, and a check that does not answer in time leaves the step undecided, never accepted. The screen offers only what is permitted, and the server checks every decision again before it takes effect. Each decision stays in the batch record under its own name (blocked, reworked, accepted as is, rejected, upheld); a fix that passes the check is a different event from an override, and the refusal remains whatever was decided.

Agents get the same gates. An agent connected over the Model Context Protocol can start a run and answer a gate, but only through the checks a person faces: an acceptance still needs a justification, and is still refused where the model does not allow it. Each unit’s descriptor is an Agentic Datasets declaration carrying its place in the ISA-88 model, its PackML state model and the command each action issues in each state, so the plan check follows a recipe to its end. While a recipe is planned, Agentic Loom also shows when another recipe holds the same unit over an overlapping window, and when a lot’s history carries a material the procedure excludes; these are findings for the author, and a gate at run time asks only about its own step.

agenticloom.ca gives each standard its status: ISA-88 recipes and PackML states built, the OPC UA gate measured, batch records in Agentic Loom’s own format, ISA-95 exports and MTP planned. In the recipe editor, each phase’s live verdict matched the decision its gate made when the demonstration recipe ran. At the equipment, an admission gate inside a real OPC UA server checked each call against the unit’s live PackML state: 90 of 90 disallowed calls were refused, none of the refused work ran, and the gate took 49.5 µs per call (median of 30 replicates, simulated units). The recipe runner does not connect to OPC UA yet, every result comes from demonstration descriptors rather than a plant, and compliance with Part 11, Annex 11 or GAMP 5 is a site’s to establish after validation.

Transferable principle: let agents and people propose, let a model of the plant admit each step, and make every exception a person’s decision, kept with its reason.

References

  1. IEC (1997). IEC 61512-1: Batch control — Part 1: Models and terminology (ISA-88). International standard. webstore.iec.ch
  2. ISA (2022). ISA-TR88.00.02-2022, Machine and Unit States: An implementation example of ISA-88.00.01 (PackML). Technical report. isa.org
  3. IEC (2025). IEC 62541-1: OPC Unified Architecture — Part 1: Overview and concepts. International standard, edition 1.0. webstore.iec.ch
  4. Chernov (2026). Brain API: An Intent-Aware Control Plane for Policy-Governed Agentic Systems. arXiv preprint. arXiv:2609.21299