Before Your Agents Touch Motors: A CTO Safety Case for AI-to-IO

By Diogo Hudson Dias
Engineer on a factory floor inspecting a laptop connected to a PLC cabinet beside a running conveyor with visible safety relays and an emergency stop.

Anthropic just previewed a hardware standard that lets AI agents control the physical world. It’s the moment a lot of teams have been waiting for—“finally, our warehouse bot can press the real button.” It’s also the moment a lot of CTOs are about to get hurt. The failure mode here isn’t a broken UI; it’s a pallet on the floor, a pump run dry, or a lawsuit.

If you’re going to connect agents to I/O—relays, motors, valves—you need a safety case, not a demo. This post gives you a decision framework to draw the boundary between autonomy and control, wire three independent interlocks, budget latency properly, test with a twin before you touch metal, and ship a tamper-evident audit trail. We’ll keep it vendor-neutral, but we’ll acknowledge the reality: you’ll be bridging modern agent stacks (MCP, ROS 2, gRPC) with old-but-reliable plant tech (OPC UA, Modbus/TCP, EtherCAT, safety PLCs).

The boundary that saves you: agent vs. controller

Most teams get the architecture wrong by letting the agent “drive” the plant directly. Don’t. The agent proposes; a certified controller disposes. That boundary is your legal, operational, and moral safety line.

Draw it like this:

  • Agent layer (uncertified, adaptive): Plans tasks and proposes intents like “move conveyor A at 40% for 12 seconds” or “open inlet valve B until level hits 70%.” It never toggles a GPIO or writes a coil directly.
  • Command envelope (deterministic, filterable): Validates, shapes, and rate-limits intents. Think of it as a kernel for actuation: unit-aware, bounds-checked, jerk-limited. If the envelope can’t prove safety, it refuses the command.
  • Plant controller (certified, real-time): A PLC/drive/robot controller actually manipulates motors and valves. It enforces hard interlocks and invariants at millisecond loop times and drops to a safe state on loss of comms.

Agents live outside the safety boundary. Your controller and safety system live inside it. That’s the line your lawyers, auditors, and ops team can defend.

Make safety constraints executable

Policies belong in code, not a PDF. You need machine-checkable invariants in the command path—before commands ever hit a PLC. Examples:

  • Mutual exclusion: “Forward and reverse contactors for Motor M must never be energized simultaneously.”
  • Rate limits: “Change conveyor speed by ≤10% per second; absolute max 60% during mixed-human zones.”
  • State guards: “Do not open Valve B unless Pressure P < 1.2 bar and Temperature T < 40°C.”
  • Energy limits: “Robot TCP speed must remain ≤250 mm/s while safety scanner zone 2 is occupied.”

Represent constraints as a domain rule set compiled into runtime checks. You don’t need formal methods to start; a safe envelope can be enforced with statecharts and a handful of predicates. But do treat it like a controller: write property tests, fuzz discontinuities, and prove monotonicity where possible.

Three interlocks, independent paths

Saying “we have an E‑stop” isn’t enough. You want overlapping, diverse defenses so a single class of bug can’t take you out.

1) Policy gate (who may do what)

  • Allowlists over prompts: The agent can only invoke named skills with typed arguments. No free‑form actuation strings.
  • RBAC + time bounds: Certain skills (e.g., “open caustic valve”) require elevated roles and explicit time-boxed approval. Embed a two‑person rule for policy changes.
  • Command budgets: Per shift or per recipe, cap high-risk actuation count and duty cycle. You should be able to answer, “How many times did we open this valve in the last 24h?”

2) Physics gate (the envelope)

  • Unit-checked, jerk-limited commands: Commands carry units and are automatically shaped (e.g., S-curve profiles) to avoid transients.
  • Invariant checks with sensor corroboration: The envelope refuses to proceed if the required sensors are degraded, stale, or contradictory.
  • Watchdog + bounded horizon: Agent intents must have a clear end condition. If not satisfied, the envelope aborts and falls back to a known state.

3) Plant gate (safety PLC/relays)

  • Hardwired E‑stops and safety scanners: Category 3/4 circuits per ISO 13849, normally‑closed wiring, and safety relays that de‑energize to safe.
  • Safe Torque Off (STO): For drives and robots, use IEC 61800‑5‑2 functions where available.
  • Independently clocked watchdog: If the controller misses a heartbeat (e.g., 100 ms) from the envelope, it drops to a safe state—no excuses.

These paths should be technologically diverse where practical: an LLM policy layer can fail independently from a PLC firmware bug or a safety relay welded closed.

Latency budgets that won’t get someone hurt

