The repository includes a coordination pipeline, a multi-process chat application, a content-keyed analysis application and a load generator. Only live model calls require an API key; the automated suites use deterministic providers.
Run deno task demo to start a planner, two workers and an aggregator. The planner
emits pieces, each worker claims the kind it handles and the aggregator writes a summary after
all results arrive.
The four programs do not import or address one another. Their integration consists of the kinds and patterns they publish to the shared space.
Open the console while it runs and you can watch records appear and change colour as they are claimed and answered.
Run deno task chat-test for the no-key suites, or deno task chat with a
configured provider. The application separates the client, model routing, inference, tool
execution and code execution into processes with distinct credentials and host permissions.
The terminal client writes a request record and renders result records. Workers perform model and tool calls independently, so a terminal restart does not terminate an active turn.
a message // what you typed
a request // no model named: the chat does not choose one
a request // a router picked a model and asked again
some chunks // the reply, streaming in
a reply
a tool call // whichever worker offers that tool claims it
some progress
a tool result
a verdict // written by the runner, not by the model
a reply // carrying the provider's own token and dollar figuresConversations persist as record threads and can be resumed by name. Code checks are written by the runner under a kind the assistant cannot write, keeping model claims separate from execution verdicts.
Tool workers advertise schemas and descriptions as records. The assistant watches those records to build the model's tool list, so a newly deployed worker is available on the next turn without client configuration.
Replies retain provider-reported token and cost fields for later queries. Model tiers are also records, allowing routing and escalation workers to read the same active registry.
With --encrypt, message prose, tool arguments and tool output are encrypted while
routing fields remain readable to the runtime. Conversation keys live in shreddable artifacts,
allowing the prose to be erased while records, lineage and the event chain remain.
Run deno task analysis to start a web application with sign-in, CSV upload and
staged processing. The application relays the browser's token and holds no service credential.
Each stage is keyed by dataset, input digest and code digest. Completed work is found by query. Changing code or input creates a new key for that stage and its descendants; unchanged stages reuse their existing artifacts.
The code that runs is a record too. Each stage lives in a workspace tree named by its digest, and that digest is the same value the work request carries and a promotion grant pins. So a stage can only ever be handed work naming its promoted tree, and a result claiming any other digest is refused at the moment it is written. The question every cached answer rests on, which code produced this, went from a field a worker reported to a fact the grant table enforces in both directions. The code itself runs in a jail holding no credential: a generic host fetches its input under the stage's own permission, and stamps its output with the person the work was for, so that person's scope reaches bytes an agent computed on their behalf.
And the pipeline's shape is itself data. The list of stages is a registry the planner and the page both read, so adding a stage is a deployment: store the tree, declare where it goes in the order, promote its digest, bind it. The example's own test does exactly that, deploying a fourth stage into the live pipeline while it runs, and only the new work computes; nothing restarts and no process that was already running learns anything. A tree authored anywhere qualifies, including one an agent wrote in conversation, because deployment names a digest and nothing else.
planner.ts. Deciding it depends on what you consider an
input. Everything else (the DAG, the routing, the leases, the audit, and now which code may
answer) is already there. That split is the property to look for in any coordination runtime: the part
left to you should be the part only you could know.
Start a space and there is a web console at the same address. It is built on the public API, so it can only show you what any other client could ask for.
Overview ranks what deserves attention, and every finding links to the records it rests on. Feed is a live view of everything happening. Graph draws how records connect, a conversation and its messages, a job and its pieces, with a waterfall view that reads like a trace: time as the axis, so you can see which tool the seconds went to. Kinds draws who is listening for what right now, mined from live declarations rather than configuration. Space arranges every record by what it is rather than by what it links to, so a fleet doing something odd shows up as a cluster that should not exist. Flows renders the recurring shapes with their evidence. Auth shows who exists and what they may do.
Whatever you are looking at is in the address bar, so you can send someone a link to it, and it survives your session expiring while you are in the middle of looking at something.
Here is a problem this design creates for itself. If nothing declares how work flows, there is no diagram to look at. New people ask where the workflow is, and no file holds one.
So it gets worked out from what happened. Take everything that is causally connected, reduce it to the sequence of steps involved, and count how often each shape occurs.
180x 100% n= 2 1.3s a request → a reply
104x 100% n= 7 7.6s conversation ⇒ request → request + message → reply
73x 100% n= 4 810ms conversation ⇒ tool call → message + result
3x 100% n=10 229ms job → pieces ×4-7 → results ×4-7 → summaryThe bottom line is the pipeline from earlier, found without anybody describing it. The columns are how often it happened, how often it finished, how many records were involved and how long it took.
Shapes that start and rarely finish show up next to the ones that work, which is usually the most useful thing on the screen. A job nobody ever picks up and a job whose worker keeps crashing look identical in a log, and they need completely different fixes.