Document 2 / 3

AGENTS, MEMORY & VPS ARCHITECTURE

This version reflects the architecture that is actually relevant to the current Nexus build: OpenClaw runtime, file-backed memory, portal surfaces, and the real operating model around them.

Current ModelReality NotesNext Steps

Current architecture

What is real in this environment

Main portal application

live now

Nexus Portal is currently a Next.js application with working boards, APIs, and operational surfaces already wired into the product.

Workspace-backed memory model

live now

The real memory approach in this environment is file-backed: MEMORY.md, daily memory files, workspace docs, and live project files.

OpenClaw runtime + relay path

live now

The assistant runs inside OpenClaw on TC’s VPS, with session tools, spawnable sub-agents, and browser control intended to reach TC’s local Chrome session through Browser Relay over Tailscale.

Reality notes

Important clarifications

  • This page describes the current operating model, not a generic future multi-agent platform brochure.
  • Sub-agent orchestration exists conceptually and operationally in OpenClaw, but not every theoretical topology shown here is separately deployed inside the portal repo.
  • Memory durability depends on files and process discipline, not on a hidden magical database layer.
  • The practical browser-control architecture is VPS gateway plus TC’s attached Chrome tab, not an imaginary fully self-contained cloud desktop.
  • VPS hardening, proxying, backups, and restart policies should be treated as operating requirements, but they are not all proven by this repo alone.

Operating surfaces

How the system actually behaves

Conversation orchestration

The main agent handles the chat, decides when to inspect the workspace, and can delegate or spawn isolated execution when needed.

File-backed continuity

Rules, memory, and operating context are stored in workspace files so future sessions can recover durable context safely.

Portal as operator UI

Nexus is the review and control surface for tasks, approvals, meetings, notifications, and other operating signals.

Remote browser control path

The architecture is designed around OpenClaw Browser Relay attaching to TC’s live Chrome tabs, especially for workflows like TradingView control from the VPS-hosted gateway.

Next architecture work

What to improve next

  • Document the exact live deployment topology for Nexus and OpenClaw on this VPS.
  • Add a simple architecture status card showing what is actually deployed versus merely recommended.
  • Connect portal pages to live health and runtime metadata where possible.
  • Only publish advanced topology diagrams after they map to real infrastructure or real code paths.