Singapore's Foreign Minister Built a Self-Hosted AI That Gets Smarter Over Time

The Problem Every AI Chatbot Has (and Most People Accept)

Standard LLM assistants are stateless. Close the tab and they forget everything. The conversation you had last Tuesday — the context, the preferences, the decisions made — is gone. The conventional fix is RAG: retrieve chunks of raw text from a document store and inject them as context. It works, but it's retrieval, not knowledge. You get fragments of old text, not synthesised understanding.

NanoClaw solves this differently. Instead of retrieving text chunks, it extracts discrete facts and insights from raw sources — speeches, articles, conversations — and stores them as graph nodes in a structured knowledge base called mnemon. On every conversation, a semantic query runs against that graph and surfaces relevant entries automatically. The agent never has to decide to “look something up.” Relevant knowledge arrives as context before it responds.

The result is an assistant that gets more useful the longer it's used — compounding knowledge, not perpetual amnesia.

How the Architecture Actually Works

NanoClaw has three layers, each with a distinct job:

• Raw sources — speech transcripts, saved articles, web clips. Archival. Never modified after ingest.
• mnemon knowledge graph — a SQLite-backed graph where each entry has content, category, importance score, tags, and edges to related entries. Queried via local vector embeddings (Ollama + nomic-embed-text running on the Pi itself — no cloud calls).
• Wiki pages — compiled markdown files that synthesise mnemon facts into human-readable narratives, organised into entities, concepts, and timelines. Browsable in Obsidian on macOS and iOS.

The pipeline flows in both directions. New documents are ingested and extracted into mnemon. mnemon facts are compiled into wiki pages. Wiki pages can be reviewed, corrected, and fed back. The knowledge base improves continuously.

Voice notes are transcribed on-device via whisper.cpp. Images are resized and passed as multimodal content to Claude. Each registered group chat (WhatsApp, Telegram, Slack, Discord) runs in an isolated Docker container with its own filesystem, its own local mnemon store, and its own Claude session. Groups cannot read each other's memory or messages.

Why It All Runs Locally

The choice to run embeddings and transcription on the Raspberry Pi rather than a cloud API is not a cost optimisation. It's a deliberate privacy architecture.

The knowledge base contains personal and policy-sensitive content. Running nomic-embed-text locally means no document content leaves the network. Running whisper.cpp locally means voice notes never touch an external server. The 274MB embedding model and the base Whisper model both run fast enough on the Pi 5 for practical daily use.

For organisations handling sensitive data — legal, healthcare, finance, government — this architecture matters. The question isn't just “can we use AI?” but “where does the data go?” NanoClaw answers that question with a clear boundary: it stays on your hardware.

The Security Design Is Worth Reading Carefully

NanoClaw's security model is unusually rigorous for an open-source personal project:

• Containers never see raw API keys. An HTTP proxy (OneCLI) intercepts container HTTPS traffic and injects credentials at request time. The agent code itself cannot exfiltrate secrets.
• Sender allowlists control who can trigger the agent — non-allowed senders' messages can be stored for context but cannot invoke the LLM.
• Mount allowlists stored outside the project root block containers from accessing sensitive host directories (.ssh, .aws, *.pem, and so on).
• Per-group IPC namespacing — each group can only send messages to its own conversation identity. Source identity is verified by directory path, not message content.

This is the kind of defence-in-depth that enterprise security teams ask for and rarely see implemented cleanly in AI projects. The fact that it appears in a personal productivity tool is a signal of how seriously the author thinks about operational risk.

Three Design Decisions That Stand Out

Beyond the architecture, three specific choices in NanoClaw are worth studying:

One Docker container per group, not one process. Isolation is the goal. A runaway agent in one group cannot affect others. Container lifetime is tied to conversation activity — they shut down after idle timeout, keeping resource usage minimal. This is the same principle that makes microservices resilient applied directly to AI agent management.

A pre-check script before every scheduled task. Each agent invocation uses API credits. For tasks like “check if there are new PRs” or “did anything change?”, a bash script answers the question without waking the LLM. The agent only runs when the script signals wakeAgent: true. This is simple and effective cost management that most AI implementations skip entirely.

iCloud + rsync for Obsidian sync, not git. iOS git clients have unreliable auth in practice. iCloud is zero-config and native to iOS. rsync is directional and battle-tested. A Mac Mini on the same LAN acts as the bridge. It is a deliberately pragmatic choice over an architecturally pure one — the kind of decision that separates systems that get used from systems that get abandoned.

What Growing Businesses Should Take From This

NanoClaw is a personal productivity system, not a commercial product. But the problems it solves are not personal problems — they're organisational ones.

Every business accumulates knowledge: customer conversations, meeting notes, research, decisions made and why. That knowledge currently lives in email threads, Notion pages, and people's heads. It doesn't compound. It decays. New team members can't access it. The AI tools most businesses deploy today are stateless — they're helpful in a session and useless the next morning.

The architecture NanoClaw demonstrates — extract facts from raw sources, store them as structured retrievable knowledge, surface them automatically at the moment of relevance — is the direction enterprise AI is moving. The question for businesses is not whether to build a knowledge graph on a Raspberry Pi. The question is whether your current AI setup is building institutional knowledge or burning it.

One more thing worth noting: this project is actively running in daily use, processing messages, running scheduled briefings, and ingesting articles. It is not a prototype. It is a system maintained by a senior government official with a demanding schedule. If it can meet that bar, the underlying architecture is more production-ready than most businesses give it credit for.

NanoClaw is open source at github.com/qwibitai/nanoclaw.