UNITARES

An agent reports that its fix is done and the tests pass. By morning its session has restarted, its context is gone, and another process has taken over the task. Who said it? What supports it? Who challenged it? What happened? Each run leaves its own log, and the answers scatter across them.

UNITARES is self-hosted accountability infrastructure for operators running multiple AI agents. Its single-operator federation kernel connects independent runtimes to one operator-controlled server over MCP or HTTP, where they share a durable record while keeping their own models, tools, and runtimes. They interoperate with each other over their own transports or A2A; UNITARES is the record behind them, not the transport between them.

UNITARES preserves accountability across discontinuities in agent identity, context, process, and time. Agent work remains attributable, reviewable, and recoverable even when the process that started it is gone.

What UNITARES gives you

• Identity and lineage — know which process acted and where inherited work came from. This is a record for attribution, not a credential; platform workload identity remains the credential layer.
• Claims and evidence — retain important findings, corrections, and their provenance outside any one context window.
• Governed review — preserve disagreement, conditions, and resolution as part of the work record.
• Outcome grounding — connect predictions and check-ins to what later happened.
• Runtime policy — return an action, reason, and next step at meaningful checkpoints in an agent's loop.
• Reconstruction — give a successor the records needed to understand and continue earlier work.

The claim ledger gives the evidence status of each measured result.

Together, these form an operator-owned accountability layer across coding agents, research agents, background agents, and custom runtimes. What it adds to a record of what happened is adjudication: disagreement, conditions, and outcomes bound to the process that made the claim.

Install

With Git, curl, and Docker Compose installed, one command starts the latest verified release of the local operator stack:

v=$(curl -fsSL https://raw.githubusercontent.com/cirwel/unitares/master/PUBLISHED_VERSION) && git clone --branch "v$v" --depth 1 https://github.com/cirwel/unitares.git && cd unitares && docker compose up -d --wait

Connect MCP clients at http://localhost:8767/mcp/ or open the dashboard at http://localhost:8767/dashboard. If port 8767 or 8788 is taken, set GOVERNANCE_HOST_PORT and LEASE_PLANE_HOST_PORT; see Docker quickstart.

An agent starts with start_session(force_new=true) and passes the returned client_session_id on every later call, which ties its writes to its own process; see Integrating agents.

This provisions the server, PostgreSQL with AGE and pgvector, Redis, and the coordination plane.

Data lives in Docker named volumes keyed to the Compose project name, which is the checkout directory name (unitares). Re-running the one-liner therefore reuses an earlier install's database. For a clean start, run docker compose down -v in the old checkout first. See Reinstalling.

From the checkout, ./scripts/unitares model points the server at a model you run with Ollama, which turns on advisory consult answers and a first reviewer for dialectic reviews; without one, a review waits for a peer or the operator. ./scripts/unitares update later moves the install to the newest release: it backs up the database before any migration, applies them, restarts, and checks health. See Choose a model and Updating, which also covers the one-time step for installs made before update existed.

How it works

An agent joins the operator's UNITARES deployment and receives a process identity. During work it can publish selected findings and evidence, request structured review, report meaningful state transitions, and record outcomes. UNITARES keeps those records available to the operator and to later authorized processes.

The server runs alongside evals, sandboxes, and guardrails. It provides the continuity and accountability layer that connects their outputs over time. Core storage is self-hosted and runs on its own; the operator chooses which inference providers and integrations to connect.

Its EISV state model is runtime proprioception: a way to make changes in an agent process visible so operators can diagnose and act on them with evidence.

Where it is going

UNITARES is working toward an operator experience where a fleet can be brought under accountable operation in one step: identities are configured, handoffs are enforceable, important evidence survives, reviews bind to the work they govern, and outcomes are recorded where the next decision can use them.

The larger aim is infrastructure for agent systems that can accumulate useful experience without losing authorship, challenge, or operational control as they grow.

Start here

Goal	Guide
Operate a deployment	Operator manual
Connect an agent or application	MCP integration · Python SDK
Understand the product and architecture	Product definition · Architecture
Evaluate the claims	Evidence and limits · Reviewer Guide · Public dataset
Contribute	Contributing · Development guide

The documentation index covers deployment profiles, operations, security, compatibility, research, and the full tool surface.

Ecosystem

UNITARES works with the governance plugin for Codex and Claude Code, the host adapter for Hermes Agent and OpenAI-compatible clients, the public Python SDK, and the resident agent runtime. These are separate userlands connected by the same operator-owned record.

Citation and license

Kenny Wang (ORCID 0009-0006-7544-2374), CIRWEL Systems. See CITATION.cff for the versioned citation.

@misc{wang2026unitares,
  author = {Wang, Kenny},
  title  = {{UNITARES}: Information-Theoretic Governance of Heterogeneous Agent Fleets},
  year   = {2026},
  doi    = {10.5281/zenodo.19647159}
}

Apache License 2.0. See LICENSE and NOTICE.