Personal Flywheel

Chapter 1 — The Problem: You Know Your Projects. You Don't Know the Edges.

By mid-2026 my machine held a dozen active projects: design work, a portfolio site, plugins, agent experiments, writing. I knew each one intimately. What I didn't know was what they meant together — which project secretly fed another, which finished work deserved to be published, which two half-ideas were the same idea.

Every productivity tool I tried organized the endpoints: better lists of projects I already knew. None of them worked on the edges — the relationships. And the edges are where the value lives: no summary of my portfolio project tells me "the search-engine design work you did last quarter belongs in here." That's a connection, and connections are exactly what you stop seeing when you're inside the work.

So the product principle came first, and it's strict: Personal Flywheel only reveals connections. It never recites what you already know. If an explanation spends a sentence introducing a project to its own owner, that sentence gets cut.

Chapter 2 — The Core Design Problem: When Should an AI Assert, and When Should It Ask?

The obvious build was "LLM looks at your projects and tells you insights." The obvious build is also worthless — because an LLM will happily narrate a plausible connection whether or not the evidence supports it. Confident storytelling about weak signals is worse than silence: it burns trust, and trust is the entire product.

So the heart of Personal Flywheel is a judgment model — the design decision everything else hangs on:

Three signals, in strict order, none allowed to override the previous:

1. Relationship type sets the ceiling. A structurally weak kind of connection ("these two projects share a goal") can never score high, no matter how much evidence piles up. Category caps confidence.
2. Evidence decides: assert or ask. A strong connection type with thin evidence doesn't get narrated — it gets asked: the app surfaces it as a question ("these look related — are they?"), and only a human confirmation promotes it. The AI is designed to know the difference between "I found something" and "I suspect something."
3. The model's self-score only ranks. An LLM rating its own insight can sort the list; it can never promote a weak edge to a strong one. Self-evaluation is useful and untrustworthy at the same time — the system treats it accordingly.

Every discovered connection lands in one of five presentation tiers — from deep (fully explained: where they join, what it means, what to do next) through ask (surfaced as a question) down to suppressed (weak type, no evidence: not shown, not stored). Structural facts like "project A contains project B" get a special tier: never headlined — you already know them — but always recorded, because they're the skeleton that lets the system derive two-hop insights ("A is part of B; B belongs in the portfolio; so A might too") — which, having no direct evidence of their own, arrive as questions. The logic composes.

This is, I think, what "designing AI behavior" actually means. Not prompt-writing — deciding, structurally, when a system is allowed to speak with confidence.

Chapter 3 — Only Judge, Never Touch: The Delegation Layer

The second principle: the flywheel is thin. It judges, explains, and dispatches — it never edits your projects. Execution belongs to the coding agents already on your machine (Claude Code, Codex), which it treats the way a good lead treats a team:

• Confirmation-first. Suggested next steps go to an inbox; nothing runs without a yes.
• Capability routing. Tasks route to agents by what they can actually do — probed live, not assumed from their names.
• Graded autonomy. An LLM difficulty-grader (fail-closed) decides whether a task runs headless in the background or launches a visible session you can steer. Simple and safe → silent; ambiguous → you watch.
• Chat and dashboard are one state. Correct it in conversation — "that's not my portfolio, this is" — and the flywheel re-judges everything; the board updates itself. The chat agent can't touch state directly either: it proposes declarative actions, and code executes only a whitelist. Even my own agent goes through permission design.

And because my work genuinely spans machines, the state does too: one machine is the brain (single database, single truth), others are stateless edges. Only filtered digests travel between machines — raw project content stays where it lives, and the digest layer is deliberately the privacy knob. Task routing respects geography: a task on machine B can only be claimed by agents on machine B, enforced with per-device tokens. Multi-machine trust turned out to be a design problem wearing an infrastructure costume.

Chapter 4 — Product Discipline

I've watched enough AI side-projects die of excitement to set rules before writing code:

• Every idea goes to the roadmap first — ordered against everything else, never straight into the build. A good idea is not the same as a good idea now.
• No heavy infrastructure before the core value is proven. Delegation and multi-machine came only after the insight engine earned them.
• Taste is written down. The project carries its own rubric — UI rules and scope rules I check against before touching the interface, so "it looked good at 2 AM" never ships.
• Every slice lands with regression tests — ~800 by now. For a solo AI-assisted project this isn't bureaucracy; it's what lets me hand work to agents and trust the result.

The interface follows the same restraint the engine does: a quiet, near-white surface, one blush accent, serif display type — a calm reading environment for the one moment that matters, "here's a connection you didn't see." No gamification, no feed, no dashboard theater.

Chapter 5 — What It Proves

Personal Flywheel is where everything I care about converges in one artifact:

• A designed judgment model — the assert/ask boundary, evidence tiers, composable structural reasoning
• Trust architecture — whitelisted actions, confirmation-first delegation, per-machine boundaries
• Real product engineering — signed DMG, launchd daemon, onboarding, a full regression suite, multi-device install verification
• A working method — built end-to-end with AI agents, using the same AI design workflow it now participates in

And one loop I enjoy: this product's canonical example — the insight it was designed to find — was "your design-system work belongs in your portfolio." You're reading its portfolio entry now. The flywheel found its own way in.