Republic of Autonomous MachinesAgentic Operating System

Concept

Trust & transparency

ROAM is private by architecture. Nothing about that is rhetoric. This page documents exactly what runs on your machine, what ROAM never does, where files live, and how to remove it cleanly when you want it gone.

What runs on your machine

ROAM is two processes when fully running. Both run on your machine.

  • The daemon. A Node.js process that listens on a Unix domain socket inside your session directory. It coordinates agents, signs actions, runs drift sweeps, and writes journals. It does not bind to a network port. It does not accept TCP connections. The only way to talk to it is through the socket file, which is owned by your user with 0o700 permissions.
  • The dashboard server (optional). A small HTTP + WebSocket server on localhost:7777 by default, used only when you launch roam gui. Bound to localhost. Authenticated with a per-session random token. Stops when you close the dashboard.

Agents you run inside Claude Code, Cursor, or any other harness are external processes. They talk to the ROAM daemon through the SDK over the same Unix socket. ROAM does not start them, does not host them, does not see their model traffic.

What ROAM never does

The architecture forecloses several failure modes by design. ROAM does not:

  • Phone home for coordination. ROAM coordination happens through the local daemon and session files. Model traffic belongs to the harnesses and providers you choose, not to a ROAM coordinator model.
  • Read your agents' conversations. EYDII is content-blind by architecture. The daemon journals behavioral metadata (which task, which state, when, who); payloads stay between the agent and its harness.
  • Upload your code. ROAM does not upload your repository. If you ask ROAM to scan or adopt an existing project, that analysis stays local; what agents do inside your repo is controlled by the harness they run in (Claude Code, Cursor, etc.), not by ROAM Cloud.
  • Send your provider credentials anywhere. Harness credentials stay on your machine and keep following the provider setup you chose. ROAM does not require a Veritera account to start a local session.
  • Require an account. There is no Veritera login. There is no "ROAM Cloud." There is the binary, your machine, and your work.

Where files live

A ROAM session is a directory. Everything ROAM does is inside it. Nothing it writes lives anywhere else on your system.

<sessionDir>/
  roam.yaml                    Session config (YAML)
  .gitignore                   Auto-written, excludes secrets and runtime
  agents/                      Per-agent working directories
  registry/                    Agent registrations (one YAML per agent)
  tasks/                       Task definitions
  messages/                    Inter-agent messages
  state/                       Session state
  heartbeats/                  Agent heartbeat files
  artifacts/                   Shared artifacts
  doctrine/                    Working doctrine files
  peer-reports/                Drift peer reports
  agent-logs/                  Per-agent log directories
  health/                      Health monitoring
  .roam/
    roam.sock                  Daemon socket (created at start)
    roam.pid                   Daemon PID file
    daemon.log                 Daemon log
    credentials.json           Optional local harness credentials, if configured
    telegram.json              Telegram config (0o600, if enabled)
    digest.json                Session stats
    observer-queue/            EYDII observation queue
    agent-tokens/              Per-agent auth tokens (32-byte hex)

The CLI installs globally via npm (the binary lands in your global npm prefix, e.g. $(npm prefix -g)/bin/roam). It does not write to your home directory or system-wide config beyond the npm global location. All session state — the data — lives only inside the session directory you point it at.

How to verify the install

Use ordinary local checks before you trust the runtime:

# 1. Confirm the CLI responds.
$ roam --help

# 2. Look at what the daemon actually does on first start.
$ roam daemon start
$ roam daemon status

# 3. Inspect local network connections.
$ lsof -i -P -p $(cat .roam/roam.pid)

The point is simple: ROAM should be inspectable from your own machine, with standard tools, before you decide how much autonomy to allow.

How to fully remove ROAM

ROAM uninstalls cleanly because there is nowhere for it to hide.

# 1. Stop the daemon.
$ roam daemon stop

# 2. Delete the session directory you no longer want.
$ rm -rf path/to/your/session

# 3. (Optional) Uninstall the CLI.
$ npm uninstall -g @veritera.ai/roam

That is it. There are no system services, no registry entries outside the standard app location, no leftover daemons. ROAM leaves your machine the way it found it.