How the AI PM OS Spins Up My Entire Workday

TL;DR

The AI PM OS starts with one shell command, opens a planning workspace, writes a launch plan, derives a lightweight state view, and then spins up the right workstreams in parallel. The trick is that every workspace resumes from its own CONTEXT.md, so the system can survive crashes, restarts, and long gaps without losing the thread.

Context

Most AI workflows still assume a single chat window. That breaks down fast when your day includes planning, meetings, follow-ups, writing, research, and a few half-finished threads that all matter for different reasons.

I wanted a system that could answer a more practical question: what should be open right now, and how does each thread pick up from where it left off?

The startup command

Everything begins with one command typed into Amp:

$ start-day

In the public ai-pm-os repo, the start-day launcher validates prerequisites, boots or reuses cmux, opens the Chief of Staff workspace, waits for system/today-plan.json, derives system/state/queue.json and system/state/now.json, then opens the selected workstreams.

Step 1: the Chief of Staff plans the day

The first workspace is the planner, not the executor.

The Chief of Staff agent reads recent notes, routine context files, workstream context files, and per-workstream metadata. Then it writes system/today-plan.json with the workstreams to open, the ones to skip, and a startup prompt for each selected thread.

Step 2: derive a quick state view

The public repo adds a small state-derivation step after the plan is written. system/scripts/build-state-from-plan.py reads today-plan.json and produces two files:

• queue.json: the ranked list of recommended workstreams
• now.json: the top recommendation plus a few fallbacks

That layer is intentionally lightweight. Internally I use a richer command-center model, but for the public repo I wanted something people could inspect instantly without inheriting extra machinery.

Step 3: open workstreams in parallel

Once the plan exists, start-day opens one cmux workspace per selected workstream. Each workspace gets a startup prompt that points it back to its own folder and current objective, so it is not starting from a blank slate.

In practice, that state usually lives in two files: workstreams/<slug>/CONTEXT.md and workstreams/<slug>/config.yaml. The config file gives the launcher metadata. The context file gives the agent continuity.

Step 4: let the files hold memory

This is the part that makes the whole system feel reliable. If the terminal dies, nothing important is lost.

When the workspace opens again later, the agent reads CONTEXT.md and can answer what changed, what is blocked, what decision is pending, and what should happen next. That turns the terminal into a temporary surface rather than the only place where state exists.

Workstreams versus routines

Not everything in the system is a project. Some folders are durable loops like to-do review, comms triage, meeting prep, and scheduled maintenance. Those live as routines/, not workstreams/. They use the same continuity model, but represent a different kind of job.

Why this feels better than tab chaos

A normal workday usually becomes accidental multitasking. Too many tabs, too many half-started notes, too many threads mixed into one place.

The AI PM OS works better because it makes the structure explicit: one planner, multiple focused executors, durable state per thread, and a ranking of what matters now.

What I learned

A launcher script can carry a lot of product value. The shell glue is not glamorous, but it is what turns a pile of prompts into a reusable experience.

Derived state is worth it when it improves inspectability. queue.json and now.json are simple, but they make the system easier to reason about.

Resume quality matters more than startup polish. A beautiful launch flow is not enough if the second session is confusing.

The public version got better when I simplified it. The exported repo became more useful once I resisted the urge to ship every internal layer.

Related: I Built an AI PM OS and Why the AI PM OS Feels More Powerful Than a Chatbot.