跪拜 Guibai
← All articles
GitHub · AI Programming

botler-agent: A Minimalist Personal Data Agent That Runs on an Old Mac

By crossoverJie ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

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.

Summary

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.

Takeaways
The framework installs as a single tsx process and targets lightweight personal data tasks, not general automation or software engineering.
Only five tools are exposed: read, write, edit, run (pre-existing .py/.js scripts only, 60s timeout), and schedule (writes to a fixed schedules.json). No shell, no browser.
A path allowlist restricts all file operations to first-level subdirectories under DATA_ROOT, with realpath checks to block traversal and symlink escapes.
Business rules are defined per sub-project in AGENTS.md; adding a new data domain requires no framework code changes.
Each incoming message creates a stateless Agent. Routing uses a minimal prompt; only the matched project's AGENTS.md is loaded for execution, keeping token usage low.
All writes are validated as legal JSON; failures trigger a self-healing retry. Any change is auto-committed to git.
Configuration files (system prompt, .env, provider settings) live outside DATA_ROOT in ~/.botler-agent/, keeping secrets separate from version-controlled data.
The author runs six personal data projects: vehicle maintenance, diet, daily logs, bookkeeping, English learning, and travel records.
Conclusions

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.

Concepts & terms
AGENTS.md
A per-project markdown file that defines the data schema, writing conventions, and business rules for that sub-project. The Agent reads it before any operation to understand what and how to record.
DATA_ROOT
The root directory containing all data sub-projects. The framework's path allowlist restricts all file operations to first-level subdirectories under this root.
Dispatcher + Runner architecture
A two-phase task pipeline: the Dispatcher deduplicates and serializes incoming messages, then the Runner routes the message to a sub-project and executes it using only that project's AGENTS.md.
From the discussion
Featured comments
咬代码的兽 1 likes

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.

crossoverJie

Thanks for your reply, but this sounds way too much like an AI-generated response [picking nose]

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