Every morning, Rutger de Knijf gets a briefing from his AI assistant. It takes 30 to 120 seconds and covers urgent items, today's schedule, anomalies in his health metrics, home system status, and suggested actions. Then he gets to work.
The assistant is called Muninn - one of Odin's ravens - and de Knijf built it himself using Claude Code, plain markdown files, and MCP (Model Context Protocol) servers. MCP servers are connectors that let Claude read from and write to external services - email, calendar, smart home devices, whatever you connect.
The architecture is deliberately plain: no custom database, no proprietary framework, no cloud service subscription beyond what Claude already needs. The whole thing runs on text files in a folder.
What Muninn Actually Does
The system covers more than a dozen domains: email, calendar, tasks, Garmin health data, home automation via Home Assistant, EV charging status, cooking planning, and trip logistics. Each domain has a "playbook" - a markdown file describing what the agent should do and how. De Knijf dictates what he needs by voice, and Claude drafts the playbooks itself.
Memory runs through topic-organized files: people.md, decisions.md, projects.md. The agent searches these using keyword matching rather than vector embeddings - the AI technique where text is converted to numbers to find conceptually similar content. De Knijf chose the simpler approach because his documents are small, his vocabulary is controlled, and exact matches matter more than fuzzy ones.
One smart design detail: the agent distinguishes between facts (stored in memory), to-dos (Todoist tasks), and resolved items (logged to prevent the assistant from raising them again). That third category - resolved items - is what prevents the nagging assistant problem. Most AI workflows don't address this.
The Rules That Make It Work
Muninn follows a "bias toward action" principle: it executes directly without asking permission, except for anything that reaches outside the system. Sending an email or creating a calendar event requires explicit confirmation. Internal operations run without asking.
De Knijf calls this "fast on the inside, careful on the outside." The system also runs only when he's actively at the keyboard - no background processes, no scheduled jobs. That's a deliberate security decision.
The productivity shift he describes is hard to dismiss: what previously took a week now fits into a day. The main ongoing challenge is getting Claude to actually consult its memory files before acting, which he describes as "harder than you'd expect."
For anyone who wants to build something similar, de Knijf recommends starting with a single domain playbook, then adding memory, briefings, and sub-agents only as each piece proves useful. Prerequisites include a flat-rate token plan, configured MCP servers for each external service, and patience to iterate on the instructions.