Onboarding — Day 0 → Day 7

Welcome

OpenClaw is RERI’s internal AI operations platform — a fleet of 44 purpose-built AI agents running on a private server, orchestrated through a central gateway, and governed by a shared rulebook. It automates acquisitions outreach, disposition broadcasts, document handling, CRM sync, and dozens of other workflows that used to require manual coordination.

This guide is for new RERI team members who will read, monitor, and occasionally interact with OpenClaw — but not write code or manage infrastructure in week 1. If you’ve been handed this guide, someone has already set up your access. Your job this week is to understand the system well enough to navigate it and ask useful questions. Code comes later.

Day 0 — Before You Start

Before your first login, make sure you have these three tools installed on your laptop:

SSH client — Terminal (macOS/Linux) or Windows Terminal with OpenSSH enabled.
1Password — The team uses 1Password for all shared credentials. Henry will add you to the Aurora vault. Do not store any OpenClaw passwords in your browser or personal password manager.
VS Code — Optional but recommended. The workspace is pre-configured with OpenClaw-specific extensions and tasks.

You do not need to generate any API keys, configure any services, or install anything on the server. Your account on the VPS is already provisioned. If anything is missing, ask Henry before proceeding — do not attempt to provision your own access.

Day 1 — Connecting

OpenClaw runs on a single VPS (Virtual Private Server) hosted at Hostinger. The server is not directly reachable from the public internet — you connect through Tailscale, a private mesh network.

Step 1: Join the tailnet. Henry must add your device to the RERI tailnet before this works. Once added, install the Tailscale client on your laptop and sign in. Your device will get a private 100.x.x.x IP that lets you reach the VPS.

Step 2: SSH to the VPS.

ssh opsadmin@<vps-tailscale-ip>

The VPS Tailscale IP is in the 1Password Aurora vault. You should land at a bash prompt as opsadmin.

Step 3: Know where things live. Two paths matter most:

/home/opsadmin/.openclaw/ — the canonical home of everything: agents, scripts, webhooks, configs, memory databases, and the knowledge base. This is where the system actually runs.
/home/opsadmin/openclaw-vault/ — a read-only Obsidian-synced copy of documentation, plans, and governance files. This is the “wiki” layer you’ll browse most often. It updates from canonical paths every 15 minutes.

You can safely ls and cat files in both locations. Do not modify files here until you understand what owns what.

Day 2 — Open the VS Code Workspace

If you have VS Code installed, the entire OpenClaw workspace is pre-configured for you. From your SSH session — or via VS Code Remote-SSH — run:

code /home/opsadmin/.openclaw/openclaw.code-workspace

This opens a multi-root workspace with four folders:

Folder	Path	What’s in it
Workspace — Scripts / Webhooks / Docs	`/home/opsadmin/.openclaw/workspace`	Automation scripts, webhook handlers, API knowledge base
Agents — Configs / Instructions	`/home/opsadmin/.openclaw/agents`	Each agent’s config, system prompt (SOUL.md), and tools
Plans — Claude Plans	`/home/opsadmin/.claude/plans`	Active and archived project plans
Tools — MCP / Hooks / Memory CLI	`/home/opsadmin/.openclaw/tools`	MCP servers, hook scripts, memory CLI

Quick actions via the tasks panel: Press Ctrl+Shift+P (or Cmd+Shift+P on Mac) → type “Tasks: Run Task” → look for tasks prefixed with OC:. These are pre-wired read-only operations: view all service statuses, tail the gateway log, search memory, list active plans. They’re safe to run any time.

Useful extensions already recommended in the workspace: markdown-all-in-one, todo-tree (surfaces HENRY: and BLOCKED: tags), peacock (color-codes the window).

Day 3 — The Mental Model: 3 Layers

OpenClaw has three layers. Understanding this model will make the rest of week 1 click.

Layer 1 — Infrastructure

A single VPS runs roughly 87 services managed by systemd and PM2. The two most important:

