Neotoma with IronClaw

IronClaw is a secure, always-on agent runtime. Neotoma gives that runtime a structured state layer: versioned entities, relationships, timelines, and provenance that are also available to Cursor, Claude Code, Codex, and ChatGPT.

What IronClaw provides

Always-on agent execution with REPL, web gateway, webhooks, and channel integrations
WASM sandboxing with capability manifests, endpoint allowlists, fuel limits, and leak detection
MCP client support for hosted tool providers
Workspace memory with markdown-style files and hybrid full-text plus vector search

Why add Neotoma

IronClaw workspace files are useful working memory; Neotoma adds durable structured state
Facts stored from IronClaw become queryable from every other MCP client
Entity resolution keeps contacts, tasks, decisions, and relationships unified across tools
Versioned observations let you reconstruct what the agent knew at decision time

Using them together

Treat IronClaw as the execution layer and Neotoma as the state layer. IronClaw runs the agent and invokes tools. Neotoma stores the structured truth that should survive across sessions, agents, and clients.

Concern	IronClaw	Neotoma
Agent execution	Always-on runtime, channels, routines	-
Tool security	WASM sandbox and allowlists	State-layer access controls
Working memory	Workspace files and hybrid search	Structured entities and graph traversal
Cross-tool continuity	IronClaw-scoped	Shared through MCP
State integrity	Audit logs for tool activity	Versioned observations with provenance

Setup

Start with HTTP MCP because IronClaw documents `ironclaw mcp add`, `ironclaw mcp list`, and `ironclaw mcp test` as the stable server-management path.

Code snippet

Copy the exact snippet shown below.

# 1. Start Neotoma with an HTTPS tunnel
neotoma api start --env prod --tunnel

# 2. Add the remote MCP endpoint to IronClaw
ironclaw mcp add neotoma https://<tunnel-host>/mcp \
  --description "Neotoma structured memory"

# 3. Verify IronClaw can see Neotoma tools
ironclaw mcp test neotoma

IronClaw stores MCP server configuration in its database when available and falls back to ~/.ironclaw/mcp_servers.json. If your IronClaw build supports stdio MCP transports, you can use a local config entry instead:

Code snippet

Copy the exact snippet shown below.

{
  "servers": [
    {
      "name": "neotoma",
      "url": "",
      "description": "Neotoma structured memory",
      "enabled": true,
      "transport": {
        "transport": "stdio",
        "command": "/absolute/path/to/neotoma/scripts/run_neotoma_mcp_stdio_prod.sh",
        "args": []
      }
    }
  ]
}

Developer setup guideExact IronClaw MCP commands, local stdio fallback, verification, and troubleshooting.

Full setup details live in docs/developer/mcp_ironclaw_setup.md.

IronClaw documentation

Before and after: IronClaw with Neotoma

“Continue where we left off yesterday.”

Without Neotoma

Resuming based on thread from two weeks ago.

With Neotoma

Resuming yesterday’s thread on the migration plan. 3 open tasks remaining.

“What did I commit to with Sarah last week?”

Without Neotoma

No commitments found.

With Neotoma

You committed to sending the architecture doc by Friday. Sarah’s email updated Mar 28.

“How much did we spend on cloud hosting last month?”

Without Neotoma

No hosting expenses found.

With Neotoma

$847 across AWS and Vercel, up 12% from February.

After you connect

Once Neotoma is running, try these starter commands in IronClaw to see cross-session memory in action:

Store a contact

“Remember that Sarah Chen's email is sarah@newstartup.io — she's the CTO at NewStartup.”

Store a task

“I need to send the architecture doc to Sarah by Friday.”

Recall across sessions

“What do I know about Sarah? What did I commit to doing for her?”

Start with the install guide, then review the MCP reference and agent instructions for the memory rules IronClaw should follow when it writes to Neotoma.