An AI assistant can return a well-formed request to move a robot to a registered station. That establishes an intended action. It does not establish that the request was accepted, that the robot started, or that the delivery finished.
The next integration problem is maintaining a consistent account of one task across authentication, retries, execution, cancellation, and feedback. This article proposes a task-service contract for that purpose. It extends the separation described in decision boundaries for language models and robots.
Grounded action selection and reliable execution are different questions
SayCan combines language-based task relevance with estimates associated with robot skills to ground action selection in what the robot can do. That research addresses an important gap between language and physical capability. It does not, by itself, define the retry, authorization, or recovery behavior of a production task API. Those remain integration responsibilities. Ahn et al., SayCan, 2022
Keep that distinction visible in the architecture. The model proposes an allowed task. A task service evaluates the request and maintains its record. Existing execution and protective systems retain their own responsibilities.
Define a request that can be checked
The following JSON is a conceptual example, not a robot-control API or a complete schema:
{
"schema_version": 1,
"request_id": "req-demo-0042",
"task_type": "move_to_station",
"robot_id": "amr-07",
"station_id": "assembly-a",
"accept_before": "2030-01-01T12:00:00Z"
}The application should generate and retain the request identifier for the user's intent. A retry must not ask the model to invent a new identifier. After acceptance, the service can return a separate task identifier used for status and cancellation, while retaining the mapping to the original request.
In this proposed contract, accept_before limits when the request may first be accepted. An execution deadline is a separate policy with an explicitly defined starting point and recovery behavior. Field names alone do not establish what should happen when time runs out.
Identity comes from the authenticated session. A model-supplied claim such as an administrator role must not increase authority. Status lookup and cancellation also require authorization: knowing a task identifier is not sufficient permission to inspect or cancel it.
Validate structure and admission separately
JSON Schema can require fields, restrict values, and disallow undeclared properties. Declaring a property alone does not make it required. These checks establish structural constraints, not that a station exists or a user may dispatch a robot there. JSON Schema object reference
Business checks should resolve registered entities, permissions, task conflicts, and the freshness of relevant device state. Their rules should be inspectable and independent of a model's confidence. That does not remove uncertainty from the physical environment; it makes the admission decision reviewable.
Timestamp validation also needs care. In Draft 2020-12, the default format-annotation vocabulary does not require format to act as an assertion. Confirm validator behavior and separately check whether a parsed deadline has passed. JSON Schema 2020-12 validation specification
Retrying one intent should not create a second task
AWS's discussion of idempotent APIs explains the value of caller-provided request identifiers and the complications of repeated identifiers, changed parameters, and retention. Applying that pattern to a robot task service suggests three cases. AWS Builders' Library
- A new identifier is checked and, if accepted, associated with a task record.
- The same identifier and intent parameters return the existing task and its current state.
- The same identifier with conflicting intent parameters is rejected rather than silently changing the destination.
Two requests with identical destinations can represent two legitimate deliveries. Parameter equality alone is therefore insufficient for deduplication. Define the identifier's scope, including caller identity, and the record-retention period.
The difficult case is a crash between sending work downstream and recording its acceptance. A recoverable design needs durable association and a way to reconcile downstream state. An in-memory set of identifiers is insufficient. If the execution system offers neither deduplication nor reliable lookup, an upstream API cannot honestly promise that a physical action will occur exactly once.
A timeout is incomplete knowledge
When an acceptance response is missing, the request might not have arrived, might have been accepted without a returned response, or might have produced a response that was lost. Assigning a new identifier and resubmitting can create a second task.
This table is a proposed application contract, not the ROS 2 standard state machine:
| Observation | What to record | Next action |
|---|---|---|
| Explicit admission rejection | Request identifier and reason | Resolve the cause before proposing a new task |
| Acceptance acknowledged | Task identifier and acceptance time | Query or subscribe to execution progress |
| Acceptance response times out | Acceptance outcome unknown | Reconcile using the original request identifier |
| Feedback stops | Last known state and its age | Query the executor; keep uncertainty visible |
| Cancellation request is accepted | Cancellation in progress | Wait for a confirmed terminal outcome |
| Authoritative terminal result arrives | Result and supporting task record | Update the interface and retained history |
Unknown describes the caller's knowledge; it need not be a robot operating state. Even a not-found response needs interpretation. Was the request never accepted, was a different service queried, or has the record expired? If reconciliation is impossible, stop automatic resubmission and use the defined recovery process.
Cancellation is a process, not proof of stopping
ROS 2 Actions distinguishes goals, feedback, and results. Its cancellation protocol can acknowledge a transition toward cancellation before the action reaches its canceled terminal state. The interface semantics do not prove that a physical robot has stopped. ROS 2 Actions design
An application can therefore distinguish cancellation requested, cancellation in progress, and canceled. A claim that the vehicle is stationary requires the motion-state evidence defined by the vehicle system. Task cancellation is not a replacement for emergency stopping or a protective function.
Feedback should identify the task and include enough ordering and freshness information to reject stale updates. A delayed running message must not overwrite an established terminal result. Navigation success may also be only one stage of delivery: a station handshake or unloading confirmation may still be outstanding.
The model may explain recorded state. It should not invent missing completion evidence.
Test interruption before connecting real execution
Use a simulated executor to inject lost replies, concurrent duplicate requests, restart during dispatch, late feedback, and races between cancellation and completion. Check whether duplicate tasks appear, state moves backward, or an unknown outcome becomes an unsupported success or failure.
The useful deliverable is a traceable task record with defined failure behavior. A successful tool invocation is one event in that record.
Evidence and limits
Research and official documentation were reviewed on November 4, 2026. Request fields, the application table, and proposed tests are engineering design suggestions, not a deployed system or results from robot experiments. No customer cases or personal test history are claimed.