Why I'm building moitumi

A new repo is unreasonable optimism, especially this one. It’s called moitumi — a personal cognitive assistant. That phrase has been used to mean six different things over the last decade, so let me say what I actually mean by it.

The frustration that started it

Have you ever asked Siri what your priorities are this week?

I have. It’s a comedy bit. Ten years of behavioral data and the thing still can’t reliably tell my morning meeting from my afternoon one. Google Assistant is no better. Alexa is worse. Effectively, every assistant I’ve ever used runs the same loop — I speak, the system makes a guess, and somewhere completely out of my reach, a model gets a little more confident about who I am and what I want.

After a decade of this:

  • I cannot see what the system learned about me.
  • I cannot edit, correct, or delete its inferences.
  • I cannot ask “what are my current priorities” and get a meaningful answer.
  • When it gets me wrong, there is no recourse — no node to edit, no edge to remove.

And the kicker — the thing that finally tipped me over — is that the learned model is optimized for the platform’s engagement, not my goals. Ten years of my data and it’s still not really mine.

To be honest, the deeper problem isn’t even the quality of inference. It’s the contract. You don’t get to author the model; the model gets to author you. And there’s no real opt-out, short of not using one. I tried that. Didn’t work either.

What I actually want

So here’s what I actually want. A presence that knows me — not in the creepy surveillance way, in the way a long-time friend knows you. Not because they trained on your behavior, but because you told them who you are and what matters, and they remembered.

Concretely:

  • Thought continuity. When I switch projects mid-thought, I want my mental state captured automatically. Come back later, get put back where I was.
  • Live agent visibility. Multiple LLM agents running across different projects, all visible at once — what each is doing, which are blocked, which need my input. Right now this is a tmux mess.
  • Work-scoped presence. At the office (SSH into a Linux dev box), I want it to know about my work, my tools, my context — and have zero reach into my personal data. A physical boundary, not a behavioral one.
  • Life review at any horizon. “How was today? This month? This year? The big decisions I’m carrying?” Coherent answers across all the domains of my life, not just whichever app happened to store the data.
  • Background presence. Notices things without being asked. Surfaces them at the right moment, never as an interruption. Needless to say, this is the hardest one.

The mental model I keep returning to: a presence that knows you, sees the full picture, responds when you speak, shows you what’s happening, and acts on your behalf through agents.

The “explicit graph” bet

OK, but how?

The architectural bet that makes the contract different is one sentence: the substrate is a graph that I author. Not weights that the system learned.

Two entities. Everything else is metadata.

graph LR
    A[Node] -- "directional edge<br/>(named relationship)" --> B[Node]
    A -.has metadata.-> M1[(metadata)]
    B -.has metadata.-> M2[(metadata)]

    style A fill:#e1f5ff,stroke:#0366d6
    style B fill:#e1f5ff,stroke:#0366d6
  • A node is anything that matters: a thought, a person, a project, a journal entry, an LLM agent, the Self Model, a conversation, a piece of health data, a reminder.
  • An edge is a directional, named relationship — parent, mentions, depends_on, anything.

That’s it. The graph is the source of truth. Claude reads it; it doesn’t train on it. Anything an ML model “discovers” — embedding similarities, behavioral patterns, whatever — has to materialize as an explicit edge I confirm. No silent inference.

Compared to the implicit model:

Implicit (Siri/Google)Explicit (moitumi)
Who authors the model?The system, from your behaviorYou, by writing nodes
Can you inspect it?NoYes
Can you edit it?NoYes
Optimized for?Platform engagementYour goals
When it’s wrong?Try again, hope it learnsEdit the node

That being said — the cost is real. I now have to maintain a graph. Which sounds awful when you say it out loud. But here’s the deal: when the system gets me wrong, the recourse is deterministic. Open the offending node, change it, save. No prompt-tuning rituals. No “hope it learns this time.” That asymmetry is worth a lot of busywork to me.

What the assistant looks like

Three surfaces, one core.

graph TB
    subgraph Core["moitumi core (single daemon)"]
        G[Cortex — the graph]
        SM[Self Model]
        A[Agents]
        G -.- SM
        G -.- A
    end

    subgraph Surfaces
        TUI[TUI<br/>tmux + Claude Code]
        Mac[macOS<br/>SwiftUI + Metal]
        Phone[iOS<br/>SwiftUI]
    end

    Core --- TUI
    Core --- Mac
    Core --- Phone

    style Core fill:#fff4e6,stroke:#d97706
    style G fill:#e1f5ff,stroke:#0366d6
  • The TUI is where I work — tmux, Claude Code, navigator sidebar, full keyboard.
  • The macOS surface is the visual, ambient view — a spatial visualization of the graph, agents as figures moving between buildings. (Yes, literally. More on this later.)
  • The iPhone surface is for capture and check-ins — speak a thought, ask a question, see what the agents are doing.

The product is not any one surface. The product is the continuous presence behind them. Effectively, the surfaces are windows; the daemon is the thing.

Why now, why C++

A quick pragmatic note. The core is C++26 — with Swift only where Apple platform APIs demand it (Metal, HealthKit, AVFoundation). Two reasons:

  1. Latency. This thing runs all day, every day. Memory and startup cost matter. C++ keeps both small.
  2. The agent loop is simple. “Gather context → call the LLM provider → validate → apply to the graph.” That’s the whole loop. Every agent framework I’ve surveyed is Python, and the abstractions they impose are heavier than the problem I’m solving. A custom loop is a few hundred lines. Why pay the dependency tax for that?

Maybe I am biased — I do like writing C++. That being said, I’d defend both choices on the merits. More on each in later posts.

For now, the repo exists. The first commit is in. The next post is about the hexagonal architecture going in before any feature does.

What this blog is

A journal. Written for me, and for anyone curious about what it actually takes to build a personal AI from first principles. The DEVLOG in the repo is the raw, append-only record — that’s where the actual decisions get made. These posts are the curated layer: the whys, the why-nots, and the course-corrections.

Overall… welcome to the open notebook. Hope it’s useful.

Source pointers

  • DEVLOG.md — entry of 2026-03-14
  • PLAN.md — product vision section, ADR-001 (language), ADR-003 (domain model)

Cross-posted from the moitumi dev blog.