Each Doughex agent owns one stage of the bakery line, a bounded tool set and a measured outcome. The orchestrator plans the run, arbitrates for shared actuators and routes anything above the threshold to a person. Five agents ship as products; the rest arrive with the Plant tier.
Illustrative scenario: Plant run · one bread line, flour-lot change at the silo · shared oven. Not a measured run.
Each agent owns a stage of the bakery line, a bounded tool set and a measured outcome. They negotiate for shared actuators through the orchestrator, never directly. Five ship as products; the rest arrive with the Plant tier.
Ingredient dosing, mixing, dough development
Controls hydration, mix energy, dough temperature and development time against the flour lot in the silo and the ambient conditions on the floor, so the dough that leaves the mixer is consistent instead of over- or under-mixed.
Design scope: consistent dough development, flour-lot drift compensated
Ships in: Plant tier
Fermentation, proofing time, temperature, humidity, rise
Fuses inline dough temperature, humidity, height and CO2 signals with recipe and flour-lot context, predicts the rise curve for the batch in front of it, and holds proofer temperature, humidity and dwell so rise, volume and structure land on target rather than on a fixed clock.
Design scope: target rise every batch, no baker at the panel
Ships in: Proofa
Makeup, forming, sheeting, depositing, weight
Fuses checkweigher readings with dough state and depositor feedback, predicts the portion weight for the dough flowing now, and trims depositor and divider setpoints in real time to hold target weight at the minimum safe margin without going underweight.
Design scope: giveaway toward zero, underweight guardrail held
Ships in: Gramex
Oven zones, profile, colour, bake, moisture, cooling
Senses surface colour, product profile and inline moisture, predicts the as-baked outcome for the product entering the oven, and tunes zone temperatures, airflow, humidity and band speed to land colour, bake and moisture at the minimum energy per unit. Coordinates cooling to protect texture and shelf life.
Design scope: colour and moisture to spec at minimum energy
Ships in: Ovenix
Colour, bake, shape, holes, foreign bodies, seal and fill faults
Runs multi-camera vision and inline sensing at the plant edge to detect colour and bake faults, misshapes, holes, cracks, blistering, foreign bodies and seal or fill failures at line rate, rejects the unit and attributes each defect back to the upstream agent that caused it.
Design target: sub-100 ms reject decisions at 10 to 60 FPS per station
Ships in: Vizra
Weight, moisture, texture and shelf-life optimisation
Predicts shelf life and finished-product quality from moisture, bake state, cooling curve and weight, and proposes the recipe and profile moves that protect both before the product is packed.
Design scope: quality and shelf life predicted before packing
Ships in: Plant tier
Yield, waste, giveaway, energy and line balancing
Prices every candidate move in grams of giveaway, kilograms of waste and kilowatt-hours of oven energy, sequences products and changeovers, and balances the moving line so takt is met without starving the oven or flooding the cooler.
Design scope: yield up, waste, giveaway and energy down
Ships in: Plant tier
Pan, tray, product and packaging handling
Drives robotic pan loading and unloading, tray transfers, rejected-product diversion and packaging handling, with perception and motion policies built in simulation before they touch a pan on the line.
Design scope: handling paced to the line, safe zones monitored
Ships in: Plant tier
Right-first-time, non-conformance, lot genealogy, food-safety traceability
Builds the lot genealogy record from flour lot, recipe, mix, proof, deposit, oven and inspection events and every human decision, gates release against product spec and the plant's food-safety procedures, and blocks any action the HACCP plan does not allow.
Design scope: complete, immutable release records
Ships in: Plant tier
Planning, arbitration, human approval, twin rehearsal, bakery knowledge
Plans the run, rehearses high-impact moves on the Bakesim twin, arbitrates between agents that want the same actuator, enforces the autonomy level per loop and routes anything above the site threshold to a named person. Grounds its reasoning in the plant's recipes, proof and bake specs and food-safety procedures through cited retrieval.
Design rule: every write policy-checked, every output cited
Ships in: Bakesim
Every Doughex run is an ordered, inspectable sequence. This is run_scn_01, an illustrative scenario: Plant run · one bread line, flour-lot change at the silo · shared oven. Scenario complete · every stage inside spec · one human approval at the oven.
Plant Orchestrator · Pulled the product spec, the recipe, the HACCP plan with its bake kill-step and metal-detection control points, the allergen status of the line and the new flour lot's certificate from MES and the lab system; locked the target envelope for the run.
Plant Orchestrator · Simulated 24 candidate profiles across mix, proof, deposit and oven on the Bakesim as-baked twin for the new flour lot; ranked them on colour and moisture margin, weight margin, energy per unit and takt, and discarded every candidate that thinned the bake kill-step margin.
Dose-and-Mix · Adjusted hydration and mix energy for the new lot's absorption so dough temperature and development landed on target; dough state was handed to the proofer with its predicted rise curve.
Ferment-and-Proof · Predicted the rise curve from inline height, temperature, humidity and CO2, then trimmed proofer humidity and dwell so rise and volume landed on target instead of running fast on the fresher lot.
Makeup-and-Deposit · Fused checkweigher readings with dough state and divider feedback and trimmed the divider in real time so portion weight sat at the minimum safe margin above the declared weight, with the underweight guardrail armed.
Plant Orchestrator · The twin's lowest-energy candidate wanted a zone-three temperature outside the site's bounded envelope. Held for the shift process engineer, who approved the step with a tighter colour alarm.
Bake-and-Cool · Ran the oven against the twin's colour and moisture prediction; stepped zone temperatures and band speed toward the minimum-energy profile while predicted crust colour and crumb moisture stayed inside spec and the core-temperature kill step was verified on every reading.
Defect-and-Inspect · 12 camera streams at oven exit, cooler exit and packing at the plant edge: colour, shape, holes, cracks, foreign-body and seal checks on every unit; two pale-top rejects were attributed to a draught at zone one and the oven agent was notified.
Robot-and-Handling · Robotic depanning, tray transfers and packaging handling paced to the line, with rejected units diverted off the belt and the safe zone around each cell monitored.
Quality-and-Conformance · Lot released: flour lot, recipe, mix and proof setpoints, portion weights, oven profile, kill-step readings, inspection rejects and every human decision written to the genealogy and checked against spec and the HACCP plan.
Two agents will want the same actuator. The orchestrator arbitrates on the run goal, with food safety above everything, and the handoff is logged like any other step.
Yield-and-Takt wants a faster band through the oven so the line clears the proofer backlog and the packing hall is not left waiting.
Bake-and-Cool requires the band speed that keeps core temperature above the kill-step threshold for the full dwell. That is the HACCP critical control point.
Food safety outranks takt under every run goal. The critical control point wins the actuator; the request for more speed is logged with its score and the reason it lost.
Yield-and-Takt recovers the schedule by trimming proofer dwell on the next batch within its window and resequencing the changeover. Takt is met without touching the kill step.
Every tool invocation, argument and result is written to an immutable, human-readable log, and every reasoning step is expandable. Nothing about a run is hidden from the plant. The log below is the scenario run, not a measured one.
Goal, plan, thought, action, observation, exactly as the orchestrator would record it.
Start flour lot F-3312 on bread line BR-2, hold development, rise, weight, colour and moisture on target through the change, and release the lot with full genealogy.
Simulate the whole profile on the twin first. Lead with the mixer so the proofer gets dough with a known rise curve and the divider gets dough with a known density. Verify the bake kill step continuously. Let the oven chase minimum energy only inside the bounded envelope; hold anything beyond it for a person.
The standing recipe overshoots portion weight and runs the oven hot to protect against lot variability. With continuous dough-state, weight and colour estimates the margins can sit at their minimum safe values. The saving is giveaway and energy, not safety margin: the kill step is never a candidate for optimisation.
twin.simulate(candidates=24) → profile #7: minimum safe weight margin, kill-step margin unchanged, lowest predicted energy per unit.
Profile #7's zone-three temperature sits outside the site's bounded envelope. The policy engine routes that single write to the shift process engineer and permits the other eight.
Execute profile #7 at the bounded level: mixer, proofer and divider writes proceed; the zone-three write waits.
Approval granted at 05:53:09 with a tighter colour alarm. Two pale-top rejects at oven exit were attributed to a draught at zone one and corrected by the oven agent.
Scenario complete. The lot released with flour lot, setpoints, kill-step readings, inspection events and the human decision in the genealogy. No measured plant result is claimed; this is the run the platform is designed to execute.
An agent can only call the tools declared for it, and a write tool carries the tags, rate and magnitude limits it may touch. Critical control points appear only as read tools.
| Agent | Tools | Scope | Ships in |
|---|---|---|---|
| agent.dose_mix | plc.read_mixer, lot.read_flour, plc.write_setpoint(mixer.energy) | Read + guarded write | Plant tier |
| agent.ferment_proof | sense.read_rise, proofer.read_climate, plc.write_setpoint(proofer.dwell) | Read + guarded write | Proofa |
| agent.makeup_deposit | checkweigher.read, depositor.read_feedback, plc.write_setpoint(depositor.trim) | Read + guarded write | Gramex |
| agent.bake_cool | vision.read_colour, nir.read_moisture, plc.write_setpoint(oven.zone) | Read + guarded write | Ovenix |
| agent.defect_inspect | vision.stream(cams), reject.actuate, defect.attribute | Read + reject | Vizra |
| agent.quality_shelflife | shelf.predict, spec.check, recipe.propose | Read + propose | Plant tier |
| agent.yield_takt | cuopt.sequence, energy.budget, takt.balance | Read + guarded write | Plant tier |
| agent.robot_handling | isaac.perceive, robot.plan_motion, robot.execute(guarded) | Read + guarded write | Plant tier |
| agent.quality_conf | mes.release_lot, genealogy.write, audit.write | Read + propose | Plant tier |
| agent.orchestrator | plan.compose, policy.evaluate, approval.request, twin.simulate | Read + propose | Bakesim |
The rules every Doughex agent is held to before it is allowed near a line.
A bakery does not go from manual to bounded control in one step. Doughex makes the level explicit per loop, auditable and reversible at any time, and some decisions never leave the person.
| Level | What the agent does | What the person does | When |
|---|---|---|---|
| Observe | Predicts rise, weight, colour, moisture and defects; writes nothing | Runs the bakery as today; compares predictions to QA checks | First phase with every design partner |
| Recommend | Proposes mix, proof, deposit and oven moves with the evidence behind each | A process engineer or baker approves or corrects each one | After accuracy is proven against the baseline |
| Approve to apply | Prepares the write; applies it only on a named person's approval | Approves per move; reviews the shift record | Once recommendations are trusted |
| Bounded | Writes low-risk oven, depositing and inspection setpoints inside explicit limits | Approves anything above the limits; reviews exceptions | After the food-safety and ROI gates agreed up front |
| Exceptions | Escalates anything outside its envelope, CCP-adjacent moves and release decisions | Always decides these; the agent never does | Permanent |
Doughex is recruiting three to five design partners for the first cohort. These are the bakery types the products were designed around and where each would start.
Proofing and the oven at the highest volume in the industry. Starting wedge: Proofa or Ovenix, with Vizra at oven exit.
Depositing weight and bake colour decide margin. Starting wedge: Gramex on the depositor, Ovenix on the band oven.
Depositing to weight and baking to moisture on high-value product. Starting wedge: Gramex, with Vizra on decoration and packing.
Proof, sheeting and a fast, hot bake. Starting wedge: Proofa and Ovenix together.
Weight, diameter and bake colour at very high rate. Starting wedge: Gramex, with Vizra on shape and colour.
Continuous bake and moisture windows under food-safety mandates. Starting wedge: Ovenix, with Vizra for foreign bodies.
There is no SDK to download yet. What design partners get is the integration surface: connectors, an autonomy policy declared per loop, and an audit record for every reading, recommendation, write and approval. This is the shape of one record, illustrative.
// one write, as the audit log would hold it
{
"run": "run_scn_01",
"step": "deposit.trim",
"agent": "agent.makeup_deposit",
"level": "bounded",
"action": { "tool": "plc.write_setpoint", "tag": "DIV1.TRIM" },
"limits": { "max_step": "declared per tag", "per": "declared per tag" },
"evidence": ["checkweigher.read", "depositor.read_feedback"],
"citation": "spec:SANDWICH-800 declared weight v3 §2",
"policy": "permitted",
"models": { "weight": "versioned", "policy": "versioned" },
"human": null,
"outcome": "inside spec · minimum safe margin"
}The numbers Doughex is engineered against, from the GPU utilisation plan.
Design targets from the GPU utilisation plan. Nothing on this page is a measured plant result; measurements start when the first design-partner line runs in observe mode.
The three people in an industrial bakery whose week changes when the line runs itself, and what each of them needs from Doughex.
Owns production rate, quality, waste, giveaway and yield, energy and food safety. Wants a bakery that holds spec at higher rate with fewer interventions, and a number that justifies the spend.
Owns recipes, dough development, proof and oven profiles, process windows and yield. Approves and corrects the agents in recommend mode; those corrections train the models.
Owns HACCP, FSMA, BRCGS, ISO 22000 and allergen conformance, foreign-body and defect conformance, and lot genealogy. Needs every action grounded, cited and written to an immutable record.
IT/OT and sustainability leads approve the deployment. There are no customer quotes on this site yet; design partners will speak for themselves when they choose to.
Doughex reads and writes through the systems already on the floor. No parallel historian, no new HMI, no rip-and-replace. Connectors are built against each design partner's stack first; long-tail integrations are out of scope for the first release.
PLC and SCADA of mixers, proofers, dividers and depositors, ovens, coolers and slicers
Setpoint reads, guarded writes, interlocks untouched
Checkweighers, inline moisture and NIR, thermal cameras, dough height, temperature and humidity
Continuous product and process state
Metal detectors and X-ray systems
Read and verified; reject interlocks stay the plant's
Orders, recipes, product specs, lot genealogy, allergen status
Targets in, release records out
Multi-camera stations at oven exit, cooler exit, slicer and packaging
Frames, defect events, reject commands
Plant and oven-level gas and electricity meters
Hard constraints for the oven profile and schedule
Isaac-driven depanning, tray transfer and packaging cells
Perception and motion for pans, trays and packs
SSO and role-based access; SOC 2 on the roadmap
Named approvers, scoped roles
Doughex writes to production equipment in a food plant. Every capability is scoped, every write is policy-checked, every output is cited, and every action is written to an append-only audit log the plant owns.
| Item | Scope | Status |
|---|---|---|
| SOC 2 Type I | Cloud control plane | QUEUED Roadmap, first 6 months |
| SOC 2 Type II | Cloud control plane | QUEUED Roadmap, 6 to 12 months |
| HACCP · FSMA · BRCGS · ISO 22000 · allergen | Grounding and record-keeping | RUNNING Design basis for retrieval and the audit log |
| Per-tenant isolation | Data, memory, models | RUNNING Design rule |
| On-prem deployment | Recipe-sensitive bakeries | RUNNING Design option |
Doughex supports your food-safety records. It is not a certification and it does not replace your HACCP plan.
One policy model, one audit trail and one set of yield, waste, giveaway and energy benchmarks across every bakery in the group, with each site's recipes and tolerance models kept private to that site.
The questions plant directors, process engineers and quality managers ask in the first meeting.
Only at the autonomy level your plant has set, and only to an explicit allow-list of low-risk loops inside explicit limits. Every design partner starts in observe mode, where Doughex predicts and writes nothing. Recommend mode follows, where a process engineer approves each move. Bounded autonomy on oven, depositing and inspection loops comes after the food-safety and ROI gates agreed up front.
Critical control points are not optimisation variables. The bake kill step, metal detection and X-ray reject interlocks, allergen changeover and release decisions stay with your HACCP plan and your people. Doughex verifies readings, writes them to an immutable audit log and attaches them to the lot genealogy. It supports HACCP, FSMA, BRCGS, ISO 22000 and allergen records; it is not a certification and does not replace your plan.
Doughex sits above your existing automation as a supervisory layer. If it stops, the line keeps running on its current PLC and SCADA control and the interlocks it already has. A Doughex outage degrades the bakery to the way it runs today, not to a stop.
The first phase is observe mode on one line: Doughex reads your sensors, PLC history, QA checks and MES while you run the line as usual, and we measure its predictions against your own checkweigher, colour and moisture checks. Recommendations start when accuracy is proven against that baseline, and improve as plant-specific history and engineer corrections accumulate.
Recipes, product specs, tolerance models and customer specs are tenant-scoped and never used to train another customer's models. Retrieval is multi-tenant isolated and permission-aware. On-prem deployment is available for bakeries protecting sensitive recipes or private-label specs.
You are, the same as with any control strategy. That is why every write is policy-checked, bounded, logged and reversible, every output carries a citation to the recipe or procedure it relied on, and anything above your threshold waits for a named approver. The audit log records the request, the reasoning, the limits applied and the human decision.
As a design partner, on one line, with one hard metric: giveaway in grams per unit, energy per unit through the oven, downgrade and waste from under- or over-bake, or foreign-body and defect escapes. We instrument the line in observe mode, measure the baseline, move to recommend mode when accuracy is proven, and expand only when the number holds.
Full multi-module autonomy across the whole bakery, long-tail integrations beyond the design partners' stacks, and self-serve onboarding. The first release is one wedge workflow, its connectors, the agent loop with human checkpoints, the review console and the food-safety audit log.
Pick the stage that costs you the most: proofing, depositing, the oven or inspection. We start it in observe mode.
↑↓ navigate↵ openesc close