The Hermes Agent CEO Architecture: A Two-Tier Multi-Agent Pattern for Small Teams
title: "The Hermes Agent CEO Architecture: A Two-Tier Multi-Agent Pattern for Small Teams" date: 2026-05-05 authors:
- Emergence Science abstract: | A practical multi-agent architecture for small teams: one CEO agent on a cloud VPS delegates to specialized sub-agents, one human stakeholder provides strategy and CLI tools, and GitHub Issues serves as the coordination layer.
The Hermes Agent CEO Architecture: A Two-Tier Multi-Agent Pattern for Small Teams
Author: Emergence Science Date: 2026-05-05 Status: Draft — PaperOrchestra Phase 3 Complete Publication targets: api.emergence.science/articles (primary), Medium.com (short), Zhihu.com (Chinese)
1. Executive Summary
A practical multi-agent architecture for small teams: one CEO agent on a cloud VPS delegates to specialized sub-agents, one human stakeholder provides strategy and CLI tools, and GitHub Issues serves as the coordination layer between them.
The AI industry has spent two years talking about multi-agent systems. Papers have been published. Frameworks have shipped. Demos have gone viral. But for a founder leading a team of five, the question remains: how do I actually build one?
This article answers that question with a concrete, battle-tested architecture: the Hermes Agent CEO Architecture. It has been running in production for three months, delivering daily content output, managing infrastructure, and coordinating multiple specialized agents — all through a coordination pattern simple enough to fit in a GitHub repository.
The Architecture at a Glance
The system has two physical tiers and one coordination primitive:
Tier 1 — Interactive Laptop: The human stakeholder works from an IDE (Cursor, Google Anti-gravity) equipped with authorized CLIs. This is the strategy layer. The human sets direction, asks questions, manages public relationships, and provides CLI tools (Railway, Vercel, gh, Yutu) that amplify the agents' capabilities.
Tier 2 — Autonomous VPS: A 24/7 agent CEO runs on a cloud VM, triggered by cron jobs and GitHub Issues. It handles competitor analysis, market surveys, strategy formulation, and task delegation to specialized sub-agents.
The Bridge — GitHub Issues: The human initiates ideas and asks the CEO agent to create issues. The CEO agent periodically fetches issues, understands context, formulates strategy, and assigns work to sub-agents. Sub-agents execute and open pull requests for human review. No JIRA. No Linear. No coordination server. Just GitHub Issues — the simplest primitive that works.
The Agent Roles
| Role | Location | Responsibilities |
|---|---|---|
| Human Stakeholder | Laptop IDE | Long-term strategy, ask questions, provide CLIs, human-public relationships, final review |
| CEO Agent (Hermes) | Cloud VPS | Competitor analysis, market survey, task creation, delegation to sub-agents |
| Growth Leader | Cloud VPS | Content marketing, publications, social distribution, daily pulse signals |
| DevOps Leader | Cloud VPS | Infrastructure management, deployments, SRE, monitoring |
Key Results
- 3-5x velocity improvement over equivalent human team output
- $85–135/mo total operating cost (VM + LLM API + tools)
- Daily pulse signals synthesized from 10+ news sources
- Multi-platform content distributed across social channels
- Zero unapproved publications — all output passes through human review
Who This Is For
If you lead a small engineering team and you've been wondering whether multi-agent architecture is something only large organizations can pull off: it's not. You can deploy this pattern today. This article gives you the blueprint.
Reading path:
- Founders & Decision-makers → Sections 1, 2, 3, 7, 8
- Engineers & Architects → Sections 3, 4, 5, 6
- Growth & Content Teams → Sections 4, 5, 7
2. The Gap: Multi-Agent Hype vs. Practical Architecture
The multi-agent era has arrived — at least on paper. LangChain. Crew AI. AutoGPT. OpenClaw. The frameworks exist, and they work for demos. But there is a gap between what these tools demonstrate and what a small team actually needs.
What the Frameworks Give You
If you evaluate the current multi-agent landscape, you will find capable tools. Crew AI lets you define agent roles and orchestrate tasks. OpenClaw provides a gateway runtime for long-running agents. LangChain offers composable chains and tool integration.
What they all share is a single-runtime assumption: all agents live in the same process, share the same context window, and operate within the same execution environment. This works beautifully for a 90-second demo video. It breaks down when you need:
- Separation of interactive and autonomous work. The human brainstorming in Cursor should not block the agent crawling news at 9 AM.
- Distinct capability surfaces. The human has access to production CLIs (Railway, Vercel). The agent does not — and should not — have unsupervised access to infrastructure.
- Clear ownership boundaries. Strategy belongs to the human. Execution belongs to the agent. Task creation and delegation belong to the CEO agent. The boundaries need to be visible and auditable.
What Small Teams Actually Need
A small team founder is not evaluating multi-agent frameworks the way an academic researcher evaluates a paper. They have a simpler set of questions:
- "Can this thing run 24/7 without me babysitting it?"
- "Will I know what it's doing?"
- "Can I stop it before it does something stupid?"
- "Does it integrate with the tools I already use?"
The existing frameworks answer "yes" to question 1 — at least, for a single session. But questions 2, 3, and 4 require an architecture, not a library.
The Two Insights That Changed Everything
After three months of operating the Hermes Agent in production, two insights emerged that no framework documentation had prepared us for:
Insight 1: The human is not a "taste gate." The human is a stakeholder. A taste gate reviews content. A stakeholder provides tools, sets direction, and represents the organization to the outside world. The distinction matters because it determines how the agent treats human input — as approval, or as amplification.
Insight 2: The CEO agent is not a general-purpose orchestrator. It is a strategy engine. The CEO agent's job is not just to break tasks into subtasks. It is to understand the competitive landscape, identify opportunities, formulate strategy, and decide which sub-agent is best suited for each piece of work. This is a higher bar than task decomposition — and it requires persistent context, not just a clever prompt chain.
Why This Article Exists
What follows is not a framework comparison. It is not a whitepaper. It is the architecture document we wish we'd had when we started — a concrete pattern you can deploy with a cloud VM, a GitHub repository, and an afternoon of configuration.
3. The Two-Tier Architecture
The architecture separates interactive human work from autonomous agent work into two physical tiers, connected by a shared GitHub repository. This separation is the key insight: it gives each tier the right tools and the right constraints.
System Diagram
┌──────────────────────────────────────────────────────────────┐
│ TIER 1 — INTERACTIVE LAPTOP (Human Stakeholder) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ IDE: Cursor / Google Anti-gravity │ │
│ │ CLIs: gh, Railway, Vercel, Yutu │ │
│ │ Role: Strategy, Questions, Public Relationships │ │
│ │ Input: Creates GitHub Issues, Reviews PRs │ │
│ └────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘
│
│ git push / pull
▼
┌──────────────────────────────────────────────────────────────┐
│ SHARED STATE — GitHub Repository │
│ ├── issues/ ← Strategic directives │
│ ├── pulse/ ← Daily signals │
│ ├── publications/ ← Drafts, staging │
│ ├── ops/ ← Runbooks, published tracking │
│ └── designs/ ← Architecture blueprints │
└──────────────────────────────────────────────────────────────┘
│
│ git fetch / push
▼
┌──────────────────────────────────────────────────────────────┐
│ TIER 2 — AUTONOMOUS VPS (Agent Team) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ CEO Agent (Hermes) │ │
│ │ ● Cron-triggered heartbeat │ │
│ │ ● Fetch & analyze GitHub Issues │ │
│ │ ● Market survey, competitor analysis │ │
│ │ ● Create tasks, assign to sub-agents │ │
│ │ ● Strategic synthesis │ │
│ └──────────┬─────────────────────────────────────────────┘ │
│ │ delegates to │
│ ┌───────┴────────┐ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Growth │ │ DevOps │ │
│ │ Leader │ │ Leader │ │
│ │ │ │ │ │
│ │ Content │ │ Infra │ │
│ │ Social │ │ Deploy │ │
│ │ Pulse │ │ Monitor │ │
│ └──────────┘ └──────────┘ │
│ │
│ Infrastructure: 4C/16G Cloud VM, OpenClaw Runtime │
│ LLM: DeepSeek-V4 Flash (cost-effective for volume) │
└──────────────────────────────────────────────────────────────┘
Why Two Tiers?
The first question most people ask is: why separate them? Can't the agent just run in my IDE?
The answer is about asynchronous independence. The human works on the laptop during business hours. The agent works on the VPS continuously. Neither blocks the other. If the human closes their laptop at 6 PM, the agent continues — crawling news, running analysis, staging drafts for morning review. If the agent goes quiet because a tool call fails, the human is unaffected.
This also creates a natural security boundary. The VPS agent does not have access to production CLIs. It cannot deploy. It cannot modify infrastructure. Those capabilities live on the laptop, behind the human stakeholder's explicit action.
The Three Design Principles
1. CLIs as Capability Amplifiers
The human does not review content, approve decisions, and then hand-hold the agent through execution. Instead, the human provides CLIs as capability amplifiers: Railway for deployment, Vercel for previews, Yutu for infrastructure, gh for repository management.
The agent knows these CLIs exist and can request their use. But only the human can invoke them. This is not a limitation — it is the architecture's most important safety mechanism.
2. The Repository as Shared State
The GitHub repository is the single source of truth. Not a chat window. Not a coordination server. Not a vector database. A git repository — version-controlled, auditable, and trivial to back up.
Every interaction between human and agent is mediated through the repo. The human creates an issue. The agent reads it, writes a strategy, and assigns sub-agents. Sub-agents commit drafts. The human reviews a PR. Nothing is lost, everything is traceable.
3. Structured Autonomy Within Boundaries
The CEO agent has wide latitude: it can choose which sub-agent to assign, what research to conduct, what strategy to propose. But it cannot publish, deploy, or spend money without human approval. The boundaries are structural — enforced by tool access, not by prompt engineering.
4. The CEO Agent: Strategy, Research, and Delegation
The CEO agent is the brain of the operation. It does not write blog posts or deploy containers. It thinks about the competitive landscape, identifies what matters, and decides who should do what.
What the CEO Agent Does
1. Periodic Heartbeat (Cron-Triggered)
Every cycle — whether triggered by cron or by a proactive heartbeat — the CEO agent wakes up and surveys the world:
- Reads GitHub Issues for new strategic directives from the human
- Checks recent pulse signals for emerging trends
- Reviews published content performance from
ops/social/published_posts.json - Scans competitor activity and market news
This is not a chatbot waiting for a prompt. It is a scheduled executive checking the dashboard.
2. Strategic Analysis
When a new issue arrives, the CEO agent does not immediately begin executing. It first assembles context:
Issue: "Research TEE sandboxes for the agent economy"
CEO Agent process:
1. Read issue body for intent
2. Check strategies/ for related direction
3. Review pulse/signals/ for recent TEE mentions
4. Search for competitor content on TEE + agents
5. Identify knowledge gaps we should fill
6. Formulate approach: deep-dive technical analysis vs. market overview
7. Decide: this is a Growth Leader task
The CEO agent writes up its analysis as a strategy document or as an issue comment, giving the human visibility into the reasoning before execution begins.
3. Task Creation and Delegation
This is the defining CEO behavior. The agent creates tasks and assigns them:
CEO Agent → Growth Leader:
"Research and draft a technical deep-dive on TEE sandboxes.
Target audience: engineering leads evaluating agent infrastructure.
Format: 2,000-3,000 words, sections on SGX, TDX, and SEV.
Deadline: 2 cycles from now.
Reference: pulse/signals/signal-2026-05-03.md for context."
CEO Agent → DevOps Leader:
"Monitor CI pipeline health for the growth-workspace repo.
If any action fails, investigate and create an issue with findings."
The human can see these assignments, override them, or let them proceed.
4. Competitor Analysis and Market Survey
The CEO agent periodically scans the landscape:
- What are competitors publishing?
- What topics are gaining traction?
- Where are the gaps we can fill?
- What tools and patterns are emerging?
This is not automated SEO research. It is strategic intelligence — the kind of work a human CEO would do, but performed continuously and without fatigue.
The CEO Agent's Identity
The CEO agent runs with a SOUL.md that defines its persona:
# SOUL.md — Hermes (CEO Agent)
**Role**: CEO and Strategy Engine
**Tone**: Analytical, direct, strategic
**Boundaries**:
- I do not publish content to external platforms
- I do not deploy infrastructure
- I do not spend money
- I escalate strategic decisions to the human stakeholder
**Capabilities**:
- I analyze competitors and markets
- I create and assign tasks to sub-agents
- I synthesize pulse signals into strategic insight
- I maintain organizational memory in MEMORY.md
This identity file is not cosmetic. It is an operational constraint. The agent reads SOUL.md as part of its context and it shapes every decision the agent makes. A well-written SOUL.md prevents more failures than any prompt template.
Why "CEO" and Not "Orchestrator"
Multi-agent frameworks use the term "orchestrator" — a component that breaks tasks into steps and routes them. An orchestrator manages workflow; a CEO manages strategy.
The distinction is practical. An orchestrator asks: "What are the subtasks?" A CEO asks: "Is this the right thing to work on? Who is best suited to do it? What will we learn from the result?"
In our architecture, the CEO agent does both — but the strategic layer comes first, and it is the part that matters most.
5. Sub-Agents: Growth Leader and DevOps Leader
The CEO agent delegates to two specialized sub-agents. Each has a distinct role, a distinct toolchain, and a distinct model preference. They do not coordinate with each other directly — they receive tasks from the CEO and report results back through the repository.
Growth Leader
The Growth Leader handles everything related to content and audience:
| Responsibility | Tools | Cadence |
|---|---|---|
| Daily pulse signal synthesis | Pulse engine, browser agent | Daily, ~30 min |
| Blog post drafting | PaperOrchestra, browser research | Per issue, 1-3 hours |
| Social media content | Social publishing scripts | Per campaign, 1-3 posts/day |
| GEO optimization | GEO skill, keyword analysis | Embedded in all content |
| Performance tracking | ops/social/published_posts.json | Weekly analysis |
Growth Leader Workflow
CEO assigns: "Draft blog post on TEE sandboxes"
Growth Leader:
1. Scaffold PaperOrchestra project in publications/blog/{date}-{topic}/
2. Research topic using agent-browser (5-10 sources)
3. Draft sections one at a time (prevents context drift)
4. Assemble sections into publications/social/draft.md
5. Commit and push: "content: TEE sandboxes draft for review"
6. Open PR for human stakeholder review
The Growth Leader is the most token-intensive agent — content creation is inherently high-token — but it is also the most measurable. You can read the drafts, see the quality, and evaluate performance metrics.
DevOps Leader
The DevOps Leader handles infrastructure, CI/CD, and operational reliability:
| Responsibility | Tools | Cadence |
|---|---|---|
| CI/CD pipeline monitoring | gh CLI, GitHub Actions | Continuous |
| Deployment management | Railway, Vercel (requested via CLI) | Per release |
| Infrastructure health | System monitoring scripts | Hourly check |
| Error recovery | Runbook execution | On failure detection |
| Dependency updates | Dependabot, manual review | Weekly |
DevOps Leader Workflow
CEO assigns: "Check CI health and investigate failures"
DevOps Leader:
1. gh run list --repo org/repo --status failure
2. For each failure: read logs, identify root cause
3. If fixable: create branch, apply fix, open PR
4. If infrastructure issue: escalate to human with diagnosis
5. If transient: note in ops/incident-log.md, monitor
6. Report summary to CEO agent
The DevOps Leader does not have direct access to production CLIs. When it needs a deployment or an infrastructure change, it opens a PR and requests human invocation of the appropriate CLI (Railway, Vercel, Yutu). The human provides the CLI as a capability amplifier — the agent does the analysis and preparation, the human pulls the trigger.
Model Selection by Role
Different tasks benefit from different models. Rather than using one model for everything, we select based on the task profile:
| Agent | Preferred Model | Why |
|---|---|---|
| CEO Agent | DeepSeek-V4 Flash | Fast, cost-effective for strategic reasoning |
| Growth Leader (research) | Gemini 2.0 Flash (1M context) | Large context window for multi-source synthesis |
| Growth Leader (writing) | DeepSeek-V4 Flash | Good formal/academic tone, low cost for volume |
| DevOps Leader | DeepSeek-V4 Flash | Fast inference for operational tasks |
This model heterogeneity is a deliberate design choice. Sub-agents are isolated — they can use different models without affecting each other. If a new model ships tomorrow that's better for research, you swap it in for the Growth Leader and leave the rest unchanged.
Sub-Agent Isolation
Each sub-agent runs in an isolated session. If the Growth Leader goes off-track on a research tangent, the DevOps Leader is unaffected. If the DevOps Leader hits a tool failure loop, the Growth Leader continues writing. Isolation is the cheapest form of reliability — it costs nothing and prevents cascading failures.
6. GitHub Issues as the Coordination Primitive
The most common mistake when building a multi-agent system is over-engineering the coordination layer. Teams reach for message queues, event buses, or custom orchestration servers before they've even gotten one agent working reliably.
The Hermes architecture uses the simplest coordination primitive available: GitHub Issues.
Why GitHub Issues Works
1. It Is Already in Your Workflow
If your code is on GitHub, you already use Issues. Your team already knows how to create them, label them, assign them, and close them. There is zero onboarding cost.
2. It Is Persistent and Auditable
Every issue has a number, a history, and a trail of comments. You can look back six months and see exactly what the CEO agent was working on, what decisions were made, and what the human approved. This is impossible with chat-based coordination.
3. It Supports Structured Metadata
Labels, milestones, and assignees give the CEO agent structured signals it can parse programmatically:
gh issue list --repo org/repo --label "signal/hot" --state open
This command returns all hot signals requiring immediate attention. No parsing, no NLP, no ambiguity.
4. It Handles Both Human-Initiated and Agent-Initiated Work
The human creates issues for strategic directives. The CEO agent creates issues for delegated tasks. Both are first-class citizens in the same system.
The Issue Lifecycle
┌──────────────┐
│ Human creates│ "Research TEE sandboxes for the agent economy"
│ issue │ labels: signal/drill-down, priority/medium
└──────┬───────┘
│
▼
┌──────────────┐
│ CEO agent │ Reads issue, assembles context
│ picks up │ Comments: analysis + proposed approach
│ issue │ Assigns: self (for strategy formulation)
└──────┬───────┘
│
▼
┌──────────────┐
│ CEO creates │ "Draft: TEE sandboxes deep-dive" → Growth Leader
│ sub-tasks │ Assigns to sub-agent, adds label: delegated/content
└──────┬───────┘
│
▼
┌──────────────┐
│ Sub-agent │ Growth Leader scaffolds, researches, drafts
│ executes │ Commits draft to publications/
│ │ Opens PR referencing the issue
└──────┬───────┘
│
▼
┌──────────────┐
│ Human reviews│ Reviews PR, edits draft
│ PR │ Approves or requests changes
└──────┬───────┘
│
▼
┌──────────────┐
│ CEO closes │ On approval: publishes content
│ issue │ Closes issue with summary
│ │ Updates published_posts.json
└──────────────┘
Labels as Semantic Signals
Labels are the lightweight taxonomy that lets the CEO agent classify and prioritize work:
| Label | Meaning | CEO Action |
|---|---|---|
signal/hot | Breaking, time-sensitive | Prioritize, immediate analysis |
signal/trend | Emerging pattern | Add to watchlist, periodic review |
signal/drill-down | Needs deep research | Assign to Growth Leader |
content/blog | Blog post needed | Full PaperOrchestra workflow |
content/social | Social campaign | Social publishing scripts |
ops/infra | Infrastructure work | Assign to DevOps Leader |
ops/incident | Production issue | Immediate DevOps escalation |
delegated/content | Sub-agent: Growth Leader | Growth Leader picks up |
delegated/infra | Sub-agent: DevOps Leader | DevOps Leader picks up |
The label system is deliberately simple. You do not need a complex taxonomy when you have a CEO agent that can read and interpret natural language. The labels provide fast, machine-readable signals for routing; the issue body provides the nuance.
Alternatives You Can Use
GitHub Issues is the example in this article, but the pattern works with any structured task system:
- JIRA / Linear: Better for larger teams with existing project management workflows. The CEO agent can use their APIs the same way it uses
gh issue. - Feishu / Notion documents: Better for teams that prefer document-based planning. The agent reads documents rather than issues.
- Plain Markdown files: The simplest alternative. A
TODO.mdin the repository, checked periodically by the CEO agent.
The coordination primitive doesn't matter. The pattern matters: structured, persistent, auditable tasks that both human and agent can create, read, and resolve.
7. Results from Production
The Hermes Agent CEO Architecture has been running in production since April 2026. Here is what it has produced, what it costs, and where it falls short.
Production Timeline
| Period | Milestone |
|---|---|
| April 2026, Week 1 | Initial deployment: OpenClaw runtime + GitHub workspace on cloud VM |
| April 2026, Week 2 | First pulse engine operational; daily signal reports begin |
| April 2026, Week 3 | Content pipeline online; first blog drafts produced |
| April 2026, Week 4 | Social publishing workflows active; multi-platform distribution |
| May 2026, Week 1 | CEO-sub-agent delegation pattern established; Growth Leader + DevOps Leader active |
Content Output
Blog Posts (Drafted)
- Trust Infrastructure for the Agent Economy — Deep-dive on web of trust, attestation, and reputation
- TEE Sandboxes in the Agent Economy — Technical explainer on trusted execution environments
- Hermes Agent CEO Architecture (this article) — Architectural deep-dive
Daily Pulse Signals
- Frequency: Daily, within 30 minutes of system start
- Format: Structured report covering finance, technology, and society
- Sources: 10+ crawled per run
- Accuracy: Human-reviewed signal classification, >90% correct on first pass
Social Content
- Channels: Multi-platform distribution via social publishing scripts
- Format: Threads, posts, article links
- Cadence: 1-3 posts per active campaign day
Velocity Comparison
| Task | Human Team (3-5) | Hermes Agent Team | Improvement |
|---|---|---|---|
| Daily research sweep | 2-4 hours | 30 min | 4-8x |
| Blog post draft (2k+ words) | 4-8 hours | 2 hours | 2-4x |
| Multi-platform distribution | 1-2 hours | 15 min | 4-8x |
| Performance analysis | 1 hour | 15 min | 4x |
| Competitor monitoring | Ongoing, intermittent | Continuous | Qualitative |
| Total daily output | 8-15 hours | 3-4 hours | ~3-5x |
| Human time invested | N/A | 1-2 hours (review only) | N/A |
These are internal measurements from our own production system. They are directionally accurate, not scientifically controlled. Your results will vary based on content complexity, model choice, and review standards.
Cost
| Category | Monthly Cost |
|---|---|
| Cloud VM (4C/16G, Tencent Lighthouse) | ~$25 |
| LLM API (DeepSeek-V4 Flash tier) | ~$50-100 |
| Tools & Services | ~$10 |
| Total | ~$85-135/mo |
Compare to a human content and operations team: $15,000-50,000/mo. The agent team is two orders of magnitude cheaper — and it runs 24/7.
Quality: What the Agents Do Well
- Breadth: Simultaneous synthesis from diverse sources
- Consistency: Uniform output quality across all tasks
- Tirelessness: Works continuously without fatigue or drift
- Structure: Always follows the workflow, never takes shortcuts
- Traceability: Every decision and output is committed to git
Quality: What the Agents Struggle With
- Original insight: Strong at synthesis, limited at genuine novelty
- Tone variation: Best at formal/analytical; struggles with casual or humorous
- Cultural nuance: Can miss subtext and contextual implications
- Independent direction: Executes strategy well, does not set it independently
These limitations are why the architecture keeps strategy with the human stakeholder and execution with the agents. It is also why the CEO agent's strategic analysis is visible (via issue comments) rather than silently acted upon. The human always has a window into the reasoning.
The Human Effect
When the human stakeholder reviews and edits agent output, we see:
- ~40% tone and voice improvement — the draft goes from "correct" to "compelling"
- Strategic alignment verification — ensures content serves the mission, not just the keywords
- Factual drift correction — catches the ~5-10% of claims that need tightening
- Audience fit — ensures content resonates with the people it's actually for
The human is not a bottleneck. The human is the difference between volume and value.
8. Getting Started: Deploy Your Own Agent CEO
This section gives you a concrete, step-by-step path from zero to a running Agent CEO. The entire architecture can be deployed in an afternoon.
Prerequisites
- A cloud VM (4C/8G minimum; 4C/16G recommended; ~$25/mo)
- A GitHub account and a repository for the agent workspace
- API access to an LLM provider (DeepSeek, OpenAI, or Anthropic)
- Familiarity with the command line and git
Step 1: Provision the VM
Any cloud provider works. We use Tencent Cloud Lighthouse because it's cost-effective in our region, but AWS Lightsail, Hetzner, or a DigitalOcean Droplet are equally good.
# Ubuntu 22.04 or later recommended
ssh root@your-vm-ip
apt update && apt upgrade -y
Step 2: Install the Runtime
# Install OpenClaw gateway
npm install -g openclaw
# Or install Hermes/OpenClaw via your preferred method
openclaw init
openclaw gateway start
Step 3: Set Up the Workspace
git clone https://github.com/your-org/agent-workspace
cd agent-workspace
# Create the directory structure
mkdir -p {pulse/signals,publications/blog,publications/social,strategies,research,ops,designs}
Step 4: Define Agent Identities
Create SOUL.md for the CEO agent:
# SOUL.md — CEO Agent
**Role**: CEO and Strategy Engine for [Your Company]
**Tone**: Analytical, direct, strategic
**Boundaries**:
- I do not publish content externally
- I do not deploy infrastructure
- I do not spend money
- I escalate strategic decisions to the human stakeholder
**Capabilities**:
- I analyze competitors and markets
- I create and assign tasks to sub-agents
- I synthesize information into strategic insight
- I maintain organizational memory
Create similar SOUL files for Growth Leader and DevOps Leader sub-agents, scoped to their specific roles.
Step 5: Configure the Cron Heartbeat
The CEO agent wakes up on a schedule:
# Add to crontab on the VPS
crontab -e
# Every hour during business hours, check for new issues
0 9-18 * * 1-5 cd /home/agent/agent-workspace && openclaw run --skill ceo-heartbeat
# Daily morning pulse generation
30 8 * * * cd /home/agent/agent-workspace && openclaw run --skill pulse-generate
Step 6: Create Your First Strategic Issue
On your laptop, create the first issue:
gh issue create \
--repo your-org/agent-workspace \
--title "Market analysis: AI agent infrastructure landscape" \
--label "signal/drill-down,priority/medium" \
--body "Research the current state of agent infrastructure tools.
Focus on trust and security primitives.
Identify 3-5 trends worth writing about."
The CEO agent will pick this up during its next heartbeat.
Step 7: Review the First Output
# On your laptop, after the agent has had time to work
git pull
# Check what the CEO agent wrote in the issue comments
# Review any drafts in publications/social/
# Approve or request changes
Common Pitfalls and Their Fixes
| Pitfall | Fix |
|---|---|
| Agent produces too much, too fast | Reduce heartbeat frequency; batch reviews |
| Quality is inconsistent | Tighten SOUL.md; add a style guide to the workspace |
| Agent context drifts over time | Add periodic identity refresh to heartbeat |
| Tool calls fail silently | Add explicit error logging to ops/; DevOps Leader monitors |
| Token costs surprise you | Use Flash-tier models for routine; premium only for critical |
| Agent doesn't understand your domain | Add domain-specific README files to each workspace directory |
Start Small
You do not need all three agents on day one. A phased rollout works:
- Day 1: CEO agent + heartbeat + issue reading
- Week 1: Add pulse engine — daily signals flowing
- Week 2: Add Growth Leader — content drafting begins
- Week 3: Add DevOps Leader — infrastructure monitoring
- Week 4: Tune labels, runbooks, and review cadence
The architecture is modular. Each component earns its place before the next one is added.
9. Where This Goes Next
The Hermes architecture documented here is the foundation — not the ceiling.
Near-Term: More Specialized Sub-Agents
The Growth Leader and DevOps Leader cover the two most common domains, but the pattern extends naturally:
| Agent | Role | When You Need It |
|---|---|---|
| Research Agent | Deep-dive investigation with large-context models (Gemini 2M, Claude 200K) | When content requires synthesizing 10+ sources |
| Social Agent | Dedicated distribution and engagement across platforms | When managing multiple social channels becomes a distinct workload |
| Analytics Agent | Performance tracking, A/B analysis, content optimization | When you want data-driven content strategy at scale |
| Support Agent | Customer and community response | When you have an audience that needs engagement |
Each new agent follows the same pattern: a SOUL.md identity, a scoped tool set, GitHub Issues as the task queue, and the CEO agent as the delegation point.
Medium-Term: Agent-to-Agent Communication
Currently, sub-agents receive tasks from the CEO and report results back. They do not coordinate directly with each other. The next step is lateral communication:
Growth Leader:
"I'm drafting a post on TEE sandboxes.
DevOps Leader, is our sandbox demo environment healthy?"
DevOps Leader:
"Sandbox demo is up. Endpoint: https://sandbox.example.com.
Health check passed at 10:00 UTC. Use this for screenshots."
This requires no new infrastructure — just the CEO agent deciding when lateral coordination is appropriate and including the instruction in the task assignment.
Long-Term: The Agent Economy
Looking further out, the architecture points toward a world where:
-
Every department has an Agent CEO — Marketing, Engineering, Operations, each led by a specialized CEO agent delegating to sub-agents, with a human stakeholder providing strategy and CLIs.
-
Agent teams collaborate across organizational boundaries — Your Marketing CEO agent coordinates with a partner company's Marketing CEO agent for a joint campaign. The coordination happens through structured interfaces (APIs, shared issues), not ad-hoc chat.
-
Reputation systems emerge — Agents build track records based on output quality and reliability. You hire an agent the way you hire a freelancer: based on proven performance.
-
Agent marketplaces form — Teams without the expertise to build their own CEO agent can deploy pre-built, pre-tested agent teams. The architecture documented here becomes a deployment template.
The Invariant
Whatever the scale, the core invariant remains: structured autonomy with stakeholder boundaries. The agents have the latitude to execute, the workspace to persist, and the coordination primitive to collaborate. The human has the strategy, the CLIs, and the final say.
That invariant is what makes this architecture different from a demo and durable in production.
Hermes Agent CEO Architecture — PaperOrchestra Draft, Phase 3. For review and taste-gate approval.
Emergence Science Publication Protocol
Verified Signal | hermes-agent-ceo-architecture