Six Agents, One Substrate

Most agent products have one agent. Paramus has six, because lab work comes in different shapes. A question takes minutes. A discovery campaign takes days. An experimental campaign takes weeks and stops before every robot run. A change to the scientific model waits most of its life for two people to decide. One loop cannot serve all of that well.

So each kind of work is its own agent app. None of them brings its own agent machinery: each brings a workflow graph, a window and the rules for where it must wait. Everything else is shared.

The shared substrate

Four things live in the Paramus kernel and nowhere else:

• The engine. Every piece of agent work is a run. A run can pause, survive a restart and resume exactly once.
• Principals. Every step is done by someone: a human, or an agent population with its own grants – science, ontology, coding, QA, compute. Agents can read, propose and modify. No agent can validate; that stays with people. A helper an agent starts gets the intersection of its own grants and its parent’s, never more.
• Gates. The places where a run waits: a human vote, a benchmark that must pass, a licence check, a confirmation before an expensive or physical step.
• Provenance. Every tool call is recorded in the workflow graph: who did it, with what, producing what.

The rule is simple: no capability lives only in an agent app. If one app needs it, the kernel provides it, and the other five get it too. The kernel and its measured properties are described in A scientific kernel for agentic architectures (Paramus, 2026, Zenodo).

The six apps

chat – the assistant. One conversation, tools from the whole catalog, a plan the agent writes down and keeps up to date, and a strip that shows when it waits for your confirmation. A chat that grows into a campaign hands over to discovery or dmta.

discovery – the long campaign. For a question that takes days: “find what determines filtration in these 400 runs”. It proposes tasks, runs helpers in parallel, checks every claim deterministically and keeps only what survives. Next to the results sits an abstention list: what the tools refused to answer. Nothing enters the knowledge base without a check.

dmta – the experimental campaign. Design, Make, Test, Analyze, round by round toward a target such as “Tg above 230 K, particles below 50 nm”, within a budget. Make has a hard stop: the protocol the robot is about to run, and an Approve button. The planner proposes; the chemist decides.

scr – the scientific change request. One change to the scientific model, from observation to release, through fixed stations: observed, proposed, scientific review, requirement, implementation, validation, staging, human acceptance. Two of the stations belong to people, and no agent can skip them.

autonomy – what runs on its own. The scheduled work: a tick that reads the workspace, nightly mining of observations into proposals, regression sweeps over the tools, retraining. Every scheduled run is a normal run with a principal and a trace, listed in one window, so nothing happens overnight that you cannot see in the morning.

coding – requirement to pull request. One requirement becomes one reviewed pull request. The agent that writes the code and the agent that reviews it are different principals with different grants. The default branch is reachable only through a maintainer’s vote.

What ties them together

One window belongs to none of the six: the runs list. It shows every run from every app and, for the ones that wait, who they wait for. In the morning a chemist might see a robot protocol waiting in dmta, a proposal in scr and a confirmation in chat. That list is what makes six architectures one system.

The apps also use each other: dmta can run the discovery graph for its literature phase, and an observation in chat can become the start of a change request.

More: Four Graphs: How an AI Lab Knows What It Knows

FAQ