botler-agent: A Minimalist Personal Data Agent That Runs on an Old Mac
General-purpose Agent frameworks are heavy, expensive on tokens, and often too permissive for a long-running personal daemon. botler-agent shows that a five-tool, allowlist-only design can handle daily record-keeping and reminders at a fraction of the cost, on low-end hardware, without exposing the rest of the filesystem.
botler-agent strips the Agent down to a single tsx process that installs in seconds and runs comfortably on older hardware. It receives messages from chat platforms, routes each one to the correct data sub-project using a tiny routing prompt, then loads only that project's AGENTS.md to guide execution. The framework enforces a strict directory allowlist and gives the Agent exactly five tools — read, write, edit, run (existing scripts only), and schedule — with no arbitrary shell access. Every write is validated as legal JSON, and any change triggers an automatic git commit for backup.
Business logic lives entirely in per-project AGENTS.md files. Adding a new data domain means creating a directory and writing its rules; the framework source stays untouched. The author runs six projects covering vehicle maintenance, diet, daily logs, bookkeeping, English learning, and travel — all vertical personal data that chat-based input turns into structured, version-controlled records.
Token costs are kept low because each message spawns a fresh, stateless Agent. The routing phase uses only project names and summaries; the full AGENTS.md is concatenated only for the selected project. When routing is uncertain, the system asks the user to clarify rather than guessing. Scheduled reminders, a local WebUI, and health monitoring round out the optional modules, and all configuration lives external to the data directory so secrets never leak into version-controlled data.
The design treats the Agent as an untrusted process: even if it hallucinates, the blast radius is limited to JSON files inside allowlisted directories. This is a practical threat model for a daemon that accepts external messages.
Separating routing from execution and loading only one project's AGENTS.md per task is an underused pattern that directly cuts token waste in multi-project setups.
Refusing to guess when routing is ambiguous — and instead asking the user — avoids silent data corruption, which is a higher-stakes failure in personal record-keeping than in conversational chat.
The framework's insistence on structured JSON output and git commits turns ephemeral chat messages into a versioned, queryable dataset, sidestepping the long-term maintenance problem of cloud chatbot logs.
Only five tools, run doesn't go through a shell, parameters are passed directly, 60-second timeout — this minimal-permission design is spot on. An Agent that runs long-term and accepts external entry points should be built exactly like this. Using AGENTS.md for business decoupling is also clever; adding a business means adding a directory and writing a doc, without changing a single line of the framework. We've been exploring similar lightweight personal Agent approaches lately and have seen quite a few similar cases on ai345. This article really nails the permission design aspect.
Thanks for your reply, but this sounds way too much like an AI-generated response [picking nose]