AFO Agent OS

The setting

My agency maintains a fleet of client sites and a stack of recurring operational work: check-ins, content updates, lead follow-ups, monitoring. That’s exactly the shape of work AI agents are good at — if you can trust them. The off-the-shelf answer was an existing open-source agent runtime. I evaluated it and decided to build my own orchestration layer instead.

That decision is the case study.

Why build instead of adopt

The runtime I evaluated had a consolidation problem: every subagent pinged me independently, which at any real scale turns “automation” into a second inbox. I could have patched around it. But I build to own it — and an agent system that acts on my business, with my credentials, is the last place I want a black box. So the orchestrator became mine: it consolidates all agent output into a single digest, and nothing outward-facing happens without passing an approval gate that is enforced in code. Not a prompt instruction an LLM might ignore. A code path that doesn’t exist without approval.

Where each piece lives, and why

Systems design here is mostly about placement constraints:

• The agent loop runs on a VPS as a long-running Node process — Vercel functions time out, and an orchestrator that needs to think for minutes can’t live in a 60-second box.
• The command-center UI is Next.js on Vercel — public, fast, and it means the VPS needs zero open inbound ports. The UI talks to state, not to the box.
• PocketBase holds data and memory — managed and boring until self-hosting is justified by real load. Managed-until-it-matters is a principle, not a compromise.
• Telegram is the interaction surface — the digest arrives where I already live, and approvals are one tap.

VPS — no open inbound ports

OrchestratorNode · 24/7

↓→

Workers

single digest + approval gate (in code)↓→

Telegramdigest + approval

PocketBasestate / memory — VPS + Vercel

Next.js command centerVercel · public

• Workers → Telegram directly: no per-agent pings

The threat model

Running a third-party agent runtime and my own system as the same OS user would mean a compromised runtime could read my .env and walk off with every credential I own. So AFO runs as a dedicated non-root afo user with chmod 600 on secrets, and the roadmap is per-container isolation with Docker — one blast radius per agent, not one blast radius for the business. Prompt-injection surfaces get the same treatment: anything an agent reads from the outside world is treated as untrusted input to the orchestrator, never as instructions with authority.

Scope discipline

v1 is deliberately small: the orchestrator spine, idea intake, and a client-watcher targeting one concrete workflow — the biweekly client check-in — as the first proof point. Everything else is specified but dormant. (There’s also a Factorio-inspired “factory floor” visualization of the agents on the roadmap, because a system you can see is a system you debug faster — and because building things should be a little fun.)

Why this project matters to an employer

This is current, self-directed engineering in the part of the field that’s moving fastest — and it demonstrates the judgment that matters there: when to build versus adopt, where code must enforce what convention can’t, and how to threat-model a system that acts autonomously with real credentials.