All work

Production · Architect and sole engineer · 2025 to present

Always-on agent runtime

Roughly 10 scheduled agent workflows running unattended for weeks, with a human approving every state change

  • TypeScript
  • MCP
  • Docker
  • systemd
  • Tailscale
  • OpenRouter
  • Telegram
  • HMAC

The constraint

An unattended agent with write access to production is a liability, not a feature. Everything here is built around that: a default-deny trust ladder, a human approval step on every state-changing action, and no auto-merge anywhere in the pipeline.

What it is

The agent infrastructure I run my own operation on. Scheduled workflows, a ticket-to-PR pipeline, and a governance layer that refuses by default. It saves about 10 hours a week, and it is where the on-prem and policy patterns get tested before a customer sees them.

What shipped

  • Roughly 10 scheduled agent workflows running unattended for weeks at a time, each of which proposes and waits.
  • A ticket-to-PR pipeline: HMAC-authenticated machine API intake, Claude Code drafting under safe-path guards, then a PR routed for human approve or reject over Telegram with no auto-merge, followed by deploy and idempotent time logging.
  • A governance MCP server in TypeScript with a 57-test suite covering propose, policy-decide, append-only audit, and rollback on a default-deny trust ladder.
  • Four coordinated always-on services on a hardened VPS: Docker-isolated, systemd-sandboxed, Tailscale-private, with an HMAC-signed control channel.
  • Routing across roughly 15 cost-tiered model slots through one OpenRouter gateway serving hosted open-weight models including Qwen3-235B, with a local catalog-override manifest and TTL prompt and response caching.
  • A warm-session sidecar holding an open Agent Client Protocol JSON-RPC session, which cut Vapi voice-agent cold start from about 25 seconds to a few seconds.

Measured outcome

  • About 10 hours a week returned, with a human approving every state-changing action.
  • Found and remediated real defects in my own production stack: hardcoded secrets, a committed HMAC key, and an unauthenticated debug endpoint. I led the rotation.
  • Migrated to k3s with the trust boundaries moved into NetworkPolicy. See backbone-on-k8s for the verification record.

Why it is built this way

  • The governance server is the same shape as the policy engine in Little Bear Foundry. Running it against my own infrastructure first is how the propose-then-approve pattern got its 57 tests.
backbone-on-k8sagent-fleet-on-eks