Background
Running a household means constantly tracking small things: dentist appointments, HVAC filters, school deadlines, calls that slip. My wife and I were managing all of it across text messages and memory.
I wanted a single shared system both of us could talk to in plain language, without installing anything new. Telegram was already on both our phones.
What it does
The assistant runs across three Telegram chats simultaneously — my personal chat, my wife's, and a shared family group. All three read and write to the same task inventory. Either of us can add, check, or complete a task and the other sees it instantly.
It handles tasks with categories and priorities, fires reminders at the right time, looks up phone numbers and business hours on demand, and sends a morning briefing at 8am summarizing tasks in an Eisenhower matrix, because that's how my family thinks.
How it's built
The core is a Node.js/TypeScript process handling Telegram polling, a SQLite database for shared state, a cron-based scheduler, and an IPC file-watching loop. It's built on NanoClaw, a minimalist AI agent orchestration framework.
When a message comes in, it routes to an isolated Docker container running a Claude agent. Each family member's chat gets its own container with its own filesystem and session context. The agent communicates back to the host exclusively through IPC files; it cannot touch the database or network stack directly. The host validates intent and applies changes with authorization checks.
Agent capabilities are exposed as MCP tools, a typed interface between the agent and the host. Adding a new capability means adding a tool definition and a handler; the agent picks it up automatically on the next container start.
The two-tier scheduling decision
Not every scheduled job needs a full agent. Lightweight reminders write a row to a schedules table and fire a direct Telegram message at the right time, no container, near-zero cost. Complex recurring jobs like the morning briefing spin up a full agent container that queries the database, reasons over the results, and composes a response. The distinction keeps resource usage and latency where they should be.
What I took from it
This is a production system my family has been using since March 2026.
Most decisions came back to one constraint: the agent should be useful, but the host should always be in control.