Agent collaboration,
with evidence

What you can verify

Radia keeps the three questions behind a handoff connected.

These records make successful work inspectable. MCP tracing adds the other half for agent testing: calls that failed or matched nothing before they could leave a record.

Coordination without blind trust

Direct calls make each participant depend on the identity and interface of the next one. Adding a capability can require changes to every caller that might use it. This becomes difficult when agents are deployed independently or owned by different teams.

Radia stores work as records. A worker registers a pattern such as { kind: "document", match: { type: "scan" } } and claims records that match it. Publishers do not hold references to workers or choose a destination.

Starting a worker makes its pattern available to the space. If no eligible worker is running, matching records remain available until one can claim them.

Discovery is only half of the boundary. The publisher does not decide which worker receives the record, and the worker does not decide what it is allowed to see. Radia combines the worker's requested pattern with grants assigned by an operator and applies the same policy to its output. A faulty or compromised participant cannot recover broader access by asking for everything or by skipping an application-level check.

Two kinds of provenance

Radia keeps authority provenance and data provenance independent. A claimed lease identifies the run allowed to act; data-parent links identify the records that influenced a result. Naming a privileged record as a parent grants nothing, and a privileged worker does not erase the handling labels inherited from untrusted input.

See the complete trust model →

What the boundary enforces

The runtime, storage and any credential-holding host remain trusted components. Sandbox strength depends on the advertised backend and its probe; labels are coarse barriers, not a general information-flow system. Radia makes these boundaries explicit rather than making every worker reimplement them.

Authorization by record content

The recorded run above shows attribution and lineage. A document worker shows the other side of the boundary: authorization can depend on the contents of the work itself. A summarizer may process public filings while remaining barred from confidential ones, regardless of which implementation claims the work.

A grant identifies a principal, an operation and a record kind. An optional pattern restricts the grant to records whose contents match it.

{ "principal": "agent:summarizer",
  "kind": "document",
  "operations": ["take", "query"],
  "pattern": { "classification": "public" } }

The runtime applies the grant while selecting a claim. The worker receives only records that satisfy both its request and its grant.

This makes the payload part of the authorization decision, rather than leaving the check to agent code. Read about authorization →

Immutable records, mutable claim state

A completed worker does not update its input. It writes a result record that names the input as a parent. The original document remains unchanged.

A result is another routable record. Downstream workers match it in the same way they match an initial request, and parent links preserve how each result was produced.

Follow one document through the whole system →

Getting started

One command starts a space with storage, a web console and a credential already provisioned. The shortest useful exercise posts a record, claims it and returns a linked result.

$ curl -fsSL https://radia.sh/install.sh | bash
$ radia dev                          # space + console, in one process
$ radia put document '{"type":"pdf","classification":"public"}'
$ radia take document --lease 30 --json > claim.json
$ radia ack - --result-kind summary --result '{"text":"..."}' < claim.json

The installer fetches a prebuilt Linux or macOS binary and verifies it against the release's checksums. On Windows, run it in WSL2. To work from a checkout instead, use deno task dev; deno task compile builds the same standalone command. The SDK packages are assets on the same release, listed in the same checksums, and carry zero dependencies, so an install fetches nothing from any registry. They are not on npm or PyPI today; the pinned URL is the supported install.

$ npm install https://github.com/wistrand/radia/releases/download/v2026.9.5/radia-2026.9.5.tgz
$ pip install https://github.com/wistrand/radia/releases/download/v2026.9.5/radia_space-2026.9.5-py3-none-any.whl

radia update replaces that binary with a later release, verified the same way. radia update --check reports whether one exists and changes nothing, exiting 1 when there is, so a scheduled check is yours to write rather than something the runtime does on startup. Releases carry checksums and no signature.

import { RadiaClient } from "radia";
import { agentLoop } from "radia/loop";

await agentLoop(new RadiaClient(url, { token }), {
  name: "summarizer",
  patterns: [{ kind: "document", match: { type: "pdf" } }],
  handle: summarize,
});

What is built

Radia currently runs on SQLite and PGlite for embedded use and PostgreSQL for multiple runtime instances. The same storage contract suite covers all three adapters.