1.6 -- What You Will Build in This Guide
Who this section is for: Any reader who wants to see the destination before starting the journey. Reading time: 8 minutes. Difficulty: Beginner.
Context
Before diving into the technical chapters, here's an overview of what you'll have at the end of the journey. Not a promise — a target.
The final result
By the end of this playbook, if you follow the steps, you will have:
- An operational server — a VPS (or local machine) with a clean, secure, maintainable tech stack.
- One or more configured agents — with clear roles, structured memory, connected tools.
- A knowledge base — your documents, your rules, your context, organized so agents can leverage them.
- Automated workflows — sequences of actions that run without your intervention, with safeguards.
- A maintenance system — backups, updates, monitoring, so everything keeps working over time.
Target architecture diagram
+================================================================+
| YOUR VPS / MACHINE |
|================================================================|
| |
| +------------------+ +------------------+ |
| | REVERSE PROXY | | MONITORING | |
| | (Caddy/Nginx) | | (logs, alerts) | |
| +--------+---------+ +------------------+ |
| | |
| +--------v-------------------------------------------------+ |
| | DOCKER NETWORK | |
| | | |
| | +-------------+ +-------------+ +----------------+ | |
| | | AGENT 1 | | AGENT 2 | | AGENT N | | |
| | | (role A) | | (role B) | | (role ...) | | |
| | +------+------+ +------+------+ +-------+--------+ | |
| | | | | | |
| | +------v----------------v------------------v---------+ | |
| | | KNOWLEDGE LAYER | | |
| | | +----------+ +-----------+ +----------------+ | | |
| | | | Memory | | Documents | | Business Rules | | | |
| | | +----------+ +-----------+ +----------------+ | | |
| | +----------------------------------------------------+ | |
| | | |
| | +----------------------------------------------------+ | |
| | | TOOLS LAYER | | |
| | | +-------+ +-------+ +--------+ +-----------+ | | |
| | | | Email | | API | | Files | | Calendar | | | |
| | | +-------+ +-------+ +--------+ +-----------+ | | |
| | +----------------------------------------------------+ | |
| | | |
| +-----------------------------------------------------------+ |
| |
| +-----------------------------------------------------------+ |
| | SECURITY: Vault / secrets, SSL certificates, firewall | |
| +-----------------------------------------------------------+ |
| |
+================================================================+
What this diagram tells you
Everything runs in Docker. Each component is isolated, reproducible, and can be updated independently.
Agents share a common Knowledge layer. They are not isolated from each other — they can share context, memory, and rules. This is what enables coordination.
Tools are connections, not components. Your email, your APIs, your files — these are interfaces that agents use. They are not part of the OpenClaw installation itself.
Security is cross-cutting. It's not a component among others — it wraps around everything else. Vault for secrets, SSL for communications, firewall for the perimeter.
What this diagram doesn't tell you
It doesn't show the real complexity of configuration. Each box in this diagram represents hours of configuration work, testing, and tweaking. This playbook guides you through each of these steps.
It also doesn't show how things evolve over time. Your installation in a month won't look like your installation on day one. That's normal and desirable.
Principle: Build the minimal architecture that works, then iterate. The diagram above is a target, not a prerequisite. Your first installation will have a single agent, not five.
Field note: The most robust installations we've seen are those that started small. One VPS, one agent, one use case. Then a second agent when the first was running reliably. Then a third. The temptation to deploy everything at once is strong. Resist it.
Proposer une modification sur GitHub