I've been doing forward deployment for myself

For the past several months I’ve been running Hermes Agent as my primary interface for almost everything I build. Not as a chatbot. More like a persistent coworker who has root access, knows my VPS layout, understands my deploy workflows, and can pick up a task from a Telegram message and see it through to a deployed change.

At some point I realized I was spending as much time configuring and operating the agent system as I was building with it. And that the two activities had become hard to separate.

What I actually do

The setup is: Hermes runs on the VPS, connected to Telegram. I send it tasks. It has persistent memory, a skill library of documented workflows, cron jobs for recurring ops, and access to my full infrastructure — GitHub, Caddy, Docker, pass, x402-gated services.

The operational picture looks like this:

• Skills encode how specific things work on my stack — not generic docs, but the actual deploy sequence for engram, the correct way to reload Caddy without destroying the live Caddyfile, which GitHub remote uses SSH vs HTTPS
• Memory stores stable facts so I don’t have to re-explain context: service ports, secret locations, known infra quirks
• Cron jobs handle recurring work: weekly blog retros, daily service health digests, Engram balance checks that post USDC readings to Telegram each morning
• Claude Code handles nontrivial coding tasks via delegation so the orchestration layer stays lean

The thing that required the most judgment wasn’t the initial setup. It was the ongoing work of figuring out what the agent should handle autonomously versus what should route back to me.

Where it breaks

The failures are instructive. I’ve run into three categories:

Precondition blindness. The clearest example is The Wipe — an agent ran mkdir -p on a directory that already had data in it, then pulled new containers that remounted it under a different uid. Every command succeeded individually. The data was effectively gone. The failure wasn’t a wrong command — it was a missing check: does this already exist? Neither of us specified that precondition because it seemed obvious.

Skill drift. When I documented a workflow once and it worked, I assumed it would keep working. But infrastructure changes. A GitHub token scope that worked for one operation failed for another six weeks later. A deploy script that assumed one Caddy config structure broke after a routine Caddyfile refactor. Skills have to be maintained. An outdated skill is worse than no skill — it gives the agent false confidence.

Scope creep in long tasks. Multi-step tasks that cross service boundaries are where things get tangled. “Update the landing page and deploy it” is one step. But that task touches the infra repo, git, GitHub Actions, Caddy, and a health check — and if any one of those has a stale state, the agent has to improvise. The more services in the blast radius, the more places for the improvisation to go wrong.

These aren’t arguments against the approach. They’re the calibration surface. Every failure taught me something about where the boundary between autonomous execution and human judgment actually sits.

What I’ve learned about deploying agents into real systems

The work that actually takes time isn’t the agent setup. It’s the environment instrumentation.

For Hermes to operate reliably on my infrastructure, I had to document the actual state of the system — not the ideal state, the actual state. Which secrets are in pass vs which are stale in .env files. Which git remotes use SSH and which use HTTPS and why. Which services have health endpoints and which don’t. Which GitHub Actions workflows are working and which are silently broken.

Most of that knowledge lived in my head or was scattered across a month of terminal history. Extracting it into skills and memory wasn’t glamorous work. But it’s what made the difference between an agent that could execute a task once with heavy prompting and one that could execute the same class of tasks reliably, on its own, three weeks later.

The pattern I’ve landed on: treat the agent’s knowledge base as part of the system. Skills, memory, cron configs — these are artifacts that need the same maintenance discipline as the code they operate on. When a deploy changes something, the skill that documents that deploy should change too. Otherwise the agent drifts from the system it’s supposed to manage.

The thing I didn’t expect

I thought the interesting part would be what the agent could do. It turned out the interesting part is how you structure what the agent knows.

The difference between an agent that reliably handles a deployment and one that doesn’t usually isn’t model capability. It’s whether the relevant context — the service topology, the known failure modes, the correct command sequence — is in a form the agent can actually use. Good documentation written for agents is a different thing than good documentation written for humans. Shorter. More specific. Explicit about preconditions and pitfalls.

I’ve started thinking of this as the primary skill: not “can you build agents” but “can you structure an environment so that agents succeed in it.” That’s what I’ve been learning to do.

I’m not sure where that skill leads. But I have a decent amount of evidence it’s the right thing to be learning.