Manufacturing Floor Agents: Real-Time Constraints And The Pact Of "Stop The Line"
An agent on a manufacturing floor has under one hundred milliseconds to decide and the authority to halt production. The pact has to enforce both at runtime, and the recovery has to be drilled.
Continue the reading path
Topic hub
Agent TrustThis page is routed through Armalo's metadata-defined agent trust hub rather than a loose category bucket.
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
TL;DR
An agent on a manufacturing floor has two properties that no other agent type combines: it operates under real-time constraints (decisions in tens to low hundreds of milliseconds), and it has the authority to halt production. The combination is what makes it valuable and what makes it dangerous. A pact that does not name both — the latency budget and the halt authority — is a pact that the agent will violate the first time it has to choose between speed and safety. This essay walks the floor-agent architecture, the stop-the-line pact pattern, the recovery procedure that must be drilled before deployment, and the operator playbook for the first deployments.
What "stop the line" means and why it is non-negotiable
Toyota's manufacturing system formalized the principle: any worker on the line, when they detect a defect that should not propagate, has the authority and the duty to stop the line. The economic cost of stopping is real (every minute of downtime is dollars). The economic cost of not stopping is much higher: defects that propagate downstream become customer-visible defects, recalls, warranty claims, and brand damage. The math says: stop early, fix the problem, restart with the defect contained.
The principle worked because the line workers had three things: real-time perception of the production process, the explicit authority to halt without asking permission, and the institutional support that made stopping the line a celebrated act rather than a punished one. A worker who feared being blamed for a halt would hesitate; the hesitation costs more than the halt.
A floor agent inherits all three requirements. It needs perception (sensor inputs from the line). It needs explicit halt authority (the ability to actually stop production, not just to alert a human). It needs institutional support (an escalation procedure that does not punish the agent for halts that turn out to be cautious). All three have to be in the pact.
The latency budget
Floor decisions happen fast. A defect detection that takes two seconds to surface is a defect that has already propagated through the next two stations. A safety event that requires a one-second response is a safety event that injures a worker if the response takes three seconds. The agent's latency budget is set by the physics of the line, not by the agent's preferences.
Typical budgets. A vision-based defect detection at a high-speed assembly station: 50-100 milliseconds from frame capture to halt signal. A weld-quality decision: 100-300 milliseconds. A safety-related response (worker proximity to hazard): 30-100 milliseconds for the perception, with conservative defaults that halt-on-uncertainty. A material-feed adjustment: low single seconds for routine adjustments, sub-second for exception conditions.
The pact's latency clause names the budget for each decision class. The runtime enforces by configuring the agent's compute, model, and tool stack to meet the budget. An agent operating outside its budget is an agent that will miss decisions; the pact's runtime monitor halts the agent itself if its 99th-percentile latency exceeds the budget.
This is harder than it sounds. LLM-based agents typically have variable latency, and the variance is high enough to blow the budget. Floor agents that need millisecond response times use models small enough to run within the budget on local hardware, with cloud escalation only for non-time-critical decisions. The architecture compromise — smaller models for speed, larger models for harder calls — is built into the pact.
The stop-the-line pact pattern
The pact has to make halt authority explicit and unconditional within its scope.
Subject: the agent's identity, the line section it operates on, the operator entity responsible for the agent.
Predicate: the agent is authorized to halt production within its line section under the following conditions, and only under the following conditions. Each halt-trigger condition is named: defect detection above the named threshold, safety event detection, sensor-input loss, capability-uncertainty above the named threshold. Halt triggers outside this list require human escalation.
Evidence: every halt produces a halt event with the trigger condition, the sensor data that supported it, the agent's confidence, and the timestamp. The halt event is logged to the floor's authoritative event store, not just the agent's local state.
Penalty: false halts (halts that turn out to be unjustified) damage the agent's reputation in the false-halt-rate dimension; missed halts (production-quality defects that should have triggered a halt and didn't) damage in the missed-halt dimension. Both are tracked. Bond slashing applies to systematic patterns, not to individual events.
Renewal: the pact renews quarterly with a calibration review. The review reads the false-halt and missed-halt rates and adjusts the trigger thresholds if needed.
Notably absent: any clause that lets a manager override the agent's halt decision in real time. The pact preserves the agent's halt authority during the halt; resumption requires the documented restart procedure, not a manager's override. This is the same discipline a human line worker has. Overriding the halt without addressing the underlying condition is exactly the failure pattern stop-the-line is designed to prevent.
The recovery procedure
A halted line is not the failure mode; an unrecoverable halted line is. The pact has to include a recovery procedure that gets the line restarted with the underlying condition addressed.
The procedure has five steps.
First, halt confirmation. The halt event is acknowledged by the line supervisor. Acknowledgment includes the supervisor's identity and timestamp.
Second, condition assessment. The supervisor reviews the halt event, the sensor data, and any physical evidence on the line. The agent's reasoning trace is available for the assessment.
Third, root cause categorization. The condition is categorized: real defect (the agent was right, contain and fix), false positive (the agent was wrong, retrain or recalibrate), edge case (the agent's confidence was appropriately low, document for review).
Fourth, corrective action. Real defects get the standard production response (contain, fix, document for the production retrospective). False positives get the agent's calibration adjustment scheduled. Edge cases get added to the agent's training distribution.
Fifth, restart with documentation. The line restarts with the corrective action complete. The full halt-and-restart event is logged to the production record.
The procedure must be drilled before deployment, not after the first incident. A floor team that has practiced the procedure twice resolves a real halt in minutes; a floor team that has only read about it takes hours and produces panicked decisions.
The operator playbook for first deployments
Floor agent deployment has a sequence that prevents the bad failure modes.
Phase one: shadow mode. The agent operates alongside the human inspectors but has no halt authority. Its halt recommendations are logged for analysis. Run for one to three months. The goal is to build the false-halt and missed-halt baseline, calibrate the trigger thresholds, and validate the latency budget under realistic conditions.
Phase two: advisory authority with human halt. The agent can flag halts for the human inspector to authorize. The inspector retains halt authority but the agent does the perception. Run for one to three months. The goal is to validate the agent-human handoff and confirm that the agent's recommendations are useful enough to follow.
Phase three: bounded halt authority. The agent can halt under a narrow set of conditions (e.g., safety events) without human authorization but escalates other conditions. Run for three to six months. The goal is to validate the agent's halt decisions under live authority for the most clear-cut cases.
Phase four: full pact-bound halt authority. The agent has halt authority under the conditions named in the pact. Calibration reviews happen quarterly. The goal is steady-state operation with the agent as a reliable line worker.
The sequence prevents the worst outcome: shipping an agent with halt authority before its decision quality has been validated. Operators who skip phases will eventually ship a low-quality halt that erodes the institutional support for stop-the-line, and that erosion takes years to repair.
The reputation surface for floor agents
Floor agents have a reputation surface that maps directly to their function.
False-halt rate. Lower is better. Excessive false halts erode the human team's trust in the agent and tempt overrides; the agent's bond and reputation are damaged for false-halt patterns.
Missed-halt rate. Lower is better. Missed halts produce defective product that reaches customers; the bond is damaged for missed-halt patterns.
Latency p99. The agent's 99th-percentile decision latency must remain within the pact's budget. Drift above the budget is itself a halt-trigger for the agent's runtime.
Uptime. Floor agents that go offline force the line to revert to human-only operation, which costs throughput. Uptime targets are typically 99.5% or better.
Calibration freshness. The agent's last calibration review timestamp; agents that drift past their renewal window get marked.
These five dimensions feed the agent's composite score within the floor-agent capability class. Buyers (manufacturers evaluating which agent platform to adopt) read the score class and pick agents whose dimensions match their priorities.
The named artifact: the Floor Agent Halt-Authority Pact
A pact template designed for floor deployments, with sections for each halt-related requirement.
Identification. Agent identity, operator entity, line section, supervising plant manager.
Latency budget. Per-decision-class budget with measurement procedure.
Halt triggers. Named conditions under which the agent has halt authority. Each condition includes the trigger threshold, the supporting sensor inputs, and the confidence level required.
Evidence. Per-halt event schema. Authoritative event store. Retention period.
Recovery procedure. The five-step procedure with named owners and timelines.
Reputation dimensions. The five dimensions tracked for this agent. Calibration cadence.
Dispute path. Halt disputes (typically internal to the operator) and pact violation disputes (under the platform's governance).
A floor operator who ships an agent without filling out this template is shipping an agent that will eventually halt the line in a way nobody can recover.
Counter-argument: "Plants will refuse to give software halt authority"
The strongest objection is institutional: plants have spent decades training humans to be the only entities with halt authority, and they will refuse to share it with software. Pact templates do not change this culture.
The objection is right that adoption will be slow. It is wrong about the equilibrium. Plants that figure out how to share halt authority responsibly will catch defects faster, reduce missed halts, and improve overall quality. The plants that adopt with discipline will outproduce plants that do not. Within five to ten years, the question will not be whether to give floor agents halt authority but how to make them trustworthy enough to deserve it. The pact pattern is the answer.
What Armalo does
The Armalo registry supports floor-agent pact templates that include latency budgets, halt-trigger predicates, evidence schemas, and recovery procedures. The runtime enforces latency budgets through compute and model configuration; halt events flow to the floor's authoritative event store with attestation; reputation tracks the floor-specific dimensions. The platform supports the four-phase deployment sequence with separate pact configurations per phase. Operators bring the line, the sensors, and the supervising team; the platform brings the trust and accountability infrastructure that lets halt authority be shared with software safely.
FAQ
Can the agent override the human supervisor in any case? The pact may include narrow safety predicates where the agent's halt authority is unconditional (e.g., immediate worker safety). Outside those, the supervisor's restart authority controls.
What about shifts where the supervisor is unavailable? The pact names backup supervisors and an emergency procedure. An unsupervised shift with no backup is a configuration error that the platform refuses.
How does the agent handle sensor failure? Sensor input loss is a named halt trigger. The agent halts on sensor failure rather than operating blind.
Can multiple floor agents share the same pact template? Yes; per-line-section pacts share a template with section-specific configuration.
What happens if the agent's reputation drops below the operator's threshold mid-shift? The pact's runtime monitor degrades the agent's authority — typically reverting from full pact-bound authority back to advisory mode — and pages the operator. The line continues with human halt authority.
Will floor agents replace human inspectors? Some, in mature deployments. Most deployments will have agents and humans working together, with agents handling high-frequency low-complexity decisions and humans handling judgment calls.
What about cyber-physical attacks on the agent? The platform's zero-trust runtime applies. The sensor inputs the agent reads are themselves attested where possible (signed sensor data, hardware-attested clocks), and the platform's audit side-channel records every halt and restart event independently of the agent.
Bottom line
Floor agents need three things together: real-time perception, explicit halt authority, and institutional support that makes halts safe to call. The pact pattern names all three and enforces them at runtime. The deployment sequence — shadow, advisory, bounded, full — protects against the bad failure mode of authority before validation. The recovery procedure is the load-bearing piece; it must be drilled before the first live halt. Operators who do this work will have software line workers who outperform their human equivalents within a small number of years; operators who skip it will produce the incidents that set the field back.
The Trust Score Readiness Checklist
A 30-point checklist for getting an agent from prototype to a defensible trust score. No fluff.
- 12-dimension scoring readiness — what you need before evals run
- Common reasons agents score under 70 (and how to fix them)
- A reusable pact template you can fork
- Pre-launch audit sheet you can hand to your security team
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Put the trust layer to work
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Comments
Loading comments…