The next stage of an agent system is not a larger plugin stack. It is a set of reusable nodes that can connect intent to action, receive evidence back, and change what happens next.
From the brain to the hands and feet
I increasingly think about agent systems in three stages. The first is the brain: problem decomposition, WHY/HOW routing, learning, review, and pattern formation. The second is the hands and feet: allowing an agent to read from real sources and produce real digital outputs through tools such as Notion, local files, browsers, CAD, simulation, and code.
The third stage is different. It is not simply more automation inside a computer. It is the point where an agent can influence a physical process through instruments, manufacturing systems, and experiments, then receive measurements back from the world. In an organ-chip setting, that means connecting design, fabrication, sensing, interpretation, and revision into one supervised loop.
Do not build around plugins. Build around loops.
A plugin-first approach begins with a tool that looks powerful or interesting and asks how to connect it. The system accumulates integrations, but the number of integrations does not necessarily tell us whether the system can complete anything important.
A loop-first approach begins with a path that needs to become repeatable. It defines the nodes on that path, then selects only the tools that are needed to make those nodes work. The plugin is an implementation detail. The closed-loop node is the system asset.
The question is not what the agent can connect. The question is which next loop it can make more complete.
From software names to capability nodes
A durable system should not depend on the name of a particular application. Blender, FreeCAD, a browser automation framework, or a simulation package may all change. What should remain is the capability that the system needs: geometric generation, manufacturing-constraint checking, simulation screening, experiment execution, data collection, result interpretation, or pattern formation.
Each capability can be described with the same small contract: what problem does it solve, what does it take in, what does it return, what counts as success, and how does it fail or hand the decision back to a person? For example, a parameterised geometry node might accept geometric, material, and manufacturing constraints, return a STEP or STL model, and fall back to parameter revision or human review when the design cannot be exported safely.
Once a tool is described this way, the agent is no longer calling a software name. It is calling a capability in a graph. The underlying tool can be replaced without destroying the system's main line.
The missing layer between digital and physical action
An agent does not directly perform an organ-chip experiment. It generates an experimental intention, proposes a design, creates files or device instructions, schedules actions, receives feedback, and explains deviations before suggesting the next move.
Between those digital actions and physical actions, there must be a translation layer. A workflow has to be decomposed into action atoms that a machine can execute, a sensor can observe, and a system can check. Without this layer, “the agent enters the laboratory” remains a metaphor. With it, the system can begin to make a real process legible and revisable.
A closed loop for organ-chip research
In an organ-chip context, the loop can be organised into five layers:
- Goal. Define what should be improved: function, vascularisation, cell viability, mechanical stability, manufacturability, reproducibility, cost, or time.
- Design. Generate candidate geometries, material combinations, flow conditions, printing parameters, protocols, risks, and informative measurements.
- Execution. Bridge the design to CAD, simulation, slicing, printing, device control, and the experimental checklist.
- Sensing. Recover the real state of the system through images, flow and pressure data, cell status, electrical or mechanical readouts, and human observations.
- Interpretation. Explain the deviation, update the model, preserve the useful pattern, and choose the next experiment.
The important part is the order of the actions. “Design an organ chip and print it” is too compressed to be a reusable loop. A real loop defines the target, generates the structure, checks manufacturing boundaries, prints, measures the result, introduces cells or flow, compares the observation with the target, explains the error, and updates the design or protocol.
Place capabilities by coupling, not by ideology
Local and server deployment are not competing beliefs. They are ways of respecting different kinds of coupling. Capabilities that depend on a local GUI, a hardware interface, sensitive raw data, or very low latency belong near the device. Capabilities that need heavy computation, shared memory, long-running jobs, indexing, or audit logs are often better placed on a server.
A practical split is a server-side brain, memory, orchestration layer, and heavy computation; a local edge for instruments, GUI tools, device control, and data capture; and a common task protocol between them. The architecture follows the relationship between the capability and the world it has to touch.
Progressive autonomy is more useful than a fantasy of full automation
The sensible route into the physical world is gradual. First comes a cognitive loop: reading, hypothesis generation, experiment design, review, and pattern accumulation. Then a digital execution loop: generating CAD or simulation files, organising steps, archiving data, and suggesting new parameters. Then a physical execution loop: starting a printer or pump, collecting sensor data, triggering imaging, and raising an alarm when a boundary is crossed.
The realistic near-term destination is a supervised semi-autonomous experimental system. It can run part of an iteration inside explicit safety boundaries while a person remains responsible for the important decisions. The goal is not a “robot scientist” that pretends context has disappeared. The goal is a system that makes the experiment easier to inspect, repeat, and improve.
Six objects, one working language
To keep the second and third stages connected, I find it useful to describe every capability through six objects: Task, Model, Tool, Protocol, Observation, and Pattern. A task gives the system a question and success condition. A model gives it a provisional explanation. A tool creates an action. A protocol defines how the action is carried out. An observation brings the world back in. A pattern preserves what can be used again.
This language is more stable than any particular stack of applications. It lets a system change tools without losing its memory of what the tools were meant to accomplish.
Four questions before adding another tool
Before connecting a new plugin, I want to ask: does it enhance cognition or execution? Does it belong on the server or at the local edge? Does it return information or an action? And can its result flow back into a pattern that the system can learn from?
If the answer to the last question is no, the integration may still be useful, but it is probably a one-off convenience rather than a durable component of the loop.
The first stage of an agent system asks how to think. The second asks how to use digital tools. The third asks how to map digital action onto experiments and manufacturing. The real system is built when those stages meet in a supervised loop: from hypothesis to design, design to making, making to measurement, and measurement back to the next hypothesis.