Agentic Scheduling: Adaptive shop floor planning on the UNS

The moment a CNC spindle faults at 2:14am on a Thursday, your carefully optimized production schedule is wrong. The question is how long it stays wrong. In most manufacturing environments, the answer is measured in hours: a shift supervisor notices the gap, calls a planning meeting, manually reshuffles jobs across available work centers and pushes an updated schedule to the MES. By the time the new plan reaches the floor, downstream stations have already been idle, WIP buffers have backed up and the on-time delivery metrics for three customer orders have quietly degraded.

Agentic scheduling eliminates that latency. An AI agent, consuming the same real-time MQTT event stream that reported the spindle fault, evaluates every active work order, checks equipment and operator constraints, proposes a replanned schedule and surfaces it to the shift lead for confirmation, all within seconds of the disruption event. 

Why do batch-driven MES and APS scheduling break on the shop floor?

Traditional shop-floor scheduling operates on a planning-then-execution model inherited from MRP II. A planning engine (typically inside the MES or an APS module) generates an optimized schedule based on a snapshot of current state: machine availability, labor assignments, material availability, order priorities. That schedule is then treated as the plan of record until the next planning cycle, which might run every shift, every 4 hours, or in some plants, once per day.

The failure mode is obvious to anyone who has spent time on a production floor. The snapshot is stale the moment it is taken. Between planning cycles, machines fault, operators call in sick, material deliveries arrive late, rush orders appear and quality holds pull WIP out of the flow. Each disruption widens the gap between the schedule and reality. Supervisors compensate with tribal knowledge and ad hoc adjustments that never flow back into the planning system.

The core engineering problem is architectural, not algorithmic. Better optimization algorithms do not help when the input data is hours old and the output is a static artifact. What is needed is an event-driven scheduling architecture where the schedule is a continuously maintained state that reacts to every relevant change on the floor.

This is precisely where the Unified Namespace pattern, implemented on MQTT, changes the equation. Instead of periodic state snapshots, every relevant event (machine status change, job completion, quality hold, operator badge-in) publishes to a structured topic hierarchy in real time. The schedule becomes a downstream consumer of that event stream, not a periodic batch process. For the full architecture of getting shop-floor events into that structure, read our blog Establishing Real-Time Data Flow for Agentic AI Through Streaming and Unified Namespace.

What does real-time schedule context look like on the UNS?

Building an agentic scheduling system starts with the data layer. The agent cannot reason about what it cannot observe. The UNS must surface, at minimum, five categories of real-time context:

Equipment state

