AI robot agents fail dangerously when their output is treated as a command.

They become useful when their output is treated as a proposal.

That distinction is the reason to build a command validation layer between the AI agent and the robot. The validator is the deterministic gate that decides whether an AI-generated request may become a ROS 2 action goal, a supervised skill, a maintenance workflow, or nothing at all.

If the AI layer says “inspect aisle three,” the robot should not immediately move. The system should first ask sharper questions:

• Is the command syntactically valid?
• Is the target known?
• Is the robot in a mode where this skill is allowed?
• Is localization fresh enough?
• Is the obstacle map fresh enough?
• Is the operator allowed to request this?
• Does the requested speed fit the safety envelope?
• Does the action require confirmation?
• Can the action be canceled before the intervention horizon is lost?
• What evidence will be logged if this goes wrong?

This article is the architecture I would use for a ROS 2 robot, Jetson-based edge AI system, or Physical AI prototype where an LLM, VLM, or AI operator copilot can propose robot actions but must not directly own robot motion.

It builds on the authority split in How to Split Authority Between an LLM, ROS 2, and a Microcontroller, the evaluation discipline in How to Evaluate a Local LLM for Robotics Tool Use, and the safety monitor design in Runtime Assurance for Physical AI Robots.

Key takeaways

• An AI robot agent should emit a typed proposal, not a direct actuator command.
• The command validation layer should sit before ROS 2 actions, service calls, mode changes, and any path that can energize motion.
• JSON schema validation is only the first filter. The validator must also check state, mode, freshness, authority, bounds, safety envelope, confirmation, timing, and cancellation.
• ROS 2 actions are usually the right boundary for long-running AI-triggered behavior because they support goal acceptance, feedback, cancellation, and terminal results.
• The validator should fail closed. If policy lookup, state freshness, audit logging, or safety monitor status is unavailable, the command should not be admitted.
• The microcontroller or drive layer should still enforce local freshness, watchdogs, and actuator limits. The validator reduces bad commands; it does not replace actuator-near protection.

Citation-ready answer

A command validation layer for AI robot agents is a deterministic admission-control component that converts untrusted AI proposals into accepted, rejected, delayed, or human-approved robot actions. It should validate syntax, semantic intent, robot mode, operator authority, state freshness, command bounds, safety envelope, cancellation path, and audit evidence before a proposal reaches ROS 2 actions, services, lifecycle transitions, or actuator-facing control. The AI may propose; the validator decides whether the robot is allowed to act.

The architecture in one picture

The validator belongs between semantic intent and robot authority.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

operator / mission system / local LLM / VLM
  -> AI proposal
  -> command validation layer
       - schema
       - semantics
       - mode
       - permissions
       - freshness
       - bounds
       - safety envelope
       - approval
       - audit log
  -> ROS 2 action client or supervised service
  -> action server / behavior tree / planner
  -> runtime assurance monitor
  -> controller / MCU / drive layer
  -> robot motion

This is not a chatbot guardrail. It is closer to an admission controller in a cyber-physical system.

The AI agent can parse messy operator language, inspect logs, call read-only diagnostics, propose recovery steps, or generate a structured skill request. The validator decides whether that request is admissible in the current robot state.

For long-running robot behavior, the validator should usually produce a ROS 2 action goal rather than a topic publish. The ROS 2 action design is built around a server that can accept or reject goals, execute accepted goals, publish feedback, handle cancellation, and report results. That maps cleanly to AI-generated proposals because the proposal can be accepted, rejected, canceled, timed out, and traced instead of disappearing into a raw command stream.

The ROS 2 actions design document is especially relevant here because it makes goal acceptance, feedback, cancellation, and terminal states explicit. Those are exactly the hooks an AI robot agent needs before any physical task is admitted.

Start with proposals, not commands

The AI layer should emit a proposal shaped like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "proposal_id": "p-2026-07-27-00142",
  "intent": "inspect_area",
  "target": {
    "type": "named_location",
    "id": "charging_station_a"
  },
  "constraints": {
    "max_speed_m_s": 0.25,
    "avoid_dynamic_obstacles": true,
    "return_if_battery_below_percent": 15
  },
  "requested_by": {
    "actor_type": "operator",
    "actor_id": "maintenance_lead"
  },
  "evidence": {
    "source": "operator_chat",
    "trace_id": "trace-7419"
  }
}

That object is still untrusted.

It is not allowed to move the robot. It is only a candidate for validation.

