Three Blockers Our Agent-PM Caught This Week

We don't have a project manager at Mindops. We have an agent.

It's called agent-pm. It runs every morning at 08:30 as a K3s CronJob, reads the tasks table for the active sprint, looks at status transitions, time-in-column, assignee load, and dependency edges, and posts a sprint_health proposal to /hub/[ws]/proposals. We approve or reject from there.

This isn't a chatbot. It's a 5-minute-per-day Python-shaped scheduled job that returns structured JSON with three fields: summary, blockers[], suggested_actions[]. We've been running it for the full year of Mindops. Here are three real blockers it caught last week.

Blocker 1 — Stale task in "in-review" for 6 days

What it saw: MO-127 (a small UI fix) entered in-review last Monday and hadn't moved by Sunday. The acting reviewer (Aykut) had 4 other tasks in in-progress. The PR was open, CI was green.

What it proposed:

"MO-127 has been in review for 6 days. Reviewer Aykut has 4 in-progress tasks; review queue likely deprioritized. Suggested: ping reviewer in #hub or reassign to admin. Cost of waiting: blocks MO-131 (depends_on)."

What we did: Approved the "ping reviewer" action. The proposal carried a Telegram notify — Aykut got it, merged within 90 minutes.

What we'd have missed: Without agent-pm watching column-age, this would have been one of those tasks that just lives in review until someone notices during a retro. We've all done it.

Blocker 2 — Three tasks unassigned, sprint at day 4 of 14

What it saw: Sprint S-23 started Monday. By Thursday morning, three tasks (MO-130, MO-132, MO-134) were still in todo with assignee=null.

What it proposed:

"Sprint S-23 day 4/14: 3 tasks unassigned (MO-130, MO-132, MO-134). Workload distribution: erkut 6, ali 4, tugrul 3, aykut 1. Suggested: assign MO-132 (UI) to ali, MO-130 (API) to erkut, MO-134 (docs) to tugrul. Confidence: medium — based on past 30-day completion rate per assignee per label."

What we did: Approved 2 of 3, rejected the docs assignment (Tuğrul was on holiday — agent-pm doesn't read calendar yet). The reject reason went into the next run's context; the agent didn't suggest Tuğrul for the rest of the week.

What we'd have missed: The classic mid-sprint "wait, who's doing this" Slack thread on Friday. We had it, then we built agent-pm, now we don't.

Blocker 3 — Cyclic dependency between two epics

What it saw: MO-EPIC-3 (billing UI) had child task MO-141 linked depends_on MO-149, which was a child of MO-EPIC-4 (auth refactor), which had MO-152 linked depends_on MO-138 from MO-EPIC-3. A cycle. Drizzle task_links allowed it because task_links doesn't enforce DAG constraints (we noted this as a future migration).

What it proposed:

"Cyclic dependency detected: EPIC-3 → EPIC-4 → EPIC-3. MO-141, MO-149, MO-152, MO-138 form the cycle. No epic can complete in isolation. Suggested: meet to break cycle (likely move MO-138 out of EPIC-3 scope)."

What we did: Did the meeting. Moved MO-138 to MO-EPIC-5. Agent-pm ran the next morning and the cycle was gone.

What we'd have missed: Both epics would have been "almost done" forever. This kind of cross-epic dependency is invisible in any single-epic view.

What this isn't

It isn't AGI. It isn't autonomous. It's a scheduled job that reads structured data and writes structured proposals to a queue we approve or reject. The "intelligence" is mostly: agent-pm reads more rows, more often, more consistently than a human PM would, and writes structured output we can act on in 30 seconds.

For the past year of running our 5-person team this way:

• 9 agents total (5 site, 4 ops including agent-pm)
• 5 cron jobs keeping it scheduled
• 35-table schema behind the hub
• 17 MCP tools so we can also query/run it from Claude Code or Cursor

Every agent run is logged in agent_runs (public last 30 days at mindops.net/changelog). The three blockers above each have an agent_runs row you can find in the public log.

Want one for your team?

We built Mindops to run our own company first. The same 4 ops agents (PM, Customer, Finance, Personal Assistant) plus the Hub UI ship as on-premise install in your K3s, 6-8 week setup with us.

If your sprint board has tasks aging in columns, unassigned mid-sprint, or cross-epic dependencies nobody tracks — book a 30-minute discovery call: mindops.net/enterprise

Or watch ours run live first: mindops.net/agents-live.