A robot task begins as a sentence, but it cannot stay there.
“Move these parts to shipping” sounds clear until the robot has to decide which parts, from which rack, in what order, by what route, with what payload limit, around which people, and under what conditions it should stop. “Clean the room” sounds ordinary until the robot has to distinguish trash from a dropped toy, avoid cables, respect privacy, handle a blocked path, and decide whether a spill is inside its authority. The work is not only making the robot smarter. The work is making the task legible enough that intelligence has something stable to act on.
Task design is the discipline between a capability claim and a deployment. It turns a broad desire into a bounded job with a start state, an end state, allowed actions, forbidden actions, measured outcomes, and known exception paths. The articles on What Robots Can Actually Do and Robot Demo Evaluation ask readers to judge robots by the exact work they perform. Task design is how that exact work is written before the robot is asked to prove anything.
A Task Is Not A Wish
People often describe robot work by naming the human goal. Pick the order. Restock the shelf. Fold the laundry. Inspect the aisle. Fetch the tool. Those phrases are useful for conversation, but they hide the physical decisions that make or break the robot’s behavior.
A deployable task needs a smaller surface. It needs to say what object class is involved, where the object begins, where it should end, what variation is expected, how the robot knows the job has started, how it knows the job is finished, and what it must not do along the way. The difference between “pick boxes” and “move sealed cartons from the blue inbound tote to the right side of the packing bench when the tote is seated in the marked position” is not pedantry. The second statement gives perception, planning, safety, and human workflow something to share.
This does not mean every robot must be reduced to a rigid script. A useful physical AI system may still handle variation, interpret language, or choose among tactics. But flexible systems need boundaries more than simple systems do, because their failure modes are less obvious. A robot that can infer intent should also know when the request is outside the task it was built to perform.
Start States Matter
Many robot failures are born before the robot moves. The object is half outside the bin. The cart is at an odd angle. A door that should be open is closed. The docking station is blocked. A person has placed a tool where the robot expects empty space. A camera sees glare instead of a clean view. The robot may fail later during motion, but the real problem was that the task began from a state the team never defined.
A good start state is not an ideal photograph. It is a practical description of the conditions under which the robot is allowed to begin. For a mobile robot, that may include a known pose, a valid map, enough battery, a clear route, a payload within limits, and a job assignment that matches its permissions. For a manipulation robot, it may include a seated tray, a visible object, a calibrated tool, a clean gripper, and a workcell free of unexpected obstacles. For a home robot, it may include user-approved rooms, known no-go areas, and enough confidence that a target object is what the robot thinks it is.
The start state is closely tied to Robot Site Readiness and Robot Workcell and Fixture Design . A site or cell that presents work consistently gives the robot a fairer starting line. When the start state is vague, every run becomes a new experiment, and the team may mistake setup variation for autonomy weakness.
End States Need Evidence
A robot task is not complete merely because the robot stopped moving. Completion needs evidence. The tote arrived at the correct station. The part is seated in the fixture. The shelf image was captured from the required viewpoint. The door remains open enough for the next step. The object was released without damage. The robot is no longer blocking the lane. The system recorded the job result.
End states matter because they separate motion from work. A robot arm may move a part near its destination without placing it correctly. A mobile robot may reach the right area while facing the wrong handoff side. A cleaning robot may cover most of a surface while skipping the corner where debris collects. A visual inspection robot may visit the target but fail to capture a usable image. From the outside, these can look like successful runs. For the operation, they are incomplete work.
The evidence does not always have to be sophisticated. It may come from a sensor, a fixture switch, a weight reading, a camera check, a barcode scan, a human confirmation, or a downstream process that accepts the result. The important part is that the system knows what proof it is using. Without proof, a task can drift into theater: the robot performs the shape of work while the real verification remains with a person who has to clean up afterward.
The Middle Of The Task Is A State Machine
Between start and finish, a robot task is usually a sequence of states, even when the interface hides that structure. The robot waits, accepts a job, localizes, approaches, checks the scene, moves, manipulates, confirms, reports, and returns. At each state it has different permissions. It may be allowed to move quickly in an empty corridor and slowly near people. It may be allowed to retry a grasp twice but not ten times. It may be allowed to ask for help before touching an uncertain object, but not after dragging it across a table.
Thinking in states is useful because it keeps responsibility clear. The high-level planner can decide the next step, but the safety layer still limits motion. The perception system can express uncertainty, but the task policy decides whether uncertainty is acceptable. The remote operator can rescue an exception, but the robot should still enter a safe local state before help arrives. This is the same layered thinking described in Robot Autonomy , applied to one job rather than the whole machine.
State design also prevents strange loops. A robot that misses a grasp should not retry forever because the command still says “pick object.” It should know when a failed attempt changes the scene enough to require looking again, asking for help, or abandoning the job. A mobile robot that finds a blocked route should not keep nudging the same obstacle because the destination remains valid. It should move into a recovery state that protects the site from repeated nuisance behavior.
Failure Cases Are Part Of The Task
A task definition that only describes success is unfinished. Robots need failure states for the ordinary ways the world refuses to cooperate. The object is missing. The wrong object is present. The target is occluded. The route is blocked. The gripper slips. The payload is heavier than expected. A person enters the work zone. The network degrades. The battery falls below the threshold. The map no longer matches the space.
These events should not be treated as rare interruptions to the real task. In deployment, they are the task. The useful robot is not the one that assumes failure away. It is the one that responds without making the situation worse. That response might be a safe stop, a retry from a new pose, a request for local help, a remote support session, a deferred job, or a maintenance flag. Robot Failure Recovery covers this after the fault appears. Task design decides which faults the robot should expect before the first run begins.
Good failure design also protects people from ambiguous responsibility. If a robot arrives with a tote and the station is full, the worker should not have to guess whether to unload it, move it, reject the job, or wait. If a home robot cannot identify a dropped item, the user should not be trained by accident to trust a guess. The robot’s refusal can be part of the service when the refusal is clear and appropriate.
Acceptance Tests Should Look Like The Work
Acceptance tests are where task design becomes evidence. A robot should not be accepted because it succeeded once in a polished setup. It should be accepted because it performs the defined task across enough realistic variation to support the decision being made. That variation may include different object positions, lighting, payloads, route congestion, human timing, battery levels, sensor dirt, map updates, and ordinary interruptions.
The test should match the claim. If the claim is that a robot can move sealed totes between two stations, the test should include the real route, real station geometry, expected traffic, real handoff timing, and the acceptable rate of intervention. If the claim is that a robot can pick mixed items from a bin, the test should include the actual object range, damaged packaging, partial occlusion, and the failure behavior when an item is unsafe to grasp. If the claim is that a home robot can bring a cup, the test should include cup shapes, lighting, clutter, privacy boundaries, and a way to refuse lookalikes.
Acceptance tests are not only vendor exams. They are design tools. When a test fails, the result can reveal that the task is too broad, the fixture is weak, the route is poorly chosen, the handoff point is awkward, the sensing assumption is fragile, or the acceptance metric rewards the wrong behavior. The goal is not to punish the robot for being imperfect. The goal is to find the smallest truthful task that creates value and can expand with evidence.
Metrics Need A Denominator
Robot task metrics become meaningful only when the denominator is visible. A success rate means little unless the reader knows how many attempts were made, under what conditions, with which objects, and with how much human help. Average cycle time means little unless it includes waiting, retries, charging, recovery, and the human steps the robot creates. Intervention rate means little unless interventions are defined consistently.
A narrow task with honest metrics is usually more useful than a broad task with flattering language. A robot that completes a specific material move ninety-eight times out of one hundred, asks for help clearly on the other two, and preserves the workflow may be valuable even if it cannot generalize. A robot that can attempt many tasks but leaves ambiguous cleanup work behind may be less useful than its demo suggests.
This is why Robot Data Collection belongs near task design. The system should record enough context to explain its own scores. A pass or fail flag is rarely enough. The useful record connects the task definition, sensor evidence, robot state, human intervention, recovery path, and final outcome. Without that record, teams argue from memory and highlights.
Task Design Is A Deployment Contract
A task definition is not only a technical artifact. It is a contract between the robot, the site, the people, and the organization paying for the work. It says what the robot is responsible for, what the environment must provide, what people may expect, and what happens when the boundary is reached.
That contract can be modest and still valuable. A robot may not “run the warehouse,” but it may move a particular class of tote between receiving and packing during defined hours. A home robot may not “do chores,” but it may vacuum mapped rooms and avoid uncertain messes. A lab robot may not “automate experiments,” but it may transfer plates between two instruments when the deck is prepared. The narrower language is not a lack of ambition. It is the shape that lets ambition survive contact with floors, objects, batteries, people, and time.
Good task design also makes expansion cleaner. Once the first task has stable start states, end evidence, failure behavior, and acceptance tests, the next task can borrow what is proven and expose what is new. The team can see whether it is adding a route, an object class, a manipulation primitive, a human handoff, a safety boundary, or a different operating schedule. Expansion becomes an engineering step instead of a new promise.
The best robot tasks feel almost plain when written down. They avoid mystery. They tell the machine what world it is in and tell people what the machine is prepared to do. That plainness is not a weakness. It is often the difference between a robot that performs an impressive moment and a robot that becomes part of ordinary work.
