AI Agent Runtime for Coordinated Work | Dweve Nexus

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Coding agent and operator assistance. Demo metrics are illustrative.

Terminal, search, lint, test, git, and more.

Remembers your codebase and team context.

Specialised agents collaborate across concerns.

Review diffs, request changes, final sign-off.

Replay any session bit-for-bit when something needs review.

Autonomous agents that write code and keep receipts

to handle network timeouts, 5xx responses, and idempotent-safe conditions. Pure helper, fully unit-tested.

Input, policy, reasoning on one artefact

formed around one task, and it shows its work

intent, scope, content, ethics, anomaly, runtime

objective obj-281 · team 5 specialists · cycle 1/1

The runtime for executable organisations · one objective, one formed team, one trace

run decision · hold payment to vendor v-281

sign · M. Bos, ops-3 · 2026-04-12 09:14 CET

account · constraint trace sealed, replayable end to end

Working, episodic, semantic, procedural, knowledge base

one objective, one accountable operation

Bring Nexus an objective that currently crosses people, systems, rules, and approvals. See how the work is decomposed, how the organisation forms, how authority is assigned, how failure is contained, and how every contribution returns to one accountable outcome.

Every contribution returns to the objective

Pipeline, fan-out, delegation, blackboard, debate

Dweve Nexus, the runtime for Executable Organisations

Nexus is a Python multi-agent runtime for work that needs more structure than a prompt loop. Its implementation separates agents, task lifecycle, workflows, memory and capability-based routing into distinct components. Python builders, DweveScript and a CLI define and run that work.

Capability matching, explicit requirements

Use the Python builders, DweveScript or CLI to define agents, tasks and workflows for the work you need to coordinate.

Python builders, DweveScript and the CLI

Working, episodic, semantic, procedural and knowledge

Deductive through hybrid, selected for the task

Dweve Nexus, every task gets its own team

Most AI tools give every job to the same assistant. Nexus works differently. Behind Fabric it forms a team around what you asked, sends each part to the specialist suited to it, and returns one result through the conversation you already opened. You ask once. Nexus organises everything behind it.

Ask once. Let Nexus form the team, divide the work, bring the pieces together, and return one result. The organisation works for you. The authority remains with you.

Typed handovers keep the runtime coherent. Whoever signs for the work reads something else.

The current implementation provides Python builders for agents and a DweveScript compiler for declarative agent and workflow definitions. Its CLI parses, compiles and runs DweveScript files. These are complementary interfaces to the same Python implementation, rather than claims of equivalent Rust, TypeScript or Go clients. A definition written in one of them is the same definition when read from the other, so a team can move between the declarative file and the builder without maintaining two descriptions of the same organisation.

Alongside point to point messages runs a typed event bus, which is what a group of agents actually coordinates on: task requests and results, acceptance and rejection, claims and releases, and lifecycle and health events, with subscribers able to filter, forward, drop and transform what they receive. Two kinds of state are deliberately kept outside individual messages. A blackboard is a declared structure that agents read and write, so a contribution is legible to something other than whoever wrote it.

Events, and the state that is meant to be shared

A handover in Nexus is a value with a shape rather than a paragraph one agent hopes another parses. The protocol layer carries A2A compatible types for messages, tasks, artefacts, capabilities, skills, roles and statuses, and JSON is one way to put those on a wire rather than the type system itself. Tools and outside systems arrive by contract, and Model Context Protocol is supported as one of those boundaries where a customer wants it. A receiving component can validate that shape before it acts, and the trace keeps the handover inspectable. JSON is a transport choice; it does not replace the contract.

Replay answers what happened. What the parts hand each other is typed as tightly.

Nexus has separate components for routing, workflow execution, communication, reasoning, memory, safety and recovery. That separation makes it possible to inspect the relevant component when work behaves unexpectedly, rather than treating every failure as a prompt problem. Each component records what it decided at the moment it decided it, so the question after an incident is which component changed rather than which sentence was worded badly. That record is what a replay reads back.

Captured replay reuses the recorded outputs of every external call and reconstructs the original run, which tests the runtime's own decisions with the outside world held still. Live replay calls the dependencies again and compares, which is the test that can fail and therefore the one worth running. Captured replay answers whether the runtime made the same decisions with the outside world held still. Live replay answers whether today's dependencies still produce the same result. The comparison is therefore a test of the environment, not a second copy of history.

All of that can be watched live. What the runtime decides for itself is settled before it runs.

Structured events are emitted per entity, and the deployment decides which store receives them: bounded memory on a development estate, a persisted store in production, and append only or tamper evident storage where the record has to stand up to somebody outside the building. Each of those is called what it is. The runtime does not call ordinary mutable logs immutable, which is the difference between evidence somebody accepts and a claim they test. Events retain their entity and storage posture.

The kinds of entity take different questions, and the asymmetry is the useful part. Asking an agent how healthy it is makes sense, and asking an operation the same thing does not, because an operation is either blocked or it is not and its health is only the health of whoever is inside it. A unit of work has a deadline and a count of retries, and a group has neither: what a group has is a membership and a record of what it has worked on. Since no two of those sets match, one flat stream of lines answers all four badly.

A production question is rarely what a log said. It is which unit of work missed its deadline, which agent is unhealthy, which part of the operation is blocked and on what. Nexus reports state on the same things it executes, so the question goes to whatever owns the answer instead of being assembled out of lines that happen to mention it. That makes the question addressable without replaying a conversation. The state belongs to the entity that owns the work, so a missed deadline, unhealthy agent or blocked operation can be investigated from its record and current condition.

Recovery is something you are told about. Watching it as it runs is a different demand.

Two consequences an engineer can use. Because the wait is a deterministic fixed point computed from the attempt number rather than a draw from a random source, the schedule of a failed run is part of what replays, so an argument about how long yesterday took has an answer rather than a theory. And because the circuit belongs to the agent rather than to the kind of work, one failing dependency stops routing to one place while the same work stays routable everywhere else. Every substitution is written down as it happens: the reroute names the replacement agent and the state that travelled with it, so a rescued run reads afterwards as one piece of work with a recovery inside it.

Something will fail, and the interesting question is not which response gets chosen. It is what stops the recovery from becoming the workload. Every part of it is bounded before the trouble starts: how many attempts, how long each wait is, how much of the allowance a rescue may spend, and how much of the estate one bad dependency takes with it. Nothing here ends because a loop decided it had tried hard enough. The runtime records the attempt number, computed wait, circuit state, replacement and state carried across. That gives an incident review a bounded path to inspect: a retry can be replayed, a closed route can be explained and a terminal failure can be distinguished from a rescue that finished.

Policy decides what may happen. Something has to decide what happens when it will not.

Alongside policy, a set of checks looks for the operational failures a well behaved single run never shows you: the same work assigned twice, a task type with no qualified owner, resources committed beyond what exists, an agent being starved, and latency bounds being missed. Each one is an operational invariant evaluated against the live estate rather than against a diagram, and a check that fires names the entity it fired on, so the fix goes to an agent rather than to a theory about the design.