Independent · Single-operator · Est. 2025

CIRWEL Research

— The running system, in detail

How UNITARES
fits together.

UNITARES puts identity, evidence, memory, runtime state, review, policy, and coordination behind one shared contract. Different models and agent harnesses can use the same accountable layer without becoming the same agent system.

The home page explains the problem. This page shows the shape of the system, then goes deeper into identity, shared memory, verdicts, and the workloads CIRWEL runs on top of it.

— The receipts

Core
CIRWEL/unitares · Apache 2.0
Contract
unitares-sdk · identity, check-ins, evidence, memory, policy
Research
UNITARES paper · Wang, 2026 · CC-BY 4.0
Production
In continuous operation since November 2025 · CIRWEL's own deployment
Vocabulary
Public glossary · terms, definitions, and drift corrections

§01 — System shape

Core, contract, userland, workloads.

UNITARES is the layer around agent work, not the agent loop itself.

The core owns identity, provenance, longitudinal state, policy and recovery, audit, shared knowledge, review, and coordination. The public SDK is the contract agents depend on. A first-party resident userland exists, but it is optional: Claude Code, Codex, Hermes, or a custom runtime can speak to the same contract directly.

Underneath, the deployed service uses PostgreSQL with AGE and pgvector, Redis for transient state, and MCP/REST interfaces. Those are implementation details of the shared layer, not requirements on the model or conversation loop above it.

  1. Core

    CIRWEL/unitares

    Identity, evidence, state, policy, recovery, audit, memory, review, and coordination.

  2. Contract

    unitares-sdk

    The public client surface an agent uses to identify itself, check in, attach evidence, read policy, and participate in shared memory.

  3. Userland

    optional

    Conversation loops, model providers, tools, scheduling, and queues remain outside Core.

  4. Workloads

    yours

    Coding sessions, research agents, residents, services, or whatever else you run. A fresh install starts without CIRWEL's roster.

§02 — Identity & lineage

Process attribution is recorded, not reconstructed.

Names are labels. Identity is bound to the process that acted.

Fresh processes mint fresh identity by default. When continuity or lineage matters, it is explicitly declared rather than inferred from a reused display name. Labels retain their source so an auditor can distinguish operator-assigned, self-claimed, and system-generated descriptions.

This adds friction at session start in exchange for a clear chain of attribution across claims, evidence, reviews, and coordination.

§03 — Shared memory

Findings survive the process that discovered them.

Agents and operators search the same provenance-tracked knowledge surface.

Discoveries, decisions, review outcomes, and findings are stored with source, status, and lifecycle rather than disappearing into one chat history. The deployed store combines relational data, Apache AGE, and pgvector retrieval.

The important property is not the graph technology. It is that later work can recover what was learned, who recorded it, and whether it was superseded or resolved.

§04 — Policy & review

Advice, evidence, and authority stay separate.

A check-in can return a proceed or pause policy action with a named reason. Advisory consultation can add model evidence without becoming a decision. Structured review records disagreement and conditions rather than silently replacing the original author or operator.

When a governed surface is paused, recovery is recorded as a separate event. Actions outside UNITARES-owned surfaces remain the host's responsibility.

§05 — CIRWEL's workloads

The deployment is evidence, not the architecture.

CIRWEL uses UNITARES across long-running resident agents, short-lived coding sessions, operational monitors, and an embedded Raspberry Pi testbed. Those processes are deployment configuration. They demonstrate that the same contract can span different lifetimes and runtimes; a fresh installation does not inherit them.

§06 — Public surfaces

What you can use from outside.

Each of these is described here as a surface. The build page is how you actually reach one.

Server

UNITARES Core

CIRWEL/unitares exposes MCP, REST, a dashboard, and the governance runtime.

Client contract

unitares-sdk

pip install unitares-sdk gives custom agents the public identity, check-in, evidence, memory, and coordination interfaces.

Optional userland

UNITARES Resident

CIRWEL/unitares-resident is the first-party agent userland built on the same public contract; it is not part of Core.