Building a Fleet of Persistent AI Agents Without an Extra Subscription

Building a Fleet of Persistent AI Agents Without an Extra Subscription

Why not just use an existing agent framework?

Tools like Hermes or OpenClaw give you that “personal AI assistant with a name and a memory” feel, but they can burn through tokens fast — especially as an agent’s skill count grows, since each one is usually billed on metered API usage. I was already paying for a CLI-based AI subscription plan. The question became: could I get the same durable-identity, multi-agent feel using files and structure alone, riding on a cost I was already covering, instead of adding a separately-billed framework on top?

What it does

Agent Creation gives an AI CLI tool a persistent identity — who it is, what it knows, what it’s responsible for, where its memory lives — defined entirely in plain files, no code required. I ended up with two patterns, and most of my real setup uses both:

• Directory-scoped agents: a dedicated folder holding a CLAUDE.md (identity, personality, responsibilities), a .claude/settings.json (pins the model explicitly — more on why below), and the agent’s working files — memory.md for long-term knowledge, a Logs/ folder for status history, a reports/ folder for point-in-time deliverables. Launching the CLI tool with that folder as the working directory makes it become that agent. This is what I use for agents with real ongoing state — a NAS agent that remembers past incidents, a personal-assistant agent that remembers my schedule.
• Context-injected agents: a single .md file with the same identity content, no folder, no persistent memory — prepended to a fresh session. This is for lightweight, stateless personas dispatched per-task by something else.

Making it actually feel like a chat app, not a script

The part I’m proudest of isn’t the identity-file pattern itself — it’s what makes it feel like Hermes or OpenClaw rather than a folder of text files: a small wrapper script on my PATH, named after the agent’s handle, that cds into its folder and execs the CLI tool. Typing the agent’s name from any terminal launches (or headlessly messages) it directly. On top of that, I built two “reach it from your phone” layers — a Telegram bot wired through n8n for quick one-off messages, and a full remote-control setup (claude --remote-control) that gives the same familiar chat interface as a mobile app, for actual back-and-forth conversations rather than one-shot commands.

Design decisions that mattered more than they looked like they would

A few things I got wrong on the first pass, and had to fix deliberately:

• Naming consistency. Early on I let each agent’s handle get hand-picked (the-man, projectmanager — inconsistent hyphenation). That’s fine until something external — a phone automation tool, a webhook — needs to address agents by name programmatically; it ends up needing a per-agent lookup table just to get the name right. Settling on one uniform transform rule (lowercase, no separators) for every new agent means any caller can derive the right name with one deterministic step.
• Model inheritance. If the CLI tool has a global default model, an agent without its own explicit pin can silently inherit it — including an expensive default meant for interactive use, not unattended background runs. Every agent gets its model set explicitly now; nothing relies on inheritance.
• Redaction discipline. Cleaning up an accidentally-plaintext secret taught me that “preview with context, then redact” is fundamentally unsafe once a file’s confirmed to hold a real value — there’s always a formatting gap a regex won’t catch (bold markdown, backtick-quoting, an unexpected prefix). The fix was replacing by line number blind and verifying success by hash, never by re-reading the result. The opposite failure is just as real, though — a fuzzy “mask anything that looks risky” heuristic once redacted the literal word “Manager” out of “Password Manager agent” because it followed the word “password.” Only exact, already-confirmed matches get redacted now — never a guess.

What it demonstrates

This is systems design applied to something that doesn’t normally get designed carefully — most people either accept a framework’s defaults or hand-roll something ad hoc per agent. Treating “agent identity” as a reusable pattern (files-as-identity, a naming convention, a wrapper mechanism, a remote-access layer) rather than one-off setups per agent is the same instinct that matters in any codebase: build the abstraction once, reuse it, and fix the actual root cause (upstream discipline about how secrets get written) instead of re-running cleanup passes forever.

Part of the Homelab AI Blueprints series — see all nine blueprints for building and operating a self-hosted, AI-agent-run home server.