The validator should normalize it into an internal command envelope:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "command_type": "ros2_action_goal",
  "action_name": "/inspection/inspect_area",
  "risk_tier": "motion_low_speed",
  "requires_confirmation": true,
  "expires_at_ms": 250,
  "allowed_modes": ["assisted", "autonomous_supervised"],
  "required_state": {
    "localization_age_ms_max": 200,
    "obstacle_map_age_ms_max": 150,
    "battery_percent_min": 15,
    "estop_state": "released",
    "fault_state": "none"
  }
}

The important part is not the exact JSON. The important part is where authority lives.

The AI proposes intent. The validator owns admission. ROS 2 owns supervised execution. The runtime assurance layer owns live veto, clamping, cancellation, degradation, and fallback. The microcontroller or drive layer owns actuator-near freshness and hard timing.

This is the same authority model I use in robot safety architecture, but applied to one narrow interface: AI-generated commands.

The validator stack

Do not build one giant is_safe=true function. Split the validator into explicit gates.

The validator should return a structured decision:

1
2
3
4
5
6
7
8

{
  "decision": "rejected",
  "reason_code": "STATE_STALE_LOCALIZATION",
  "human_message": "I need fresh localization before I can request motion.",
  "blocked_gate": "state_freshness",
  "trace_id": "trace-7419",
  "safe_next_actions": ["refresh_localization", "run_read_only_diagnostics"]
}

That rejection is a product feature. It is how the robot stays useful without pretending the AI layer is always right.

Admission decision matrix

A practical validator should produce a small set of decisions that downstream systems understand.

Avoid returning free-form “probably safe” language. The validator is not a model narrator. It is an authority gate.

Where ROS 2 actions fit

AI-generated behavior often looks like a tool call, but in a robot it is usually a long-running physical task.

That makes a ROS 2 action a better boundary than a topic or a short service for many commands:

The validator can call quick services to check permissions, state, map metadata, or dry-run feasibility. But once a physical task is admitted, a ROS 2 action gives the supervisor a goal ID, feedback, result, and cancellation path.

That goal ID is operationally important. It lets you correlate:

• AI proposal,
• normalized command,
• approval record,
• validator decision,
• ROS 2 action goal,
• action feedback,
• runtime assurance events,
• rosbag and structured logs,
• final result.

Without that trace, debugging an AI-triggered robot incident becomes guesswork.

Lifecycle and mode are validation inputs

Robot teams often validate command arguments and forget component lifecycle.

That is weak.

A command can be perfectly formed and still invalid because perception is inactive, localization is degraded, the controller is not active, the robot is in maintenance, or the action server restarted five seconds ago.

The ROS 2 managed-node lifecycle design gives nodes explicit states such as unconfigured, inactive, active, and finalized, with transitions controlled by supervisory logic. That matters for AI command validation because an AI proposal should not be admitted just because the text is plausible. The target subsystem must be in a state where the command makes sense.

Use lifecycle and mode checks like this:

This is why I prefer a dedicated mode manager over scattered boolean flags. A validator that reads one coherent mode state is easier to test than one that reconstructs safety state from ten loosely related topics.

The safety envelope is not a prompt instruction

“Move slowly and safely” is not a control.

The validator should turn vague constraints into numeric and stateful checks:

This is also where robot safety standards and secure AI guidance become engineering inputs rather than compliance wallpaper.

ISO 10218-1:2025 is about safety requirements for industrial robots as machines, while ISO 10218-2 covers integration into complete systems. Even if a prototype is not an industrial robot cell, the lesson is useful: machine safety and system integration are different layers. An AI validator should not pretend it replaces either one.

The NCSC Guidelines for secure AI system development also frame AI security across design, development, deployment, and operation. For robot agents, that lifecycle view matters because command validation is not just a runtime trick. It needs threat modeling, release gates, logging, monitoring, and update discipline.

Security checks belong in the same gate

Physical safety and cybersecurity meet at command authority.

If an attacker can influence the AI proposal, tool result, memory, prompt, map annotation, or operator identity, they may influence robot motion. The validator must therefore treat agent security controls as physical-system controls.

The OWASP AI Agent Security Cheat Sheet is useful here because it emphasizes least privilege, tool authorization, input validation, human-in-the-loop controls, output validation, monitoring, and adversarial testing for agents. Those controls map directly onto robot command admission.

The validator should be model-agnostic. It should not trust a command because it came from the “good” model, the local model, the latest VLA, or a prompt that sounds careful.

Trust the gate, not the prose.

The microcontroller still gets a vote

A good validator blocks bad commands before they reach ROS 2 actions.

It still does not replace actuator-near protection.

The MCU, PLC, motor controller, or drive layer should independently enforce:

• command expiry,
• heartbeat timeout,
• mode pin or enable state,
• speed and current limits,
• local stop behavior,
• watchdog reset behavior,
• sequence validity,
• safe default on communication loss,
• hard limit switches or drive safety functions.

