The name Stateful Robotics is not accidental. It reflects a specific technical position about what robot task orchestration needs to do to be useful in real warehouse operations. To explain what we mean by stateful, it helps to start with what stateless dispatch looks like and why it falls short.
What Stateless Dispatch Looks Like
A stateless dispatch system sends a command to a robot and considers that command complete once it is issued. The system may record that the command was sent and receive a completion acknowledgement from the robot when the task finishes. But between issuance and completion, the system holds no meaningful context about the task: where it sits in a larger sequence of work, what it depends on, what depends on it, or what partial progress has been made.
For a single robot completing a simple task with no dependencies, stateless dispatch is entirely sufficient. Send the command, wait for the acknowledgement, issue the next command. The simplicity is a genuine advantage when the operation is genuinely simple.
The problem surfaces as soon as the operation gets more complex. Consider a sequence of tasks that form a logical unit: pick from bay 3, transfer to staging, confirm inbound, assign to dock 7. In a stateless system, these are four independent commands. The system knows that command 1 was sent and completed. It knows command 2 was sent. It does not necessarily know that command 2 depends on command 1 having completed successfully, or that commands 3 and 4 are semantically part of the same work request as commands 1 and 2.
When something goes wrong mid-sequence, the stateless system has no framework for understanding what needs to be recovered. Someone has to manually reconstruct: what was completed, what was not, what the intended end state was, and what subset of remaining work needs to happen to reach that end state. In a small facility with a few robots and patient supervisors, this is manageable. In a fleet of 20 robots running concurrent operations, it is not.
What State the System Needs to Hold
Being stateful, in the context we care about, means holding enough information about running tasks that the system can reason about them, not just track them.
The minimal state the system needs for useful orchestration includes: the full task graph for each active ops request (tasks, dependencies, robot assignments, planned routes), the current execution status of each task (pending, in-progress, completed, failed), the history of what was completed before the current state, and the dependency chain between tasks so the system knows what work is unlocked by a completion and what work is blocked by a failure.
Task history is the part that most dispatch systems omit. Recording that a task completed is obvious and most systems do it. But the history that matters for replanning is richer than just completion timestamps. It includes: the robot that executed the task, the route taken, any sensor events that occurred during execution, and the resulting state change in the physical environment (pallet is now at staging, bay 3 is now empty).
This history is what allows the system to bound the scope of recovery when something goes wrong. If robot 07 fails mid-task on a 5-task ops request, the system needs to know: which of the 5 tasks had completed before the failure? Which tasks were in progress, and how far? The answers determine the minimum recovery path. Without the history, the default response is to restart the entire ops request, which wastes all the completed work and means the remaining work queue competes with tasks that are actually new.
The Replanning Use Case
The most direct application of stateful design is mid-run replanning when a lane is blocked.
When a lane block event fires, the system needs to answer: which active tasks have routes that pass through this lane? This question requires the system to know the planned routes of all active tasks, not just which robots are currently in motion. The routes are part of the task state.
Once the affected tasks are identified, the system needs to answer: what are the alternative routes for those tasks? This requires the same route-planning logic that was used at dispatch, applied to the current physical state of the facility (excluding the blocked lane). It also requires knowing where each affected robot currently is, because the alternative route starts from the robot's current position, not from its original start point.
Once alternative routes are computed, the system needs to issue updated commands to the affected robots and record the replan event in the task history. The task's state changes from "in-progress on original route" to "in-progress on replanned route, triggered by lane block at X." This updated state becomes the basis for any subsequent planning decisions for those tasks.
A stateless system cannot execute this sequence. It does not have the route state, it does not have the robot position context, and it has no mechanism for scoping the replan to only affected tasks. The default response is to halt everything and wait for a human to sort it out.
State Persistence and Recovery
Holding state in memory is straightforward. The harder question is what happens when the orchestration system restarts, either by design (a planned maintenance window) or unplanned (a server failure). If all task state is in memory and the process terminates, the state is lost and all in-flight tasks are orphaned.
For a production warehouse system, this is not acceptable. The state store needs to be durable: writes to task state need to be persisted before they are acknowledged, and the system needs to be able to reconstruct its runtime state from the persisted store on restart. This is a standard distributed systems requirement, but it has implications for how the state store is architected and what the write path looks like.
The tradeoff between write durability and write latency is real. Ensuring every state update is written to durable storage before acknowledging adds latency to every task transition. For a system with a replan latency target measured in hundreds of milliseconds, this write path has to be fast. Write-ahead logging with asynchronous flush is a common pattern, but the details depend heavily on the infrastructure the system is running on.
We are not going to specify the right persistence technology here, because the right answer depends on the deployment model and operational context. The point is that state persistence cannot be an afterthought. It is a first-class design requirement for any system that holds meaningful task state.
State Scope and Garbage Collection
A system that retains all state forever accumulates unbounded data. Completed ops requests from months ago are not useful for current replanning decisions but still consume storage and add query latency if they are in the hot data path.
The practical approach is to define a lifecycle for task state: active tasks in a hot store with fast query access, recently completed tasks in a warm store for short-term audit and debugging, historical tasks in cold storage or archived out of the orchestration system entirely. The transitions between these tiers can be time-based (archive ops requests older than 30 days) or event-based (archive when the ops request is fully confirmed by the WMS).
The boundary between active and historical state also matters for replanning logic. The replan engine should only look at active task state, not scan through historical completed tasks. Getting this boundary right avoids accidental contamination of replan decisions with stale data from previous operations.
What Stateful Design Does Not Guarantee
Stateful design improves the system's ability to respond to disruptions and recover from failures. It does not guarantee that every disruption will be resolved automatically or that every recovery will be perfect.
If a robot failure leaves a task in an ambiguous physical state (the pallet was picked up but it is unclear whether it was deposited at the intended location), the system knows the task failed but may not have ground truth about the physical outcome. Human intervention is still needed to verify the physical state before the task can be retried safely. The state the system holds is the state it can observe. Physical states it cannot observe are still uncertain.
Similarly, stateful design does not substitute for good operations practices. An orchestration system that holds rich task history is more useful to an operations team that actually reviews that history and uses it to improve their processes. The data is only as valuable as the team's ability to act on it.
The core claim is narrower and we think more honest: a system that holds rich task state can attempt reasoned responses to common disruptions rather than defaulting to halt-and-wait. Whether those responses are correct depends on the quality of the state and the quality of the replanning logic. The state is a prerequisite, not a guarantee.