PM Platform

Why I built the PM Platform

My AI-assisted product work had outgrown the chat window before I admitted it. I was running parallel threads with three or four different agents — one for research, one for spec writing, one for implementation, one for critique — and the actual bottleneck was never the agents. It was me, manually re-pasting context between tabs, losing track of which decision happened in which thread, and re-explaining the same product brief to a new provider every time I wanted a different kind of thinking.

That's the problem the PM Platform solves: not "better prompts," but a shared operating layer so several AI agents, across different providers, can work off the same live context without me acting as the copy-paste layer between them.

The product was never another AI chat interface. It was an operating environment for managing several AI collaborators as one coherent team — with me as the PM, not the router.

Starting from the friction, not the feature list

I didn't start by designing an agent-orchestration platform. I started by logging where my own workflow actually broke: I'd lose the reasoning behind a decision once I switched providers mid-task; I'd assign the same kind of work to whichever agent I happened to have open instead of the one actually suited to it; and parallel workstreams (research running while implementation was in progress) had no shared source of truth to reconcile against.

Those three failure modes became the spec: persistent shared context, deliberate task-to-agent routing, and a single place decisions and artifacts live regardless of which agent produced them. Everything else in the platform — the UI, the project/task model, the artifact log — exists to serve those three things, not the other way around.

Specializing agents by provider strength, not habit

Different providers are legitimately better at different parts of product work, and the platform is built around using that on purpose instead of by default. Implementation-heavy work (scaffolding, refactors, running and fixing code) routes to agents strong at long, tool-using execution loops. Synthesis and research — reading a large pile of competitor material, user feedback, or an existing codebase and coming back with a structured summary — routes to agents with the strongest long-context comprehension. Writing, structured reasoning, and product critique route to whichever agent has shown the sharpest judgment on that class of task in practice, which for me has often meant using one model to draft and a different one specifically to red-team the draft before it counts as done.

The point isn't model-shopping for its own sake. It's that the PM role in an AI-native workflow is increasingly about knowing which kind of intelligence a given piece of work actually needs, delegating it precisely, and holding the line on quality when an output looks confident but isn't right.

Building it in the loop of real product work

I didn't build this against a hypothetical use case — I built it against my own live projects, including this site. Early versions were too permissive: any agent could touch any part of the shared context, which sounded flexible but actually made the audit trail useless, because I couldn't tell which agent's reasoning led to which decision. I tightened that into role-scoped context: each agent sees the shared project state and its own assigned task, and writes back through a single decision log rather than mutating shared state directly.

That change came directly from friction, not from a design instinct — I only saw the problem because I was running real work through the platform daily and kept losing time reconstructing "wait, why did we decide that." Every feature that survived into the current version answered a specific instance of that kind of pain; anything that only made the system look more sophisticated got cut.

What it changed about how I operate

The platform lets me hold the product layer — priorities, tradeoffs, what's actually worth building — while delegating bounded, well-specified work to the agent best suited to it, in parallel, without losing the thread between them. Research can inform a spec, the spec can drive implementation, and implementation feedback can come back and revise the original decision, all inside one continuous context instead of four disconnected conversations.

The emerging skill here isn't prompting. It's systems design for a team where some of the teammates are AI: defining ownership, supplying the right context to the right agent, building in a review loop that catches confident-but-wrong output, and keeping final judgment centralized with the human PM. That's the operating model the PM Platform was built to make practical.