This is the same boundary described in Microcontroller vs Jetson: Where Real-Time Control Should Live. The Jetson or ROS 2 computer may be the right place for AI proposals and robot-level supervision, but real-time control and electrical protection should stay closer to the machine.

The validator should reduce the probability of unsafe intent reaching the robot stack. The MCU should still make expired or impossible low-level commands harmless.

Test the validator like a safety-critical interface

Do not only test happy-path prompts.

Build a replayable admission-test suite:

Each test should assert:

• normalized command,
• blocked or passed gates,
• final decision,
• reason code,
• audit event,
• absence of unauthorized ROS 2 action calls,
• expected operator-facing response.

This test suite should run whenever prompts, tools, model versions, validator policies, action definitions, mode logic, or safety thresholds change.

The ros2_control diagnostics example is a useful reminder that robot hardware status and diagnostics should be machine-readable. Human dashboards are not enough. The validator needs structured health inputs it can use in deterministic decisions.

A minimal implementation pattern

For a small ROS 2 robot, I would start with this structure:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

/ai/proposals
  - non-actuating AI proposal topic or service

/command_validator/validate
  - synchronous validation service
  - returns accept, reject, clarify, confirm, defer, degrade, escalate

/command_validator/events
  - structured decision log

/mode_manager/state
  - normal, assisted, degraded, maintenance, fault, safe_stop

/robot_state/summary
  - pose age, localization covariance, obstacle age, battery, thermal, fault state

/inspection/inspect_area
  - ROS 2 action for admitted inspection behavior

/runtime_assurance/events
  - live allow, clamp, cancel, fallback, safe_stop decisions

/mcu/heartbeat
  - actuator-near liveness and command freshness

The validator itself can be implemented in any ordinary service stack, but its behavior should be boring:

1. Parse proposal.
2. Normalize intent.
3. Look up skill policy.
4. Check actor and session authority.
5. Read mode and robot state snapshot.
6. Check freshness and bounds.
7. Check runtime assurance availability.
8. Decide approval requirement.
9. Write audit event.
10. Return decision.
11. If accepted, submit the ROS 2 action goal with correlation IDs.

The validator should not call the LLM to decide whether the LLM was safe.

You can use an LLM to help explain a rejection to the operator. You should not use it as the source of authority for admission.

Failure modes

The most common failures are architectural, not model-specific.

The subtle failure is bypass. If the validator is only one optional client among many, it is documentation, not architecture. Action servers for risky skills should require an admission record or validator-issued short-lived token before accepting AI-originated goals.

What good looks like

You know the command validation layer is mature when these statements are true:

• AI-generated proposals are never actuator commands.
• Every admitted physical action has a validator decision and trace ID.
• Every risky action has an explicit risk tier.
• Every risk tier maps to permissions, confirmation, state requirements, and logging.
• Action servers can reject goals that lack a valid admission record.
• Runtime assurance can cancel or degrade accepted goals.
• The MCU rejects stale or invalid low-level commands anyway.
• Prompt injection tests cannot create physical authority.
• Replaying the logs explains why the robot moved or did not move.

That is the practical standard.

The robot does not need to trust the AI agent. It needs to trust the narrow path through which AI proposals become robot behavior.

FAQ

Is JSON schema validation enough for AI robot commands?

No. JSON schema validation only proves that the proposal has the right shape. A physically unsafe command can be perfectly valid JSON. The validator must also check robot mode, state freshness, numeric bounds, target semantics, actor permission, confirmation, cancellation, safety envelope, and auditability.

Should an AI agent call ROS 2 actions directly?

Usually no. The AI agent can propose an action goal, but a deterministic validator should submit the ROS 2 action after admission. For low-risk read-only diagnostics, direct tool calls can be acceptable if permissions, rate limits, and logs are enforced.

Where should command validation run on a Jetson robot?

Run it close to the robot supervision layer, usually on the Jetson or robot computer that has access to ROS 2 state, mode, diagnostics, action clients, and audit logs. Do not put hard real-time actuator protection there. That belongs in the MCU, motor controller, safety PLC, or drive layer.

How is this different from runtime assurance?

Command validation is admission control before a proposed action starts. Runtime assurance monitors behavior while the action runs and can clamp, cancel, degrade, or trigger fallback. A good robot needs both.

What should fail closed?

Policy lookup, actor identity, state freshness, safety monitor status, approval validation, action availability, audit logging, and cancellation capability should fail closed for motion or other high-risk commands. If the validator cannot prove the command is admissible, the robot should not act.

What is the main design rule?

The AI may propose, but deterministic robot software must admit. The closer a command gets to motion, power, timing, or human safety, the less authority the AI layer should have.