Every team reported green. The work said ten days late.

1. Status meeting

   Everyone reports green

   Each team reports on its own work, and its own work does look fine. No one is asked about the hand-offs between teams.

2. Week 2

   The blocker is in a comment

   "Waiting on legal review of the card vault contract." "We’ll pick this up after the migration." Each one is written down, on a ticket nobody outside the team reads.

3. Week 3

   The board says done

   An epic is closed so the board looks right, with three bugs still open under it. The burndown stays green.

4. Two weeks out

   The slip surfaces

   The first team that depends on the others finds it cannot start. Every downstream date moves at once.

5. Launch review

   An executive steps in

   The date is now decided in an escalation meeting, with less time and fewer options than there were three weeks earlier.

On the fictional Northwind program, the agent finds a ten-day launch slip that every status report missed; the cost of that delay is the money leadership is asked to act on, and the asks it drafts win most of those days back if people take them.

$499K

Cost of delay at risk: 10 days late × $49,863 a day (checkout’s $455M a year ÷ 365 × a 4% conversion uplift from saved payment methods). Exposure, not a saving.

$70K

A year in program manager time: 468 hours of status meetings, chasing and write-ups (5 teams × 2 h a week, less 1 h to check the brief, 52 weeks, $150 an hour).

8 days

Recovered if the asks are taken ($399K, conditional, not counted as a saving): legal expedites the contract review, added scope is deferred, identity starts now. Two days still need a leadership decision.

Tracker dashboards and engineering analytics tools already chart the work. Here is what each does, and where an agent adds something new. In every column, people make the final call.

1. Read

   The work, not the report

   Tickets, points, epics and comments from your tracker; reviews and checks from your repositories; out of office and holidays from team calendars; velocity from past sprints.

2. Forecast

   Points left, at the pace the team keeps

   Plain code divides each milestone’s open points by the team’s recent velocity, then pushes every forecast through its dependencies. The forecast is compared with the due date and with what the team reported.

3. Blockers

   What the data shows, and what only reading shows

   Rules catch a late dependency, an owner out of office on the due date, reviews waiting more than three days, tickets untouched for a week, and scope added after the commit. The agent reads the comments for waits on other teams and work parked behind something else, and notices an epic closed with bugs still open.

4. Recommend

   One ask per milestone

   Push, Reassign, Cut scope or Escalate, by the same rules every week. Escalate only when someone above the team has to decide a date, scope or people.

5. Draft

   The ask, ready to send

   A short paragraph to each team lead, saying what the work shows and what would help. The program manager edits it, sends it or drops it.

6. Brief

   One page for leadership

   Status in one line, the decisions needed, the pushes this week, and the forecast with and without the asks.

In your environment

Next to your tracker, repositories and calendars, with read-only access.

Your plan

Milestones, due dates and dependencies are yours; the agent forecasts against them and never edits them.

Into your tools

Asks as drafts in chat or email, the brief where leadership reads it.

People decide

Every ask is a draft until the program manager sends it. Every date, scope and staffing call stays with the people who own it.

The demonstration above runs on a fictional company’s program. On yours, the agent connects to your tracker, repositories and calendars, inside your environment. Design partners can pilot it on a live program.