PulsePM: an AI project manager built into the workspace

PulsePM is a project workspace for tasks, sprints, timelines and risks, with an AI project manager built into it. I am co-founding it and I own the AI layer end to end.

Project tools are good at storing what someone typed and bad at noticing what nobody typed. The status report gets written by hand on a Friday, a task that is slipping gets noticed once it is already late, and the risk everybody half knew about was never written down anywhere. Most of the work of keeping a plan honest is reading, comparing and noticing, and that is work a model can do continuously instead of a person doing it badly once a week. The line we hold is that the AI does the admin and the human stays in charge.

Photograph a whiteboard and get a full plan back. That is the fastest demonstration I know of what an AI native tool is for: the planning that already happens on a wall stops being a photo in somebody's camera roll and becomes something the rest of the system can act on. After that it flags what is slipping each morning, catches scope creep early, and writes the status report from the real work rather than from what someone remembered to type.

That is the part I own: the planning agents, the retrieval that grounds them in the workspace instead of in the model's imagination, the structured outputs that turn an answer into something the product can act on, and the evaluation set that tells us when a change has quietly made things worse. Structured output is the unglamorous half and the half that decides whether a feature ships. A model that writes a pleasant paragraph about your sprint is a demo. A model that returns a task list with owners and dates that survive validation is a feature.

PulsePM exposes its workspace through a Model Context Protocol server, so any MCP client can ask about delivery directly: a workspace overview with counts of open tasks, overdue tasks, active sprints and open risks; projects with search and status filters; tasks; and per project sprints, milestones, risks, decisions and statuses, plus workspace members. You ask the question wherever you already work and it is answered from the live workspace rather than from a pasted export.

Two decisions in it are worth naming. The tools are read only, because an agent that can quietly reassign your sprint is a worse product than one that can only tell you the truth about it. And they are shaped around the questions people actually ask, "what is overdue", "what are the open risks on this project", rather than mirroring the database tables, because a tool surface that mirrors tables makes the model do the joins, and joins across a schema it cannot see are exactly where models go wrong.

Owning an AI layer inside a real product rather than a demo: agents that have to be right often enough to be trusted, outputs that have to validate before anything downstream touches them, evals that decide whether a change ships, and an integration surface designed so that the worst case is an unhelpful answer rather than a damaged plan.