PUDA Connects Laboratory Agents Through a Constrained CLI and Event Logs, Isolating Generative Planning from the Hardware Driver Layer

Physical Unified Device Architecture (PUDA) proposes an automated laboratory execution layer designed for AI agents. Instead of requiring agents to operate graphical interfaces or generate instrument-control code at runtime, it wraps each device as a discoverable command-line tool. Protocols and responses use JSON, while command dispatch, telemetry, and status updates are transmitted through the NATS messaging system. JetStream provides event persistence, queuing, and replay.

The architecture deliberately separates scientific decision-making from physical operations. An agent can determine the next experiment based on measurements, logs, images, or reports, but edge services expose only driver methods that engineers have reviewed in advance. Before a command reaches the hardware, the system validates its name, required inputs, data types, and permitted ranges. This prevents models from arbitrarily rewriting low-level control software during execution while keeping individual actions atomic and auditable. Each device subscribes to its own command channel, allowing analysis, monitoring, and planning agents to work in parallel without encoding the entire experiment as a single workflow graph.

PUDA also links protocols, runs, samples, measurements, and command logs using stable identifiers and timestamps, aiming to address the broken data provenance common in automated laboratories. If a measurement is anomalous, researchers can trace it from the data product back to the hardware response and original command. Durable event streams can also reconstruct state after a service interruption. These traces could eventually become training data for embodied agents, provided that human approvals, failures, and environmental conditions are recorded comprehensively as well.

At present, the paper primarily delivers an architecture and its design rationale. It does not provide cross-instrument benchmarks, fault-injection results, latency data, or a link to a public implementation. It therefore does not establish that the system can already operate real-world chemistry or materials experiments safely. Engineering teams should next examine the driver interface's permission model, two-step confirmation for hazardous commands, safeguards against duplicated actions caused by JetStream redelivery, and whether instruments from different vendors can share consistent semantics for state and samples.