The Plan Fits The Life

Most fitness apps assume you'll change your life to fit the plan. The plan is the constant. You're the variable. The plan asks for forty-five minutes Tuesday, Thursday, and Saturday morning. Your life has a four-year-old, a 5:30pm family boundary, a basement gym, and a Saturday that's hard rest. The plan and the life don't speak to each other. The plan wins on Monday, the life wins by Thursday, and you're back to chaos by the weekend.

I spent the last month flipping that. The constraint file is the artifact. The plan is the byproduct. Whatever satisfies the constraints and still moves me toward the goal is the workout that ends up on my wrist. Most of what makes this work isn't software. It's having written the life down honestly enough that something else can reason over it.

Start with why the constraints aren't preferences. For me, training is regulation. It's how I metabolize the day. Work output, training output, the occasional Saturday wine. Same engine, three outlets. When training works, the rest of the system stays in tune. When it breaks, work bloats and other things start drifting in to fill the gap. The constraints are guardrails on a regulation system, not a wish list for a coach to honor. Whatever your system is, write down the version of this. The constraints come from why the system exists, not from what you want it to produce. Henrik Karlsson has a good essay on relaxing constraints in life design. Same primitive, different domain.

The architecture has two layers. Slow-moving state lives as plain markdown. Training principles, medications, household rules, protocols I've written for myself. Fast-moving state stays in the source-of-truth APIs and gets pulled on demand. Last night's HRV, this morning's sleep score, yesterday's effort. The model reads protocols from text and calls tools for facts. That separation is the whole design pattern. Without it you bloat the context with stale dashboards or starve the model of the rules that make its decisions sane.

I made the APIs queryable by writing MCP servers across Oura, Strava, Hevy, Intervals.icu, and Obsidian. That part is plumbing. Most off-the-shelf servers already exist for the obvious sources, and the work is mostly thin wrappers and writing your rules down. The interesting move isn't the servers. It's giving the model hands in your stack instead of a chat box. Geoffrey Litt called this kind of system malleable software back in 2023, before MCP gave it a typed surface to work with.

The reason I built any of this isn't theoretical. Late March I drifted. rMSSD trended down for three straight weeks, twenty-nine to twenty-three, and I kept adding sessions because I "felt fine." I caught it on a Sunday morning, manually, by reading the trend off the Oura dashboard. I deloaded the next week and the line came back up. The catching was luck. The whole point of the stack is that the catching shouldn't depend on whether I happen to look at the right dashboard on the right Sunday.

The same loop runs at smaller scope. Two days ago my body temp deviation jumped 0.34 degrees. Fever signature. The original week had a long easy run on the books for the next morning. The planner read the temp, saw the trend, and rewrote the day to a Push lifting session instead. Lifting doesn't tax the same system. Light zone-2 the day after. The week stayed intact, the body stayed out of the cardio hole, and I didn't have to make the decision while half-sick on a Friday night.

The weekly version runs every Sunday. I open Claude on the laptop. System prompt holds the constraints. Saturday is rest. Weeknights stop at 5:30pm. No double-cardio days. Hybrid block. Current focus is threshold and zone-2. I say "plan next week." The model pulls fourteen days of sleep and readiness, strength volume out of Hevy, intensity off Strava, protocols from Obsidian, and drafts the week. I argue with it in plain English. It revises. When the block is right, it writes the workouts into Intervals.icu, which syncs to my Apple Watch overnight. Monday morning the session is on my wrist before I've made coffee. The shape works for whatever you point it at.

You don't need all of this to start. The minimum viable version is one constraint file and one typed tool. Pick one rule you keep breaking and write it down clearly enough that something else could reason over it. Pick one data source you already have and wrap its API. That's the whole stack. Add tools when the planner can't decide without them. Add rules when you watch the planner make a decision your real life would have vetoed.

This is not optimization. The longevity-stack genre is built around maximizing outputs. PRs, biomarkers, body comp, lifespan. Useful frame for some people. Different frame from this one. A regulation stack is built around staying inside the band, not climbing the curve. The planner is a sparring partner, not an oracle. Some weeks I argue with it. Some weeks it catches drift I wouldn't have caught. Some weeks I'm sure it's wrong and do the session anyway, and a week later the data tells me which of us was right. The MCPs are not the coach. They're the surface area that makes the coach competent. The coach is the conversation, and the conversation is the practice.

A stack that gives a model read-write across your protocols and your APIs is a real surface to think about. Simon Willison has been writing about this shape for a year. Treat it like one. Scoped tokens, bounded write paths, no egress to anywhere you wouldn't paste your own data into.

The same architecture runs my product work. Different domain, identical pattern. Typed tool surface over every system that holds state, plain text for the slow-moving rules, model in the loop with hands instead of opinions, human as editor. The artifact is the decision in product work for the same reason the constraint file is the decision in training. Both surface a position you can argue with instead of a slide you can nod at. The hands that plan a deload week are the same hands that triage a roadmap. That's what range looks like when AI is in the stack. One operating model that crosses domains because the primitives don't care what you point them at.

Stop designing the plan. Start designing the constraints. Write them down clearly enough that something else, model or human, can reason over them. Most of the value of this stack is in that one move, before any code. The basement gym is a constraint. The 5:30pm boundary is a constraint. The medications you're on, the HRV you run, the volume you can recover from. All constraints. The plan is whatever satisfies them and still moves you toward the goal. Most training systems fail because they treat the life as noise. The life is the signal. The plan is what's left after you've written the life down honestly.