Nine ways a chat thread fails, and the mechanism against each.
One line per mechanism. Every one is shipped and demonstrable on a live node; there is no roadmap on this page.
- Versioned content. A git-backed store snapshots human-authored content per workspace and baseline. Each tenant gets its own repository.
- Durable runs. Every run keeps a transcript that survives a browser reload, and its documents and apps are tied to the run id.
- Specialist journals. Each specialist’s contributions are recorded per plan and readable afterwards.
- Resettable workspaces. A workspace is built from a baseline and can be destroyed and rebuilt from it, or promoted into a new one. The tree resets; the specialists and what you taught them survive.
- Rolling memory. Past twenty messages, the oldest half is summarised and archived. Later turns load the summary, not the raw thread.
- Per-step context. A step receives only the handoffs its plan names, and only the tool servers it is granted.
- Vault and runtime files. Credentials stay in the vault. A runner reads a per-integration file rewritten on rotation, so a changed key applies on the next call without a restart.
- Scrub at spawn. A fixed list of platform secrets can never reach a child process.
- Gateway injection. Provider keys are added to outbound requests at the egress gateway, never inside the model. Outbound hosts are allow-listed per vendor.
- Hard ceilings. A dollar ceiling per run and per tenant, plus a cap on concurrent workers, host-side, and halting rather than warning.
- Priced approvals. A pre-run cost estimate turns the approval gate into an economic decision.
- Ledger and invoice. An append-only token ledger per run, and a monthly breakdown by specialist, plan and model.
- Forged specialists. The foundry takes a domain brief and writes a full specialist: an oath naming that field’s real temptations, testable commitments, and competencies each bound to the oath.
- Named actors. Every audit entry names the run, the specialist and the human. Every approval carries the operator’s name.
- Stop and kill switch. An operator stop marks the run halted before anything is torn down, so nothing respawns. Spend ceilings halt a run rather than warn.
- An approval queue. A plan that declares a decision submits cards to an inbox where a named human approves or rejects. What an approval may do is a closed vocabulary the agent cannot extend.
- Hash-chained ledger. Each entry hashes its predecessor. Reorder, delete or edit one and verification names the first broken entry.
- Scrubbed before signing. Secrets are removed before an entry is signed or stored, and a daily append-only file is kept as a second sink.
- Erasable on request. Transcripts support a per-run erase for data-subject requests without touching the chain.
- Two kinds of drift. Verification tells plan drift from specialist drift and blocks either before a run starts.
- One pre-flight. Scheduled runs pass the same check as a manual run, so the two paths cannot diverge.
- Re-sign, never accept. A changed specialist triggers a re-sign flow. An unsigned plan that requests any capability is refused.
- Signed with a key. A plan’s digest is keyed to the node, so a plan or specialist edited outside the console fails verification before the run rather than after it.
- A governed API. Versioned routes with machine keys, per-tenant scoping, rate limits and scope checks on every call.
- One image, signed. The same image serves development and production. The pipeline builds and signs it, the deploy verifies it, and only git reaches a box.
- Versioned, and pinned. Every release carries its version and build on the health endpoint, and a pack declares the platform range it needs: the installer refuses a mismatch.
- Posture you can read. A page listing every enforcement toggle at its live value, and every installed integration with the hosts it may reach. Read it
Planned and reviewed here. Written by a coding agent.
We run Agentic Ensemble on Agentic Ensemble: the research, the plans, the decisions and the reviews. What we did not do is write the source code in it, because that is not what it is for. The code was written by a dedicated coding agent, directed by the specifications this system produced, and reviewed here before it shipped. The plan that ran the review is published.
Specified here. Every feature began as a written plan: what it should do, what it must not do, and how we would know it worked, approved by a person before any code existed.
Decided here. Plans were reviewed and amended in place, with the decisions a builder may not reopen written at the top. What changed hands was a document, not a conversation.
Written by a coding agent. A dedicated coding agent did the implementation, working from those specifications rather than from memory of a chat. The right tool for that job, pointed at a precise brief.
Reviewed here. Specialists built for security review audited the code in three cycles, writing one document per finding, with the file, the line, the fix and the test. Every review stays on the record with the work.
Watch the mechanisms run.
Every line above is visible in the console. We open one, point it at a goal of yours, and you see which of these fire and where.