Give AI Agents a Project Manager—But Don't Let It Make the Call Yet

Robert Scoble put it bluntly in a tweet: over the past two years, everyone has been busy making coding agents faster; nobody has made them listen to one another. A plan changes in a meeting, but the coding agent keeps building last week's version, and the QA agent does the same. You pay twice for that rework. Human teams solve synchronization through project managers, but once you switch to a group of agents, you assume they will align automatically.

Jake Kim pitched a product for this gap, Serro, positioned as an Agentic TPM. A TPM is a technical project manager who manages cross-team progress, dependencies, risks, and synchronization, without making technical decisions for the team. What Serro wants to do is sit above a bunch of agents, watch program status, detect drift, and when the plan changes, first check with the owner for confirmation, then update the relevant agents.

Jake Kim said in a reply: smarter models can't fix this problem. You can feed information to agents automatically, but you can't automatically maintain the state behind the agents. A better agent is still a node guessing at a plan that exists in someone's head and in three other tools. Serro's approach is to keep live memory of each program, reconstruct state from Slack, Linear, GitHub, Jira, Zoom, Notion, email, and code repositories, and catch drift when it happens. When the plan changes, it confirms with the owner and then notifies all relevant agents at once.

There is an easily overlooked word here: confirm. Serro officially says it coordinates but does not decide; control stays with humans. In the comments, someone asks more specifically: when Slack, the roadmap, and the code each have a version, how do you know which is current? The material doesn't give a complete answer, only that it will check with the owner. This step is key to whether the product succeeds. A coordinator can organize status, route updates, and chase stalled work, but once it starts changing priorities for people, it becomes another agent creating drift.

A commenter shared their permission design: the coordinator only tracks, routes, and chases stalled work; it never starts work. Work can only be triggered by a human or by an already approved task. Coding agents can make suggestions to the coordinator, but cannot assign it work. This boundary is more valuable as a reference than a feature list. What agent teams really lack is a clear rule: who can change the plan, and after it changes, who is responsible for writing the new state into every agent's context.

Serro gave one case. A 300-person engineering organization connected Serro into a single workflow, found 112 duplicate reports and automated them, saving about 5,000 hours a year. These are the vendor's numbers with no independent verification. At least it shows where the pain is: a lot of time goes into repeated synchronization and rebuilding context, not writing code. The product entry point is serro.ai.

Robert Scoble ends by asking what coordination agents should own, and which decisions they should never touch. One answer in the comments is very practical: let it chase updates, don't let it schedule meetings. In today's agent teams, the question can be more specific: after a meeting ends, who is responsible for telling the QA agent that the plan has changed? For many teams, the answer may still be the most senior engineer.