Jiuwen Symbiosis: Physical Agents Execute AI-Designed Experiments in Automated Labs

Why Wet Experiments Are the Hard Part of AI-Driven Research

AI can generate feasible experiment plans, but turning a textual protocol into a sequence of physical actions remains the core bottleneck. A single instruction such as "prepare three solutions per Plan B, stir at 60°C for two hours, then perform spectral characterization" expands into dozens of physical steps: fetching containers, opening caps, weighing, pipetting, mixing, heating, and moving samples between stations. Each step requires a specific device or embodied robot, and the system must continuously verify preconditions — e.g., is the cap off, is the heating station free — while handling heterogeneous hardware, concurrent workflows, and unexpected disturbances. In a wet lab there is no undo button; a single state error can cascade into failure or safety hazards.

Jiuwen Symbiosis Architecture: The Perception–Planning–Execution–Feedback Loop

Jiuwen Symbiosis addresses these challenges with an Agent Loop that repeatedly senses the environment, plans the next actions, executes them on physical hardware, and validates the outcome before proceeding.

Perception: Building a Structured View of the Scene

Perception answers "what does the scene look like right now?" by fusing two information streams:

Environment state : open-vocabulary visual recognition locates containers and samples from natural-language descriptions; depth data projects detections into each device's coordinate frame regardless of whether the camera is on a robot arm or fixed to the bench.

Device state : every device declares its capabilities (move, grip, aspirate, vision), current pose, availability, and whether its end-effector holds an object. The planner only assigns actions to devices that explicitly possess the required capability.

An adapter layer abstracts away vendor-specific hardware interfaces, presenting a unified capability/state model so workflows reason about "who can do this step" rather than low-level driver details.

Planning: Dynamic Orchestration Based on Live State

Planning takes a natural-language experiment goal, the structured scene state, and device capabilities, then decomposes the task into a dependency-ordered sequence of subtasks. Each subtask is matched to an available device with the right capability (e.g., liquid handler for dispensing, robot arm for transfer, mobile robot for cross-station transport). Data dependencies are explicit: the location perceived in step N becomes the pick parameter for step N+1, not a hard-coded coordinate. Before dispatch, the whole plan is validated to ensure every precondition can be satisfied by preceding steps, preventing constraint violations from entering execution.

Unlike fixed scripts, this dynamic orchestration decouples the experiment from a specific lab layout or device set. The same goal yields different executable plans under different conditions; adding a new experiment type requires no new control code; new devices join the pool simply by advertising their capabilities.

Execution: Cross-Device Action Scheduling with Safety Gates

The planner's output is split into device-specific action commands and scheduled sequentially across the liquid handler, robot arms, and mobile robots. Every handoff checks that the previous action truly completed and the next device is free and reachable. Motion and grasp commands are never issued in parallel to the same device. Before any command reaches hardware, it passes through safety guardrails (detailed below).

Feedback: Observation-Driven Replanning

After each step, the result is written to execution memory and the scene state updates. Before the next step begins, the system verifies the latest reality against the plan. If the target container is not where expected, a station is occupied, or the prior step did not achieve its effect, replanning is triggered with a configurable retry limit to avoid infinite loops. The verified outcome then becomes the perception input for the next cycle, closing the loop.

Execution Memory and Replayable Trajectories

Execution Memory: Real-Time State Cognition

Long experiments demand more than "what to do next." The system automatically maintains: perceived target positions and device states; successful action results that subsequent steps inherit; and automatic invalidation of stale spatial references (e.g., when a mobile robot's base shifts, previously recorded positions expire, forcing re-observation). Two principles govern this memory: observed state trumps inferred state, and unconfirmed state is treated as "unknown" rather than assumed true. For instance, if a bottle cap has never been seen open and no action record proves it opened, the system will not assume it is open — directly preventing the class of cascading failures caused by unverified object states.

Replayable Trajectories: From Single Failures to Systemic Improvement

Every action call, observation, and exception is structurally logged with optional key frames. Post-run, the trajectory renders as a visualizable report. When a sample yields anomalous results, researchers trace back: which step, which device, what was the scene state, were there retries. Offline analysis clusters many historical trajectories, extracts common failure patterns, and proposes improvements for human review — turning individual failures into continuous systemic learning.

Safety Guardrails: Boundaries on Every Action

Flexibility in a wet lab must be bounded by safety. Jiuwen Symbiosis places guardrails at two critical execution events:

Pre-execution safety guardrails fire before every motion-tool invocation. Out-of-bounds commands are rejected outright; even unconfigured boundaries trigger type and value sanity checks (non-numeric, infinite, etc.).

Recovery guardrails activate on execution failure. The system attempts to return the device to a known safe pose: if the gripper is empty, it releases; if it holds a sample, it maintains grip and retracts under load — never dropping a sample due to a motion error. If recovery itself fails, the system stops retrying and escalates the issue, leaving the device in a known state for the next decision (retry, replan, or human intervention).

From "Writes a Plan" to "Completes the Experiment"

Jiuwen Symbiosis is not a single monolithic model but a full physical-agent stack: the perception–planning–execution–feedback loop sees the scene and adapts orchestration on the fly; execution memory and replayable trajectories remember every step and enable root-cause learning; safety guardrails enforce hard boundaries on every motion. Together they close the gap between AI-generated experiment designs and reliable autonomous wet-lab execution.

Open-Source Repositories

AtomGit: https://atomgit.com/openJiuwen/jiuwensymbiosis GitHub:

https://github.com/openJiuwen-ai/jiuwensymbiosis