OpenClaw Gateway (port 18789) — the central routing bus. Every agent request goes through here. It applies rate limits, selects the right model, and dispatches to the right handler.
Portkey Proxy (port 18900) — a middleware layer that sits between the gateway and the actual LLM APIs (Anthropic, OpenAI, and others). It handles cost tracking, model fallbacks, and caching.

Inbound events from the outside world (phone calls, SMS, CRM updates, form submissions) arrive via webhook handlers on specific ports, get processed by JavaScript handlers, and then write to the database or trigger agent actions.

Layer 2 — 44 Agents in 3 Tiers

Agents are not chatbots you talk to. They are purpose-built configurations that receive structured inputs, reason through them using an LLM, and produce structured outputs — usually a CRM update, an SMS message, or a Discord notification.

Tier	Model	Count	Purpose
Strategic	Opus (most capable)	2	Architecture, governance, novel problem-solving
Operations	Sonnet (balanced)	~14	API integrations, data pipelines, multi-step workflows
Automation	Haiku (fast, cheap)	~18+	High-volume polling, routine sync, repetitive tasks

Two agents you’ll hear about most: Aurora (the “Chief AI Operations” agent — orchestrates builds, monitors Discord, dispatches other agents) and Solara (strategic governance — P0 plans, compliance, system state).

Each agent has a SOUL.md — a markdown file that defines its identity, capabilities, and hard constraints. Changing a SOUL requires Henry’s approval. Think of it like an employment contract.

Layer 3 — Memory + Vault

Every agent has its own SQLite database at /home/opsadmin/.openclaw/memory/. These aren’t logs — they’re searchable memory stores with vector embeddings (generated by Voyage-4). When an agent needs context from a past conversation or decision, it searches its own memory DB first.

The vault (~/openclaw-vault/) is a human-readable window into the same information. It’s organized as an Obsidian vault and syncs every 15 minutes. You can also access it at docs.reri.co once that’s live (CF Access protected — ask Henry for OTP access).

Day 4 — How Chat-Driven Execution Works

When Henry types a request into Claude Code (the CLI AI tool), here’s what actually happens:

Hooks fire. A SessionStart hook reads the current session state — open plans, recent logs, memory context — and loads it into the conversation.
CLAUDE.md governs. Every request is routed through a 400+ line governance file (/home/opsadmin/CLAUDE.md) that defines which tools, skills, and models to use for which requests. It’s the system’s rulebook.
Tools execute. Claude may call built-in tools (read a file, run a bash command), invoke a skill (a named capability bundle), call an MCP server (a structured tool server), or dispatch to an agent via the gateway.
Portkey proxies all LLM calls. No LLM call reaches Anthropic or OpenAI directly — it goes through Portkey first for cost tracking and model fallback.
Memory absorbs the result. At session end, a Stop hook extracts a summary and enqueues it to the memory system.

For more detail on the full request lifecycle: How It Works.

Day 5 — Skills + Slash Commands

A skill is a bundle of markdown instructions and YAML metadata that Claude Code can invoke by name. Think of it as a pre-packaged workflow — like /acquisitions-outreach (run the initial SMS outreach pipeline) or /dispo-blast (broadcast a deal to all buyer channels).

Skills live at ~/.claude/skills/. There are 54 directories, ~34 with complete definitions.

How to discover what’s available:

ls /home/opsadmin/.claude/skills/

How they’re invoked: In a Claude Code chat session, typing /skill-name triggers the skill. Many skills also have keyword auto-triggers — for example, typing “where are we at” automatically runs /gsd:progress without needing the slash command. These triggers are defined in CLAUDE.md’s Tool Trigger Conditions table.

In week 1, you’re an observer. You can read skill definitions freely. Don’t invoke execution skills (/gsd:execute-phase, /acquisitions-outreach, /dispo-blast) until you understand what they do and have confirmed with Henry.

For a primer on the skill system: Skills Primer.

Day 6 — Memory + Vector Pipeline

OpenClaw’s memory system is more sophisticated than it looks. Here’s what’s actually happening:

