arthai-marketplace

/memory-setup

Availability: Local is GA for every layer. Per-layer cloud endpoints (telemetry ingest at ingest.getarth.ai, your org’s own arth-memory server) work today; the unified Arth Cloud sign-in (one login for intelligence + memory + router + orchestrate) is pre-GA, /arth-setup says so when you pick cloud.

Configure arth-memory, the org decision/memory layer for AI agents. Choose Cloud (talk directly to your org’s deployed server, zero local infra, best for trying it / team testing), Local (Docker store on this machine), or Remote (offline replica of a central AWS/GCP server), then register the MCP server. Opt-in.

Test the org memory in ~1 minute (Cloud)

The fastest way to evaluate arth-memory, no Docker, no Ollama, nothing to run locally:

/memory-setup        # choose "Cloud" → paste your org's server URL (e.g. the ALB) → done

Then open a new session and ask an agent to do a task in a repo your org has seeded, it pulls the org’s decisions/constraints via compile_context automatically. Or browse the dashboard at <server-url>/dashboard. Behind the scenes this registers the arth-memory-mcp-remote bridge, which calls the deployed REST API over HTTP.

To share with teammates: send them your toolkit branch + the server URL. They run /memory-setup → Cloud → paste the URL. That’s it.

Synopsis

/memory-setup

When to use it

Quickstart

/memory-setup

Pick Cloud to test your org’s deployed server instantly (no local infra), Local to run an offline Docker store, or Remote to replicate the central server offline. Then run /calibrate.

Examples

/memory-setup        # the only form — the skill is interactive

Typical runs:

What it does

/memory-setup is fully opt-in and additive, if you never run it, the toolkit behaves exactly as today (no memory MCP server, no container).

  1. Installs the arth-memory CLI if it isn’t already on your PATH.
  2. Asks how to connect, a user-confirmation checkpoint:
    • Cloud, talk directly to your org’s deployed server over HTTP (no Docker/Ollama/store). You provide its URL; the reader token defaults to the shared ARTH_PLATFORM_TOKEN in ~/.arthai/.env (paste once, chmod 600), so you’re only asked for a token if that’s unset. Fastest to try / test.
    • Local, a Docker FalkorDB store on this machine + native Ollama. Fully offline, ~$0.
    • Remote, an offline replica synced from your org’s central AWS/GCP server (you provide its URL; the reader token defaults to the shared ARTH_PLATFORM_TOKEN).
  3. Asks where the local knowledge store lives (default ~/.arthai/memory). Knowledge is more than one repo. KB/KG for every repo you work on lives in this one store, and each repo points at it via gitignored symlinks (.claude/knowledge → store). Knowledge is never committed per-repo.
  4. Registers the arth-memory MCP server in .claude/settings.local.json (so agents get compile_context, constraint_check, write).
  5. Runs an initial 1 GB-gated sync: under 1 GB → downloads everything into the store; larger orgs defer to selective sync (a later milestone).

Opt-in shadow write (OFF by default): knowledge write-backs normally go to the local KB + knowledge graph only. Setting ARTH_MEMORY_DUAL_WRITE=1 in your environment (or "dual_write": true in ~/.arthai/config.json) adds a third leg: typed items (decisions, constraints, facts) are also shadow-written to arth-memory through the MCP server registered in step 4. It requires that registration as transport, if the MCP tool is absent, or any write fails, the skill silently continues with KB + graph only (fail-open, today’s behavior). It stays off until you explicitly enable it.

Output & artifacts

Troubleshooting