Ask a PM about their metrics and they list outcomes: activation, retention, expansion, NPS. Good answers, but they miss the meta-answer. The number that predicts all of those is cycle time: how long a piece of work takes to travel through the seven stages of the PM Operating System, from a signal landing in Sense to a measured outcome broadcast in Amplify. At most companies that cycle is still measured in quarters. On the teams I watch closely it now runs in weeks. The Signal-to-Ship agent measures that cycle end to end so you know whether the transformation is real or performative.
The seven stages
A real product change moves through Sense (a signal becomes visible), Discover (researched into a written hypothesis), Decide (prioritized and committed to a sprint with a target outcome), Build (production code merged and instrumented), Ship (rolled out to 100 percent of the eligible segment with the launch checklist done), Measure (a signed impact reading attached, win, loss, or null), and Amplify (the learning shared in a retro or broadcast). Most teams are not instrumented for all seven. The agent stamps each active item with its current stage, its time-in-stage, and its total cycle time so far.
Why it is the meta-agent
Other agents watch one stage each. This one watches items move across all seven, wired into the outputs of the other agents rather than raw data. That matters because the bottleneck is almost never where you think. Engineering says sales is slow to commit, sales says product is slow to prioritize, product says engineering is slow to build. Everyone is partly right and fully convinced. The agent cuts the argument off: in the last 90 days, median Sense was 1.8 days, Discover 3.9, Decide 2.2, Build 11, Ship 6, Measure 14, Amplify 21. The bottleneck is Amplify, not engineering. Lessons are being hoarded instead of broadcast, so the next cycle repeats mistakes the last one already solved. That is actionable. An opinion wrapped in anecdote is not.
What it does and what it is not
Four jobs: stamp every in-flight item with its stage, compute median and P90 cycle times per stage and overall, detect the bottleneck stage relative to your own history and targets, and flag stuck items (anything past its P90 for a stage) with a one-line diagnosis. Output is a daily Slack snapshot and a Monday trend digest. The one piece needing human upkeep is a project_map.yaml identity map that links a project's IDs across Jira, LaunchDarkly, Salesforce, and the rest, about ten to twenty minutes a week. It is not a productivity dashboard ranking PMs, not a substitute for talking to the team, and not a forecasting tool. Cycle time is a team number and a system property.
Do not instrument all seven stages at once. Pick five active items, hand-stamp each with its current stage and entry date, stamp them again next Monday, and post the table in Slack. Automate the Jira side in week 3, add the stuck-item detector in week 4, then add one data source per week. A month out you have a running version, and every Monday you see the bottleneck and fix the top one, compounding.