Actuation isn’t chat completion. Put numbers on it, or don’t ship it.

  • Closed-loop controllers: 1–5 ms loops for servo motion; 5–20 ms for typical PLC logic. This is not agent territory.
  • Human-scale logistics: Conveyors and pick‑lights: 50–200 ms round‑trip is acceptable. Your envelope + PLC must keep total jitter under that.
  • Network realities: LAN OPC UA round‑trips are often 5–15 ms; cross-region cloud RTTs can be 60–120 ms with fat tails. Never place safety-critical decisioning across a WAN.
  • Heartbeats and timeouts: 100 ms heartbeat from envelope to PLC; 300–500 ms timeout to fail‑safe. Log both directions.

Rule of thumb: keep the envelope and the plant controller co‑located at the edge. Agents can be in a back office or on a nearby edge node, but the last 10 ms of control must not cross the public Internet.

“Human in the loop” isn’t a safety strategy

HITL is a governance layer, not a control loop. A human cannot reliably confirm at 200 ms cadence that commands won’t violate a pressure limit. Use human review for policy (e.g., “approve recipe change”) and intent (e.g., “schedule after shift”), not for button‑mashing your way to safety.

Test like aerospace: SIL, HIL, and twins

Don’t learn on the real plant. Use:

  • Software‑in‑the‑loop (SIL): Simulate PLC logic, envelope code, and agent plans against a plant model. For robotics, ROS 2 + Gazebo or Webots; for PLCs, vendor simulators (PLCSIM, CODESYS) or a mocked OPC UA server.
  • Hardware‑in‑the‑loop (HIL): Real controllers wired to a simulated plant through I/O emulators. Validate watchdogs, STO, and emergency chains. Prove the system fails safe when you yank cables.
  • Digital twins with fault injection: Script scenarios like “stuck valve” or “sensor drift.” Treat “sensor stale > 200 ms” as a first‑class fault, not an edge case.

Make the exit criterion explicit: “No command reaches a real actuator unless it has passed SIL tests covering 95% of reachable state space and HIL tests for all Category A hazards.”

SIL, not vibes: what standard are you aiming for?

If you’re in regulated industries, your auditors speak IEC 61508/61511 (process), ISO 13849 (machinery), or UL 4600 (autonomy). You don’t need to certify the agent, but you do need to map your envelope and plant gates to required Safety Integrity Levels (SIL) or Performance Levels (PL).

  • Continuous mode targets (IEC 61508 PFHd): SIL 1: 1e‑6–1e‑5 dangerous failures/hour; SIL 2: 1e‑7–1e‑6; SIL 3: 1e‑8–1e‑7. Most brownfield logistics will target SIL 1–2 for specific safety functions.
  • Diagnostics matter: You raise PL/SIL not just with beefier hardware but with better diagnostics coverage and test intervals. Your envelope’s self‑tests count.
  • Document the safety case: Hazard analysis (HAZOP/STPA), safety requirements allocation, verification matrix, and evidence. Vibes don’t pass audits.

Command contracts: intents, acks, and measured effects

Every actuation should be traceable from intent to measured effect with explicit acks along the way:

  1. Intent created: Agent proposes Actuate(ConveyorA, speed=0.4, duration=12s)
  2. Envelope accept/refuse: Validated, shaped to safe profile, or rejected with reason
  3. Controller ack: PLC accepted or refused; log code path
  4. Telemetry closure: Sensors confirm the desired state (e.g., speed sensor ~0.4 within tolerance). If not achieved in T seconds, raise an incident and roll back to safe

Commands that don’t result in a measurable, timely effect are not “done.” They’re anomalies, and they roll up to your MTTR and incident metrics.

Audit you can take to court

When something goes wrong, you won’t be arguing with an engineer; you’ll be arguing with an insurer or a regulator. Your logs must be tamper‑evident and complete:

  • Append‑only storage: WORM buckets or a Merkle‑chained log per edge node. Hash snapshots to a separate system every N minutes.
  • High‑resolution telemetry: 50–100 Hz capture for relevant sensors/actuators during active jobs. Coarser during idle to control costs.
  • Replayability: Given a log segment, you can reconstruct the envelope’s decision, the PLC program path, and the resulting plant state.
  • Attribution: Sign agent and envelope binaries, record model version/weights hash, skill catalog version, and PLC firmware checksum for each run.

Brownfield integration without illusions

Your plant probably speaks OPC UA, Modbus/TCP, Profinet, EtherNet/IP, or EtherCAT. Your agent stack probably speaks gRPC or ROS 2 (DDS). Don’t force a rewiring just to be “modern.”

  • Bridge, don’t rewrite: Build a thin, testable gateway that translates typed intents to controller calls. Limit its responsibility to serialization, time sync, and retries.
  • Clock discipline: Use PTP or at least NTP with monitoring; your envelope and PLC should agree within a few milliseconds.
  • Degrade gracefully: On network partition, the controller keeps executing the last safe recipe or drops to a safe idle. The agent doesn’t get a veto.

Org design: separate curiosity from control

Conway’s Law is a safety risk. If the same team that tunes prompts can push plant‑side code, you’ll ship a demo to production. Set boundaries:

  • Safety owner: A single accountable owner for the envelope and plant gates. Treat it like “SRE for physics.”
  • Change control: Two‑person rule for safety policy changes; production simulators for dry‑runs; every change gets a hazard diff.
  • Red team drills: Quarterly exercises where you kill network links, fault sensors, and inject bad intents. Measure detection and recovery times.

