Agency playbook: one isolated Hermes per client

Package always-on Hermes as one isolated SEAOTTER agent per client. Per-agent namespaces. Write-only secrets. Lifecycle APIs. No VPS per retainer.

Isolation lives in provisioning and secrets.

Agencies and freelancers are who we built per-agent isolation for. Not one shared agent hoping brands never collide.

The packaging problem

Client agent work fails in predictable ways when infrastructure is shared or fragile:

• Blast radius — one host, many clients; one outage takes everyone down.
• Context bleed — one “shared” agent memory and credential set across brands.
• Ops tax — every new client becomes another installer, another box, another night of deploys.

Agencies already think in engagements. The plane should match that unit.

Isolation is the product unit

On SEAOTTER, isolation is per agent: Kubernetes namespace agent-{id}, plan quotas, NetworkPolicy (ingress from the shared edge only; egress DNS + HTTPS), and no shared process namespace between tenants. New agents run under gVisor and fail closed on the sandbox_verified provisioning stage if the sandbox is missing.

Treat each client engagement as one agent:

1. Create — Name the agent for the client (API or dashboard). Pick a region. POST returns provisioning immediately.
2. Poll — Watch provisioning stages through wizard_reachable until status is running (typically a few minutes).
3. Connect — Attach model credentials for that agent’s workload (Nous / BYOK as documented). Control-plane API keys are not the same as the tenant Hermes dashboard credentials—reveal when you need them.
4. Prove value — One cron or chat job that shows always-on for the retainer: triage, research, inbox, whatever the SOW says.
5. Operate — Pause, restart, restore, upsert secrets, pull logs—without SSH into a client-named VPS.

When the engagement ends, pause or delete that agent. You do not inherit a zombie VM inventory.

Secrets and credentials: agency hygiene

Best practice on the plane:

• Separate agents ⇒ separate secrets. Upsert via the Secrets tab or secrets API so values live in Secret Manager; Hermes loads them at startup. The control plane stores references, not a shared spreadsheet. Prefer Secrets over pasting keys into chat.
• Rotate when people change. Reveal and rotate tenant credentials through the API when a teammate leaves the engagement.
• Keep a restore drill. Restore rebuilds the Hermes home volume from a snapshot and keeps the hostname stable—practice once before the first client incident.

Do not pitch “set and forget forever.” Pitch ops without owning the stack—with lifecycle tools when something flakes.

What “no VPS” means in a pitch

SEAOTTER handles isolation, TLS, backups, and lifecycle. You do not sell a VPS farm.

You still own:

• Clear client boundaries (separate agents, separate secrets).
• Who can rotate credentials.
• The SOW and billable scope.

For founders on a single agent, $99 per agent / month is the one-agent, no-ops-hire path. For agencies packaging per client, add a licensed seat at +$99, or book Custom as the fleet grows. See pricing.

Activation checklist (agency-shaped)

Ship this before you scale the pitch:

1. One client agent provisioned and running.
2. Model path connected for that agent only.
3. One scheduled or chat job that proves always-on value.
4. Secrets via the plane—not a shared password doc.
5. A restore or restart drill so the first incident is not inventing process.
6. Engagement end-state documented: pause vs delete, who owns the data handoff.

Start the next retainer on the plane

Isolated agents per client—without another VPS each time. Create, poll, run. A 7-day trial with no credit card is the same badge under pricing—then +$99 per always-on agent once you are packaging per client.

• Why managed Hermes · Self-host vs managed
• What is SEAOTTER? · docs.seaotter.dev