cirwel/unitares

A self-hosted record your agents write to. After a restart or handoff, the next
agent can look up who claimed what, on what evidence, who disputed it, and what
replaced it.
Agent work outlives the process that started it. A coding session restarts, a
research agent loses its context, a task moves to another runtime. Logs show
each run, but not the thread between them. Without that thread, the next agent
can repeat a dead end, act on a claim that was already corrected, or lose the
evidence behind an earlier decision.
UNITARES is a server you run that keeps that thread. Agents connect over MCP or
HTTP (with ready integrations for Claude Code, Codex, and Hermes Agent) and
write their 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.
## What the record answers
| Question | Mechanism |
| Who said it? | Identity and lineage: every write to the record is bound to the process that made it, and a successor can declare which process it continues. |
| What supports it? | Claims and evidence: findings keep their sources and corrections outside any single context window. When a newer finding replaces an older one, the older one links to it. |
| Who challenged it? | Governed review: objections, conditions, and their resolution stay on the work they concern. Asking for review is not the same as passing it. |
| What happened? | Outcome grounding: test, build, and task results are recorded against the check-ins that predicted them. |
| What can a successor recover? | Reconstruction: a new process can search or export prior findings, open review conditions, and outcomes before it acts. |
Two more pieces sit around the record. Runtime policy: each check-in returns
proceed, guide, or pause, with a reason; a pause refuses that process's
check-ins and new findings until review or recovery lifts it or it expires.
Second opinions: consult asks another connected model (Claude, Codex, Antigravity,
or local Ollama) and keeps the answer with the task.
## See it
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) picks up A's task after a restart 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 that it continues A's task.
text
# Agent A (Codex)
startsession {"forcenew": true} -> agent A's id
storefinding {"summary": "upload retry test is flaky", ...} -> finding a
recordresult {"outcometype": "testfailed", ...}
# Agent B (Claude Code), in its own session, later
startsession {"forcenew": true} -> agent B's id
storefinding {"summary": "upload retry fails on clock skew", ...} -> finding b
usetool {"toolname": "knowledge", "arguments": {"action": "supersede", "discoveryid": " ", "supersedesid": " "}, ...}
# Agent C (Hermes Agent), after A's restart
searchsharedmemory {"query": "upload retry test"} -> finding a (superseded, points to b), finding b
startsession {"forcenew": true, "parentagentid": " ", "spawnreason": "explicit"}
Nothing forces an agent to read the record; the Claude Code and Codex plugin's