If you need domain expertise quickly, nearshore mechatronics teams can move the needle. Brazil alone graduates thousands of control and electrical engineers each year and has a deep bench of PLC integrators thanks to its manufacturing base. With 6–8 hours of overlap, a Brazilian nearshore pod can wire up OPC UA gateways, build your envelope’s invariant library, and ship HIL test rigs 20–30% cheaper than US onshore—without timezone pain.

Buy vs. build: where the leverage is

Build the envelope; buy the rest where sensible.

  • Buy: Safety PLCs/relays and drives with STO; light curtains/scanners; fieldbus adapters; vendor‑supported OPC UA servers; secure remote access gateways.
  • Build: Domain‑specific command envelope with invariants; simulation models and HIL harnesses; policy gate and audit pipeline; typed skill catalog with signatures.
  • Reuse: ROS 2 for robotics middleware; OPC UA for information models; protobuf/gRPC for skill definitions; existing plant programs with well‑tested logic.

A practical 90‑day plan

Days 0–30: draw the boundary and simulate

  • Inventory actuators and hazards; write a one‑page hazard summary (top 10 failure modes).
  • Define 10–20 invariants as code in a stub envelope; hook to a simulator (Gazebo/Webots/PLCSIM/mocked OPC UA).
  • Stand up append‑only logging with model/version attestation.
  • Decide edge placement; provision an industrial PC with dual NICs and PTP time sync.

Days 31–60: wire real controllers and interlocks

  • Integrate with a real PLC on a bench (HIL). Prove watchdogs and STO behavior by pulling cables.
  • Implement the policy gate: allowlisted skills, RBAC, time‑boxed approvals.
  • Write 20–30 SIL tests and 10 HIL fault‑injection scenarios. Don’t touch production hardware yet.

Days 61–90: pilot in a cordoned cell

  • Deploy to a single, fenced‑off cell with hard E‑stops and safety scanners.
  • Run supervised shifts with agents proposing intents; envelope executes under strict budgets.
  • Collect 2–4 weeks of logs, tune invariants, and publish a safety case v1 covering the pilot scope.

What Anthropic’s move actually changes

Anthropic’s “hardware standard for agents” is a positive signal: the ecosystem is acknowledging the need for a common control plane between AI and I/O. Take advantage of it—but don’t relax your boundaries. A standard skill API or GPIO hub doesn’t eliminate the need for your envelope, your interlocks, or your audit trail. If anything, it makes your job easier: you can focus your engineering effort on the safety case rather than driver glue.

Failure stories you can avoid

  • The optimistic watchdog: A startup let the PLC assume the envelope was alive unless told otherwise; a crashed process left a pump running. Invert that: default to safe on missed heartbeats.
  • The invisible constraint: A team “knew” two valves shouldn’t be opened together but never encoded it; an agent “optimized” cycle time and mixed reagents. If it matters, it’s an invariant.
  • The cloud reflex: A logistics bot depended on a cross‑region plan approval step; a 40‑second outage stalled a line and confused operators. Keep safety and short‑horizon decisions local.

The boring route is the fast route

CTOs get in trouble chasing novel control when boring control—with real safety engineering—would have shipped faster and kept the plant running. Your agent doesn’t need to be a virtuoso of Modbus coils. It needs to be a good citizen that proposes clear intents, accepts refusals gracefully, and leaves the hard part—real‑time safety—to the systems built for it.

Key Takeaways

  • Draw a hard boundary: agents propose intents; certified controllers execute within a coded safety envelope.
  • Implement three independent interlocks: policy gate, physics gate (envelope), and plant gate (PLCs/E‑stops/STO).
  • Budget latency realistically: keep the envelope and controllers at the edge; never put safety decisions over a WAN.
  • Test before touching metal: SIL for logic coverage, HIL for real watchdogs/interlocks, and twins with fault injection.
  • Make safety constraints executable: encode invariants (mutual exclusion, rate limits, state guards) and refuse unverifiable commands.
  • Ship an audit trail you can defend: append‑only logs, high‑rate telemetry during jobs, full attribution of models and firmware.
  • Organize for safety: separate teams for agents and plant control; two‑person rule for policy changes; red‑team your physics.
  • Build the envelope, buy the safety hardware, and bridge to brownfield standards like OPC UA and ROS 2.
  • Nearshore mechatronics pods in Brazil can accelerate OPC UA gateways, invariants, and HIL rigs with 6–8 hours overlap and 20–30% lower cost.

Ready to scale your engineering team?

Tell us about your project and we'll get back to you within 24 hours.

Start a conversation
© 2026 DHDTech.io. All rights reserved.
DHDTech.io · Sheridan, Wyoming
Powered by DHDTech.io DHDTech.io