Agent Social -- Architecture Planning

Migrated from local file Agent-social-still-todo.md (2026-02-17) Project: agent-social (blueflyio/agent-platform/social/agent-social) Previous names: OpenClaw, MoltBook

GitLab Issues

Original Planning Document

Where This Should Live: Its Own Project

Here's my reasoning. You've got a clear separation in your ecosystem right now:

OpenClaw doesn't fit cleanly into any of these. It's not an agent manifest, it's not a shared package, and it's not a CI component. It's a runtime execution environment — the thing that actually runs your agents in a conversational, always-on mode. It's a new tier:

Tier 1: platform-agents/        → Agent definitions (YAML)
Tier 2: common_npm/agent-*      → Infrastructure packages (TypeScript)  
Tier 3: gitlab-agent_ossa/      → Platform implementation (Go)
Tier 4: openclaw-bluefly/       → Agent runtime & skills (NEW)

My recommendation: create blueflyio/openclaw-bluefly as its own GitLab project. It would contain your custom skills, Docker compose configs, workspace templates (SOUL.md, IDENTITY.md, AGENTS.md), and the MCP bridge servers. The OpenClaw runtime itself stays upstream — you don't fork it, you just install it as a dependency and layer your stuff on top.

On the Separate Volume / Separate Server Question

For the Synology NAS — running it on a separate volume is smart and doable. You'd create a dedicated shared folder (like /volume2/openclaw/ if you have a second volume, or a separate shared folder on volume1) and mount everything there. The Docker containers would be completely isolated from your other services.

But honestly? I'd recommend a separate cheap VPS over cramming this onto the NAS alongside everything else. Here's why:

1. The NAS is already running MinIO, webhooks, mesh API, and your other Docker workloads. OpenClaw with sandboxing spawns additional Docker containers per session — that's a resource multiplier you don't want competing with production services.

2. OpenClaw needs to own the Docker socket to spawn sandbox containers. Sharing that with your other infrastructure is a security boundary you'd rather not blur.

3. A dedicated $20-30/month VPS (Hetzner CX32 or similar — not Oracle free tier since you don't want to share it) gives you 4 vCPU, 8GB RAM, dedicated to this purpose, and you connect it to your Tailscale network so it can reach the NAS services (MinIO, mesh, webhooks) securely.

The architecture would look like:

┌─ Tailscale Network ─────────────────────────────┐
│                                                    │
│  VPS (Hetzner/dedicated)                          │
│  ├─ OpenClaw Gateway (Docker)                     │
│  ├─ Agent Sandboxes (Docker, per-session)         │
│  ├─ Custom Bluefly skills                         │
│  └─ MCP bridge → connects to NAS services         │
│       │                                            │
│       │ Tailscale (encrypted)                      │
│       ▼                                            │
│  Synology NAS (192.168.68.54)                     │
│  ├─ MinIO (:9000) ← agent storage                 │
│  ├─ Agent Mesh (:3005) ← OSSA registry            │
│  ├─ Webhooks (:3001) ← GitLab events              │
│  └─ LiteLLM (:4000) ← model gateway               │
│       │                                            │
│  Vast.ai (RTX 4090)                               │
│  └─ Ollama ← local model inference                 │
│                                                    │
│  Mac M4 Pro (you)                                  │
│  └─ Telegram/Discord ← chat with your agents      │
└────────────────────────────────────────────────────┘

OpenClaw calls your LiteLLM gateway on the NAS for model routing, pulls agent manifests from the mesh API, stores artifacts in MinIO, and receives GitLab events through webhooks — all over Tailscale. But the actual agent execution is isolated on its own box where it can't touch your production data even if something goes sideways.

Want me to spec out the GitLab project structure for openclaw-bluefly and a Hetzner setup script to get the dedicated VPS stood up?