From Local Hermes to VPS Agents: A Technical Map of the Stack
Our stack is not one product. It is a control plane, an execution layer, a memory layer, and a set of focused repos that each solve one part of the system.
The design goal is simple: keep orchestration local, keep long-running work durable, and keep the public-facing projects legible enough that they can be maintained without the whole thing collapsing into a monolith.
Architectural split
The system is easiest to understand as three connected zones:
- Local Hermes โ the coordination layer on the desktop
- VPS agents โ durable execution, long-running services, and business operations
- Shared project repos โ the public surfaces that actually ship product and content
That split matters because it keeps the responsibilities clean. The local side can make decisions quickly. The VPS side can stay online and do the boring repeatable work. The repos in the middle define the actual products, workflows, and knowledge base.
Local Hermes as the control plane
Local Hermes is where work gets routed, reasoned about, and handed off.
It is the place for:
- coordinating cross-project tasks
- deciding whether work stays local or moves to the VPS
- reading and writing shared memory
- preparing publishable outputs before they hit the live stack
This matters because orchestration is a different problem than execution. If you mix the two, the system gets harder to debug and harder to trust.
VPS agents as the execution layer
The VPS is where durable operations belong.
That layer is better for:
- persistent agents
- scheduled jobs
- business-facing workflows
- publishing pipelines
- processes that should keep running when the desktop is idle
The design principle here is separation, not duplication. The VPS does not replace local control. It complements it by handling the parts of the system that need uptime and consistency.
Memory as shared context
Shared memory is the glue that keeps the stack from drifting.
Without memory, every workflow becomes a one-off prompt. With memory, the system can retain durable decisions, project structure, and operational context across sessions.
That turns the stack into something more like an operating system:
- work can be resumed
- project roles stay consistent
- content can reference prior decisions
- agents can stay aligned even when the conversation changes
The public project layer
These are the repos that can be shared publicly. They are the visible parts of the architecture, and together they tell the story of how the stack works.
HandyBeaver
https://github.com/Atlas-Os1/handy-beaver
HandyBeaver is the business operations layer. It supports client workflows, structured operations, and the repeatable administrative work that needs to stay reliable over time.
Minte Blog Worker
https://github.com/Atlas-Os1/minte-blog-worker
The blog worker is the publishing layer. It renders content at the edge, stores posts in R2, updates indexes, and supports automated generation and approval flows.
Kiamichi Biz Connect
https://github.com/mintedmaterial/kiamichi-Biz-Connect
Kiamichi Biz Connect is the local business platform. It combines directory data, enrichment, content generation, and Cloudflare-native infrastructure into a single workflow.
OpenClaw Memory Vectorize
https://github.com/Atlas-Os1/openclaw-memory-vectorize
OpenClaw Memory Vectorize is the memory infrastructure layer. It is part of the shared retrieval and context system that helps the broader stack stay organized.
OpenMontage
https://github.com/Atlas-Os1/OpenMontage
OpenMontage covers the creative layer. It supports visual and media-oriented work that sits alongside the rest of the system instead of being bolted on later.
How the flow works
The runtime pattern is straightforward:
local orchestration โ VPS execution โ memory persistence โ published output
A task starts in local Hermes, gets routed to the right execution surface, writes durable state where appropriate, and ends as something useful in a repo, a site, or a workflow.
That flow is what keeps the stack maintainable. It also makes failures easier to isolate. If the output is wrong, you can ask whether the issue is in coordination, execution, memory, or publishing instead of guessing.
Why this architecture works
This structure works because each part of the system is intentionally narrow.
- Local Hermes is for coordination.
- VPS agents are for durability.
- Memory is for continuity.
- Public repos are for shipping real artifacts.
That gives us a stack that is easier to debug, easier to extend, and easier to explain.
It also avoids the common trap where every project becomes its own isolated island. Here, the projects are separate, but the operating model is shared.
The vision
The long-term vision is an ecosystem where:
- local Hermes coordinates work intelligently
- VPS agents handle persistent business and publishing tasks
- memory, content, and operations stay connected
- each repo has a purpose and each service has a lane
That means we can keep building without losing the structure that makes the build sustainable.
The goal is not just to automate more.
The goal is to automate cleanly.
When the architecture is coherent, the work becomes easier to trust, easier to scale, and easier to keep improving.