Rhythm & Routine

Why this exists

During a gap I was advancing job search, learning, sport, and several personal projects at once. The hard part was not “listing todos.” It was letting long-term goals pass through time constraints that change every day: something extra appears today, how does the original plan move; a task is not done, should it continue, reschedule, or split; after a week, how does the system correct the next step from real time invested, instead of repeating an idealized suggestion.

Most planning tools are good at storing tasks. Most AI assistants are good at generating a list that looks reasonable. Neither is good at maintaining state after a plan is formed. So I started building Rhythm & Routine: let an agent enter the full loop of “goal — plan — calendar — execution — review,” while leaving final control with the user.

View the GitHub repository

How I define this product

This is not an AI calendar, and not a chat TODO. Its core objects have clear jobs:

• Goal / Milestone / Task express what you want to reach, and what can be executed next.
• Routine expresses a rhythm that has to be kept repeating, and is not mixed with one-off tasks.
• ScheduleBlock connects tasks with real time, while still allowing meetings, commuting, and rest as personal holds.
• ExecutionRecord / RhythmFeedback record what actually happened, not only the plan or a check-mark count.
• Review re-projects daily and weekly facts into progress, drift, and next-step advice.

I wanted a user arriving on the home page not to have to assemble information across five modules. The Today page therefore shows calendar, completion progress, in-the-moment suggestion, rhythm findings, and this week’s track together, so the user can judge what to do next and also see the facts a suggestion rests on.

How an agent should join planning

The first implementation easily upgraded any schedule request into a full agent loop: load history, read goals, evaluate the whole day, then call several tools. The flow looked “smart,” but a simple request could still produce a long chain and high latency.

I moved the problem up from the prompt to routing and execution strategy: first judge whether this is a single fixed block, a bounded set of items, or an open all-day plan that needs historical personalization, then choose the matching Operation Profile. Only open planning loads Schedule Memory and a whole-day quality assessment; a clear single block takes the short path. The profile also defines which tools may be called; the runtime does not introduce capabilities the model currently has no right to use.

That design produced three product principles:

1. Fewer steps cannot sacrifice correctness. Conflict checks, permissions, idempotency, audit, and failure recovery must stay.
2. Plan changes must be confirmable. The agent first generates a ChangeSet draft; the user confirms before it is written.
3. Personalization must have evidence. Rhythm memory is formed only from completed blocks and actual time invested; explicit time and fixed commitments always win.

The hard part is not generation. It is correct state

A schedule looks like a start and end time. In practice it crosses time zones, reschedules, cancellations, repeating routines, history, and review stats. One reschedule cannot delete the original fact, but review also cannot count the old and new block twice; after an agent session refreshes, execution history needs to restore, but an old change draft cannot be submitted again.

Those problems made me trace “does the interface look right” back to a full data chain: UI display, service-layer projection, database history, and the agent contract have to agree on the same fact. It also pushed evaluation from “does the reply sound right” to router hit, tool choice, non-invocation, safety invariants, and context and tool-batch performance.

What I learned

1. An agent product is first a state machine and a control system

A prompt can only affect one generation. A reliable product also needs deterministic routing, capability limits, tool permissions, a confirmation barrier, idempotency, and recovery. The model owns semantic judgment; the system owns the facts and the write boundary.

2. Define personalization with real execution evidence

That a user once planned to study at night does not mean night is actually a good time to study. Schedule Memory has to distinguish planned, completed, cancelled, rescheduled, and actual time invested, and allow an explicit request to override a historical inference.

3. Put evaluation on a concrete failure layer

“The agent is not doing well” cannot guide iteration. Only when the problem is located in intent recognition, profile choice, context construction, tool calls, quality assessment, or the final write does the team know which layer to change — and avoid covering a structural issue by adding more prompt.

4. An AI product manager can push an everyday problem into engineering validation

This project kept me crossing the product–implementation boundary: from product objects and interaction rules, to database relations, time semantics, agent runtime, eval cases, and browser verification. I am not proving “I can write a calendar.” I am validating how AI can reliably join decisions in a complex, long-term, changing personal scene.

What it proves

Rhythm & Routine shows how I handle AI product complexity: define the problem from a real scene, split open-ended intelligence into deterministic state, permissions, and evals, then find the boundary through continued use and push the next iteration.

Scope note: Independent project, still being built. Features on the page follow the current local version. Test numbers correspond to a recorded validation on 2026-07-31 and do not mean every later uncommitted change has already been accepted.