Hardware
- Local: 2024 MacBook Pro — primary hub for code development, coordination, and personal use; hosts the local fleet agent.
- Cloud: Google Cloud Platform (GCP), for elastic compute and managed services.
Agent Fleet
My setup is a three-tier Hermes Agent fleet. Each agent has its own identity, memory, and role:
| Agent | Host | Role | Notes |
|---|---|---|---|
| Cloud agent (Fenit) | Nous Portal (managed VPS) | Primary personal assistant, always-on | Telegram-connected; default model stepfun/step-3.7-flash:free; durable persistent storage |
| Family agent | Profile on the same VPS | Family assistant | Kids’ activities, education, events, meal/vacation planning |
| Local agent | Local (MacBook Pro) | Local desktop agent | Private/local-first workflows |
| Elastic agent | GCP (spot L4 GPU) | Elastic GPU inference | Scale-to-zero; serves an open-weight MoE via llama.cpp; spun up on demand |
Fleet design doc: hermes-fleet-design (private repo).
Cloud Agent (Fenit) — Hermes Agent on Nous Portal
- Runtime: Hermes Agent (Nous Research), hosted on a managed VPS
- Default Model:
stepfun/step-3.7-flash:free— StepFun’s Step 3.7 Flash (198B MoE, ~11B active, 256K context, Apache 2.0), routed via the Nous provider - Persistent Storage: Durable volume (
/opt/data) for config, skills, memories, and session history; survives restarts - Platform Integration: Telegram (primary), web dashboard, TUI — all platforms share the same session history, so conversations continue across devices
- Skill System: Modular, user-authored skills covering GitHub workflows, Google Workspace (Gmail/Calendar/Drive/Docs/Sheets), event digests, planning, research, and media processing
- Scheduling: Cron jobs (morning briefings, weekly event digests, price tracking) with per-job model pinning and toolset restrictions to control token spend
- Cross-session memory: Persistent memory store injected into every session, plus full-text search over past session transcripts
Shared Memory Across Agents
Agents in the fleet share a common memory store so conversations pick up seamlessly when switching between the Mac and cloud agents:
- Store: a shared Google Firestore collection holding shared
MEMORYandUSERdocuments - Sync convention: agents push to Firestore whenever they update local memory with anything fleet-relevant, and pull the shared store at session start when context matters
- Handoff notes: after substantive work, the active agent writes a short current focus note so the next agent can continue without a re-briefing — the goal is moving between agents without repeating context
Context & Document Pipeline
When documents are shared (PDFs, links, plans, schedules), agents place them autonomously rather than asking where they should go:
- Infrastructure repo (private) is the source of truth for durable knowledge — skills, procedures, and living context files. Agents read fresh at point-of-use and update durable facts there.
- Large reference blobs (e.g. full text of plan documents) go to the shared Firestore collection, registered in a manifest in the repo and pushed by a small script — so every agent can read them without bloating the repo or every skill load.
- Per-agent working data stays local to the host that owns it.
- Fleet audit: each agent runs a self-audit on its own host weekly and reports to the shared store; the primary agent aggregates all hosts and alerts only when something drifts (stale or missing reports, out-of-sync skills). Silent when clean.
Google Cloud Services
- Secret Manager: credentials and API keys for the fleet (e.g., per-bot Telegram tokens), referenced by agents at runtime
- Service accounts: scoped per-agent identities for Drive, Calendar, and Firestore access
- GCP spot compute for the elastic tier
Local Model Inference
The elastic GCP tier already serves an open-weight MoE model via llama.cpp on a spot L4 GPU (scale-to-zero). The notes below cover the complementary option of a dedicated local Mac for private, no-token-cost inference.
Target workload
Agentic tool-use (terminal, API calls, repo edits), research synthesis, and personal planning — approximated locally by a ~32B class instruct model (e.g., Qwen2.5 32B Q4, ~19GB) or a mid-size MoE coding model.
Recommended options (Mac mini, refreshed August 2026)
| Config | Memory | Est. Price | Verdict |
|---|---|---|---|
| Mac mini M6 / 32GB | 32GB unified | ~$1,100 | Entry point — runs 32B Q4 but tight alongside macOS; best as a dedicated inference box |
| Mac mini M5 Pro / 48GB | 48GB unified | ~$2,000–2,200 | Recommended — comfortable 32B Q4 fit with headroom; ~25–40 tok/s expected |
| Mac mini M5 Pro / 64GB | 64GB unified | ~$2,400 | Room to grow into 70B-class models at Q3 |
If scaling beyond Mac mini
- Mac Studio M5 Max (from $2,499, up to 128GB, 614GB/s bandwidth) — fits 70B-class comfortably, or small MoE models
- Mac Studio M5 Ultra (from $5,499, up to 512GB, 1.2TB/s) — runs frontier-class open MoE models (100B+ total params) entirely on device; supports clustering multiple machines via Thunderbolt 5 + RDMA for even larger models
Local inference stack
- Ollama — simplest setup, auto-manages GGUF models, OpenAI-compatible endpoint for agent integration
- MLX / MLX-LM — Apple’s framework, typically 20–40% faster than llama.cpp on Apple Silicon
- LM Studio — GUI for model management and local serving
Notes
- There is no exact local equivalent to the hosted default model (Step 3.7 Flash’s sparse 198B MoE + agentic training). A 32B local model covers roughly 80% of the daily assistant workload; the hosted route remains stronger for complex multi-step reasoning.
- A hybrid setup — local model for routine/private tasks, hosted model for heavy lifting — is the pragmatic sweet spot.
Appendix: Legacy OpenClaw Setup (retired)
The fleet previously ran on OpenClaw, self-hosted on GCP. Retired in September 2026 in favor of the Hermes fleet described above; kept here for reference.
Hardware (legacy)
- Cloud: GCP
n2d-highmem-4(4 vCPUs, 32 GB RAM), 100 GB Persistent Disk, Spot Instance (Preemptible) with automated cost-management.
OpenClaw (self-hosted on GCP)
- Runtime: OpenClaw
- Primary Configuration: Gemmaclaw
- Core Model:
gemma4:e4b(running via Ollama/Local inference on the GCP VM) - Fallback/Cloud Model:
google/gemini-flash-latest
Infrastructure Automation (legacy)
- Cloud Functions: A dedicated
openclaw-starterfunction for remote lifecycle management. - Cloud Scheduler: Automated “Morning Start” (7:30 AM ET) and “Nightly Stop” (12:00 AM ET) jobs.
Agent Registry (legacy)
A multi-agent system where each “echo” had a specific domain and security profile:
| Agent | Role | Scope | Key Skills |
|---|---|---|---|
| Hermes | Primary Assistant | Privileged / Personal | GitHub, Google Workspace, Travel, Planning, Memory Search |
| echo1 | Assistant (OpenClaw) | Privileged / Personal | BlueSky, Email, Long-term Memory |
| echo2 | Research & Intel | Technical / Public | Market Research, BlueSky Monitoring |
| echo4 | Ops & Kitchen | Sandboxed / Family | Recipe Management |
Key Capabilities (legacy)
- Memory & Continuity: Distilled long-term wisdom stored in
MEMORY.md, with daily logs capturing raw session context. - Automated Heartbeats: Periodic checks for high-priority emails and calendar events.
- Platform Integration: Deep integration with Telegram, BlueSky, and GitHub.
Last Updated: October 2026