44 SQLite databases, one per agent, at /home/opsadmin/.openclaw/memory/
Each database uses two search indexes: a vector index (chunks_vec via vec0) and a full-text index (chunks_fts via FTS5)
Every search blends the two: 70% vector similarity (via Voyage-4 embeddings) + 30% keyword BM25. This handles both semantic queries (“what did we decide about wholesaler outreach?”) and exact-term lookups (“find all mentions of HubSpot deal 12345”)
Agents are memory-isolated by default — Aurora’s memories stay in Aurora’s DB; acquisitions’ memories stay in acquisitions’ DB. Cross-agent queries require explicit parameters.

The vault and canonical paths are connected. When Henry’s session ends, a hook enqueues a memory save. Separately, openclaw-vault-sync.timer runs every 15 minutes and rsyncs key files from their canonical locations (plans, agent SOULs, governance docs, knowledge base) into ~/openclaw-vault/, then pushes to GitHub. If you’re browsing the vault and something looks stale, it will self-correct within 15 minutes.

Fleet-wide there are approximately 5,500 stored memory chunks across all agents.

Day 7 — Your First Safe Interaction

By now you have a working SSH connection, VS Code workspace, and enough context to read the system intelligently. Here’s what you can do unilaterally, and what requires Henry’s go-ahead.

Safe — no confirmation needed

Read logs: journalctl --user -u openclaw-gateway --since "5 min ago"
Browse vault: ls ~/openclaw-vault/ or open it in Obsidian
Search memory: python3 ~/.openclaw/tools/claude-memory.py search "your topic"
View service status: systemctl --user status openclaw-gateway portkey-proxy
Read any file in ~/.openclaw/ that isn’t master.env or a .credentials file
Run VS Code OC: tasks that only read (Status, Journal, Memory Search, Session Audit)

Requires Henry’s explicit go-ahead

Restarting any service (systemctl restart, pm2 restart)
Editing any file — scripts, webhook handlers, agent configs, CLAUDE.md
Running execution skills — anything that sends SMS, creates HubSpot deals, or triggers outreach
Making any API call with side effects — even a read that logs usage counts
Touching master.env — the single source of truth for all credentials

This is the Action Gate rule built into CLAUDE.md: reads and logs are always fine; writes, restarts, and outbound calls wait for an explicit “go ahead.” When in doubt, read it first, then ask.

Try these two commands on Day 7:

# View recent gateway activity
journalctl --user -u openclaw-gateway --since "5 min ago"

# Search system memory for a topic you care about
python3 ~/.openclaw/tools/claude-memory.py search "acquisitions outreach"

Where to Ask Questions

Slack #ops — the primary channel for system questions, alerts, and status updates. Most automated alerts from OpenClaw post here.
Ping Henry directly — for anything access-related, anything that seems broken, or anything you’re unsure about before taking action.

Do not try to message agents directly (Aurora, Solara, etc.) until you’re more familiar with how they work. Agents respond to structured inputs via the gateway — they’re not chat interfaces you open a DM with.

What to Avoid in Week 1

A short list of things that can cause real problems if done without context:

Restarting services — even a brief restart of openclaw-gateway drops in-flight webhook events. Other agents and external systems may be mid-conversation.
Modifying agent SOULs — the SOUL.md file is an agent’s identity. Editing it without understanding the full agent context and Henry’s sign-off can cause the agent to behave incorrectly in ways that are hard to detect.
Editing master.env — this file has 111+ credential entries across 19 sections. A wrong keystroke can break multiple services simultaneously.
Using /gsd:execute-phase on someone else’s plan — this triggers autonomous phase execution. If you don’t own the plan, you don’t know what side effects it will cause.
Installing anything system-wide without checking what’s already there — there are 87 running services. Port conflicts and dependency clashes are easy to create and slow to debug.

Where to Go Next

Once you have the mental model from this week, these are your next stops:

How It Works — the full chat-to-execution flow with component detail
Master Architecture — the entire system in one diagram: agents, tiers, ports, data flows
Skills Primer — how slash commands and keyword triggers work, how to read a skill definition
Architecture Snapshot — the current live state: services, ports, agent assignments, and what’s running right now