Every work center publishes its current operational state to the UNS. On HiveMQ Broker, this typically maps to topics structured along ISA-95 lines (though adapted for your plant's actual hierarchy):

Payloads carry structured JSON with fields like operationalState (RUNNING, IDLE, FAULTED, MAINTENANCE), currentJobId, estimatedCompletionTime, and cycleTimeActual. The key engineering requirement is that these events publish on state change, not on a polling interval. HiveMQ Broker's retained messages ensure that any new subscriber (including a freshly started agent) immediately receives the last known state for every work center.

Work order queue

Active work orders, their priorities, due dates, routing sequences, and current status live in the UNS as well. A typical structure:

The routing payload defines the sequence of operations, required equipment types, estimated cycle times per operation and any prerequisite operations. This is the data an agent uses to understand which jobs can be rescheduled to which machines.

Operator and labor context

Operator availability, certifications, and current assignments publish to the namespace. This matters because many operations require certified operators; rescheduling a job to an available machine is useless if no qualified operator is on shift.

Material and WIP position

Buffer levels, material availability at each station and in-transit WIP positions provide the physical constraints. An agent cannot schedule a job on a machine if the required raw material or upstream WIP has not arrived at that station.

Quality holds and process constraints

Quality events (hold notices, SPC violations, inspection results) feed into the namespace so the agent knows which lots are available for processing and which are quarantined.

The critical point for data engineers: All five categories must share a common time reference and be governed by consistent schemas. This is where HiveMQ's data intelligence capabilities  become essential. HiveMQ’s Semantic Graph maps the relationships between equipment, work orders, operators and materials into a queryable knowledge graph. Without that semantic layer, the agent is working with disconnected event streams and must hard-code every relationship, a brittle approach that breaks the moment your plant layout or routing logic changes. 

For a deeper look at how that semantic layer gets built, read our blog Enabling Contextual Intelligence for Agentic AI in Industrial Operations.

How does an agent's replanning logic actually work?

With real-time context flowing through the UNS and semantic relationships modeled in the Semantic Graph, the scheduling agent operates on a continuous ‘sense-evaluate-propose’ loop. 

Here is the engineering pattern:

Sense: Event-driven trigger

The agent subscribes to a filtered set of UNS topics. Not every event triggers replanning. The agent's subscription filter targets state changes that invalidate the current schedule:

• Equipment fault events (operationalState transitions to FAULTED or MAINTENANCE)

• Job completion events that free up downstream capacity earlier or later than expected

• New work order arrivals with priority flags

• Operator availability changes (badge-out, break, reassignment)

• Quality hold events that remove WIP from the schedulable pool

HiveMQ Broker's shared subscriptions enable horizontal scaling: multiple agent instances can share the event load across a consumer group, ensuring replanning throughput keeps pace with event volume even in high-density plants generating 50,000+ events per minute.

Evaluate: Constraint satisfaction

When a trigger event fires, the agent pulls the current state of all relevant entities from the Semantic Graph. This is where the distinction between raw MQTT events and semantically modeled data matters most. The agent needs to answer questions like:

• "Which machines are capable of running operation 30 for work order WO-0042?" (requires equipment capability metadata)

• "Which of those machines are currently idle or will complete their current job within the next 20 minutes?" (requires real-time state + estimated completion)

• "Which certified operators are available for those machines on the current shift?" (requires operator certification and shift assignment data)

• "Does moving WO-0042 to CNC-03 violate any due-date constraints on the jobs currently queued for CNC-03?" (requires full queue state and priority rules)

The evaluation logic is a constraint satisfaction problem (CSP). For most shop-floor scheduling scenarios, the solution space is bounded enough that a well-structured CSP solver (or even a priority-weighted heuristic) runs in under 500 milliseconds. You do not need a large language model for this; you need a well-defined constraint model operating on high-quality, semantically rich data. The LLM's role, if any, is in the natural-language interface layer where operators interact with the agent, not in the core optimization.

Propose: Candidate schedule generation

The agent generates one or more candidate reschedules, each annotated with:

• Impact summary: which work orders move, to which machines, with what effect on estimated completion times

• Constraint violations: any soft constraints that the candidate relaxes (e.g., "WO-0055 moves from preferred machine CNC-01 to alternate CNC-03, adding 12 minutes estimated cycle time")

• Confidence score: based on data quality, completeness of constraint evaluation, and historical accuracy of similar replanning events

• Rollback plan: what happens if the proposed schedule itself encounters a disruption within the next planning horizon

The candidates publish back to the UNS on a dedicated scheduling namespace:

This is a critical architectural choice. The proposal is data on the namespace, not a side-channel message. Any system, including dashboards, MES integrations or other agents, can observe and react to scheduling proposals.

What constraints and guardrails prevent unsafe autonomous rescheduling?

Autonomous replanning in a production environment demands rigorous guardrails. An agent that reschedules without constraints is more dangerous than no agent at all. The guardrail architecture operates at three levels:

Hard constraints (never violated)

These are encoded in the ontology within the Semantic Graph and enforced programmatically:

• Safety interlocks: The agent cannot schedule a job on equipment that is in a safety lockout state, period

• Regulatory holds: Jobs under FDA hold, export control, or customer-mandated inspection cannot be rescheduled without explicit quality release

• Certification requirements: Operations requiring specific operator certifications cannot be assigned to uncertified personnel

• Physical impossibility: The agent cannot schedule a 5-axis operation on a 3-axis machine, even if the 3-axis machine is idle

Hard constraints are non-negotiable. The agent's CSP solver treats them as absolute boundaries on the solution space.

Soft constraints (relaxed with justification)

These are preferences that the agent can relax when hard constraints make the optimal solution infeasible:

• Preferred machine assignments: Certain jobs run more efficiently on specific machines, but alternates exist

• Batch sequencing preferences: Color-first or material-first sequencing reduces changeover time but is not mandatory

• Buffer level targets: The agent prefers to maintain minimum WIP buffers at each station but can draw them down in recovery scenarios

When the agent relaxes a soft constraint, the proposal explicitly flags the relaxation and quantifies the impact. This transparency is what makes operator confirmation meaningful rather than rubber-stamp approval.

Operational boundaries (system-level limits)

These are meta-constraints on the agent itself:

• Scope limits: The agent can only reschedule within its assigned area or line. Cross-area rescheduling requires escalation to a higher-level orchestration agent

• Rate limits: The agent cannot propose more than N reschedules per hour, preventing oscillation in unstable conditions

• Confidence thresholds: Proposals below a minimum confidence score are flagged for mandatory human review rather than presented as recommendations

• Rollback windows: Every accepted schedule change includes a defined rollback window during which the previous schedule can be restored

HiveMQ's Data Hub enforces schema validation on all proposal payloads, ensuring that no malformed or incomplete proposal can reach the operator confirmation step. This is defense-in-depth: even if the agent logic has a bug, the data governance layer catches structurally invalid outputs.

Read our blog Establishing Governance Frameworks for Agentic AI in Industrial Operations and Securing Agent Access to the UNS Guardrails for Autonomous Actions to learn more.

How does operator or human-in-the-loop confirmation work in practice?

Trusted delegation means the agent proposes; the human decides. The confirmation workflow is engineered to be fast, informative and low-friction:

1. Agent publishes proposal to the scheduling namespace on the UNS with full impact analysis, constraint annotations, and confidence score

1. Dashboard renders the proposal on the shift lead's HMI or tablet, showing a visual diff between current and proposed schedules. Key metrics are highlighted: orders at risk, machines affected, estimated recovery time

1. Operator reviews and acts: three options surface as simple controls:

• Accept: The proposal becomes the active schedule. The agent publishes the accepted schedule to the authoritative scheduling topic, and downstream systems (MES, SCADA displays, operator work queues) consume the update

• Modify: The operator adjusts the proposal (e.g., swaps two machine assignments) and accepts the modified version. The modification publishes as a new event, feeding the agent's learning loop

• Reject: The operator rejects the proposal with an optional reason code. The agent logs the rejection and incorporates the feedback into future constraint weighting

1. Timeout handling: If no operator action occurs within a configurable window (typically 3-5 minutes for critical disruptions), the system escalates - either to a secondary operator, a plant manager, or in pre-approved low-risk scenarios, auto-accepts the proposal

The entire confirmation loop runs through the UNS. There is no separate approval system, no email chain, no phone call. The MQTT event stream carries the proposal, the confirmation and the resulting schedule change as first-class events that every system on the namespace can observe.

For data engineers building this pattern: The confirmation step is where you capture the highest-value training data. Every accept, modify, and reject, annotated with the production context at the time of the decision, becomes a labeled example for improving the agent's constraint model over time. 

What data architecture supports agentic scheduling at scale?

The full architecture stacks three layers:

For a mid-size discrete manufacturing plant (20-50 work centers, 200-500 active work orders), the system handles approximately 10,000-50,000 MQTT messages per minute across equipment state, WIP tracking, and scheduling events. HiveMQ Broker's clustering handles this with significant headroom; production deployments at much larger scale (millions of messages per second) are well documented.

Edge considerations matter for multi-plant deployments. HiveMQ Edge handles protocol translation at the plant level (OPC UA from PLCs, Modbus from older equipment), bridging into the plant-level broker. Cross-plant scheduling requires broker bridging between sites, with each plant's scheduling agent operating independently but sharing capacity data through a federated UNS topic structure. Read our blog Establishing Multi-Agent Frameworks for Coordinated Industrial Intelligence to learn more.

Conclusion

Agentic scheduling on the UNS is not a future concept; it is an engineering pattern you can implement on HiveMQ's platform today. The foundation is a well-governed, semantically rich, event-driven data layer that gives agents the real-time context and constraint knowledge they need to reason effectively. The guardrails, from hard safety constraints to operator confirmation workflows, ensure that autonomous replanning earns trust incrementally rather than demanding it upfront.

The organizations capturing the most value from this pattern are the ones that start with the data layer: get equipment state, work orders, and operator context flowing through the UNS on HiveMQ Broker, model the relationships in HiveMQ Pulse's Semantic Graph, and then layer in agent logic once the data foundation is solid. Attempting to build the agent first and backfill the data layer later is the most common failure pattern we observe.

Ready to architect agentic scheduling for your production environment? Schedule a consultation with HiveMQ's industrial solutions team to assess your data readiness and define a phased implementation plan.