UNITARES

Accountability infrastructure for long-running AI agents.

A self-hosted record your agents write to. Across sessions and runtimes, any agent or operator can look up who claimed what, on what evidence, who disputed it, and what replaced it.

Agent work outlives the process that started it. Git, scratchpads, and handoff notes carry code and in-flight task state; UNITARES keeps the shared record of claims, reviews, and outcomes across runs. When a finding is corrected or a change is challenged, the next session reads the updated record instead of acting on a superseded claim.

UNITARES is a server you run that keeps that record. Any agent or model that speaks MCP or HTTP can connect (with ready integrations for Claude Code, Codex, and Hermes Agent) and write its findings, reviews, and results to one operator-owned record. A later agent, or you, can read it back and see where each piece came from.

[See one incident without installing anything →](https://cirwel.github.io/unitares/demo.html) · Read the evidence · Install

What the record answers

Digital proprioception runs on the check-in path: EISV summarizes behavioral observations over time and returns state feedback and a policy recommendation (computation contract). Second opinions let consult ask a connected local or orchestrated model, and structured dialectic records thesis, challenge, and resolution on the work.

See the record before installing

Agent A (Codex) finds a bug, records it, and exits. Agent B (Claude Code) later finds the real cause and records a finding that supersedes A's. Agent C (Hermes Agent) works on the same area in a later session and reads the record before touching the code (reading needs no identity): its search returns A's finding marked superseded, with a link to B's. C then declares lineage from A. This API sketch is separate from the hosted service-reload incident.

# Agent A (Codex)

start_session {"force_new": true} -> agent A's id store_finding {"summary": "upload retry test is flaky", ...} -> finding a record_result {"outcome_type": "test_failed", ...}

Agent B (Claude Code), in its own session, later

start_session {"force_new": true} -> agent B's id store_finding {"summary": "upload retry fails on clock skew", ...} -> finding b use_tool {"tool_name": "knowledge", "arguments": {"action": "supersede", "discovery_id": " ", "supersedes_id": " "}, ...}

Agent C (Hermes Agent), in a later session

search_shared_memory {"query": "upload retry test"} -> finding a (superseded, points to b), finding b start_session {"force_new": true, "parent_agent_id": " ", "spawn_reason": "explicit"}

The Claude Code and Codex plugin's session start points each new session at the record. For a complete call-by-call sequence, see the captured two-process walkthrough.

Install

Homebrew preview, recommended for an Apple Silicon desktop Mac: the cirwel/unitares tap installs the services natively; follow its install and first-time setup. The packaged unitares update coordinates writer shutdown, verified backup, migrations, prior-state restoration, and deep health when writers restart (schema verification when they remain stopped); kegs that predate it use the tap's one-time manual transition.

Docker Compose, on any platform: with Git, curl, and Docker Compose installed, one command starts the latest published release of the local stack (the server, PostgreSQL with AGE and pgvector, Redis, and the coordination plane; add docker-compose.full.yml for local semantic search and hybrid ranking, or use the core profile to run only the first two):

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

• Endpoints and updates: connect MCP clients at http://localhost:8767/mcp/, or open the dashboard at http://localhost:8767/dashboard (Docker quickstart). On Docker, ./scripts/unitares update backs up the database, applies migrations, and verifies deep health (updating).
• One stack per machine: Docker and Homebrew keep separate data (installation choices). Container names are fixed, so run docker compose down (without -v) in an earlier checkout before starting another (stop is not enough, because stopped containers still hold their fixed container_name values, and restart: unless-stopped revives un-stopped containers when the Docker daemon restarts), or use the managed launcher (scripts/install/launch.sh), which checks ownership first.

Connect your agents and models (Integrating agents):

• Claude Code and Codex: unitares-governance-plugin wires MCP, lifecycle hooks, skills, and per-file edit leases (via the stack's lease plane, so concurrent work in the same checkout does not overwrite another agent's file).
• Hermes Agent and OpenAI-compatible clients: the host adapter.
• Any other agent, model, or hosted connector: Streamable HTTP MCP (with npx mcp-remote for stdio-only clients, or Bearer / OAuth on a dedicated public listener for hosted connectors like Claude.ai and ChatGPT), the Python SDK (pip install unitares-sdk), or the resident agent runtime.
• Optional server-side models ([choose a model](docs/manual/02-install.md#choose-a-model-optional)): no model connection is configured by default; the core record runs model-free with no API keys. Run ./scripts/unitares model to connect a local OpenAI-compatible server (Ollama, vLLM, LM Studio, llama.cpp) for consult and in-process review, or add the agent orchestrator for cross-family CLI review.

Who it is for

For an operator running several long-lived AI agents across vendors on infrastructure they control, who wants one queryable record of identities, findings, reviews, and outcomes across the fleet.

UNITARES works alongside Git, issue trackers, handoff notes, scratchpads, evals, and guardrails: those carry code, task state, and runtime checks, while UNITARES keeps the shared record that ties the agents' claims, reviews, and outcomes together. Each agent keeps its own loop and model. Inferred pauses are advisory by default, and the operator decides when hard holds are enforced. Identity, authorization, archive, and coordination boundaries are enforced by the server.

How it fits together

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. Together this is an operator-owned accountability layer for coding, research, background, and resident agents. What it adds to an activity log is lineage and supersession: claims and evidence, reviews, and outcomes stay bound to the process that recorded them, and a replaced claim points to its replacement, for review and for reconstruction later.

Storage is PostgreSQL (with Apache AGE for supersession graph links and pgvector for embeddings) and Redis, with no required external model API. The check-in's behavioral state estimate is a form of runtime proprioception; its policy recommendation is retained in the record and is advisory by default, with optional hard-hold enforcement.

Empirical evaluations, operational measurements, and scope are documented in Evidence and limits and the Reviewer Guide.

Start here

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](