arthai-marketplace

Team Setup Guide

The central path: one admin deploys shared services once, and every seat wires into them with a short, per-seat setup pass. For the solo path, see the Single-User Guide.

Availability: per-layer endpoints (telemetry ingest, your org’s own arth-memory server, a central router) work today. The unified Arth Cloud sign-in — one login across intelligence + memory + router + orchestrate — is pre-GA. /arth-setup and /otel-setup say so explicitly when you pick a cloud option; nothing below depends on it being ready.

What the admin does once

The admin deploys the services a team wants centrally — Arth Intelligence, arth-memory, arth-router, any combination — and hands each seat exactly four values:

Value	What it’s for
ARTH_INGEST_URL	Intelligence’s OTEL ingest endpoint
ARTH_MEMORY_API_URL	arth-memory’s query/ingest endpoint
ARTH_ROUTER_URL	arth-router’s decision endpoint
ARTH_PLATFORM_TOKEN	one shared auth token, pasted once per seat

These are three separate, host-based URLs — not one base URL with path suffixes. https://intelligence.example.com, https://memory.example.com, https://router.example.com works; https://arth.example.com/intelligence, .../memory, .../router on a single host does not — each service needs its own host-routable endpoint, because each is deployed and scaled independently.

Every seat pastes ARTH_PLATFORM_TOKEN into their own ~/.arthai/.env (mode 600) exactly once; it’s never distributed any other way and never lives in a repo, a shared doc, or ~/.arthai/config.json.

Per-seat wiring

Each layer’s setup skill has a specific central-mode answer — this isn’t a generic “point everything at the org server” step:

Skill	Central-mode choice	What it means
/otel-setup	Custom (self-hosted) — not “Cloud”	“Cloud” in /otel-setup means Arth’s own hosted ingest, not your org’s self-hosted one. Point it at your admin’s ARTH_INGEST_URL via Custom.
/memory-setup	Cloud (direct to org server) or Remote (offline replica)	Cloud queries the server live; Remote syncs a local replica for low-latency answers when you’re offline or want ~200ms responses.
/router-setup	the central-router branch — “wire this seat only”	There’s no local pool config to write — capacity, budgets, and policy are entirely central. This seat is a client, not a peer.

What’s admin-owned — and seat-immutable

Some things a seat’s setup can read but never write:

• Capability flags — env-gated features (default OFF) are set per seat by that seat’s own setup choices, but nothing about central deployment lets one seat flip a flag for another. There is no “seat-flippable centrally” path.
• Router catalog, policy, and budgets — live entirely on the admin side. A seat’s provider-registry generate run under posture: central never writes to these; it emits a proposed diff (~/.arthai/proposals/ providers-{catalog,proxy}.diff) for the admin to review and apply by hand. No seat-side tooling writes to a central catalog or budget.
• Memory RBAC — reader ⊂ writer ⊂ admin roles and per-scope tokens are enforced server-side. A seat’s local config can’t escalate its own access.

Supported mixed combinations

You don’t have to go all-central or all-local layer by layer — these are the common real-world shapes:

You are	Telemetry	Memory	Router
Solo dev	Local	files or memory-local	skip
Solo dev, multiple machines	Cloud	central + replicas	skip
Small team	Cloud or self-hosted central	central + replicas	optional
Org with cost governance	central	central	central

Every mode switch — per layer — is a config edit, not a migration. Downgrading is the same edit in reverse; see Deployment Modes for the exact guarantees.

Related

• Single-User Guide — the solo path
• Prerequisites — hardware/platform reference (applies to each seat’s own machine regardless of posture)
• Deployment Modes — the full map
• /router-setup · /otel-setup · /memory-setup