Ten agent prompts to find your delivery bottleneck this week

You find a delivery constraint, the bottleneck the rest of the system waits on, by measuring where work waits, not where people are busy. The evidence is already in your pull requests, tickets, CI runs, and chat threads; the only reason nobody has looked is that joining them used to be somebody's lost afternoon. A coding agent with read-only access can do the join in an afternoon. Below are the ten prompts we'd paste, roughly in order, with a benchmark to compare against where one exists and what to do if the answer is bad. Every "I can't compute that" the agent gives back is a finding too: a place your delivery system is invisible to the people running it.

Wire the agent up: read-only, one stream, 90 days

Pick one product stream. Give a coding agent (Claude Code, Codex, whatever your team runs) read-only access to four things: version control (PRs, reviews, merge and deploy events), tickets (Jira, Linear, Azure Boards), CI/CD run history, and the chat channels where work gets unstuck. The plumbing is official now, over MCP (Model Context Protocol) servers: GitHub's MCP server, Atlassian's Rovo MCP server, and Slack's MCP server, generally available since February 2026. Where there's no MCP server, the vendor CLI works; gh run list, with a generous limit, gets you a year of Actions history. Scoped token, read-only, and show your security team the scopes before they ask. Their next question is where the data goes: run the agent under whatever AI data agreement your organization already has (the enterprise tier of the tool you use, not a personal account), point it only at the channels you name, and where a works council or a monitoring policy applies, ask first.

Which plumbing you need depends on the stack you run. The list below is the short one we reach for: the vendor's own CLI where one exists, the vendor's own MCP server where one exists, and a note on the read-only path for each. If your tool isn't here, the test is the same: can the agent list, search, and read history without a person in the loop? Then it's enough.

Ninety days is the window for the queue prompts: long enough to see a pattern, short enough that you're measuring the team you still have. The two trend prompts, 5 and 6, go back further, because a drift needs a baseline. Every prompt ends by telling the agent to show its work, because it will produce a confident number from messy data. Before you forward anything, recompute one number by hand.

Prompts 1–3: where work waits

The age of the oldest item in a queue is the constraint waving at you. Not the average, the oldest: averages hide the aging tail, and the tail is where lead time lives. Meta found the same in its own review data: median time-in-review was a few hours, but the slowest 25% of diffs could sit an extra day, and that p75 was what predicted how unhappy engineers were with review. Benchmark: LinearB's 2026 report across 8.1 million PRs puts p75 pickup under an hour for the top tier, 1 to 4 hours for good, 5 to 16 for fair, and past 16 hours as needs focus. Same dataset: agent-written PRs waited 5.3 times longer for pickup, and only 32.7% merged within 30 days versus 84.5% of unassisted ones. If your split looks like that, you already know which lane is queuing.

Flow efficiency is touch time divided by total lead time. David J. Anderson has said the firms he sees run at 5% to 15%, most cases near the bottom of a 1% to 25% range; the one published multi-team dataset we know of, 63 teams at ASOS, averaged 35%. Touch time is the estimated leg, so read your number as an order of magnitude, not a score: under 20% and most of the lead time is queue, and Prompts 3 and 9 tell you which one. Either way, most of a ticket's life is waiting. If the agent can't build the timeline because tickets aren't linked to PRs or deploys aren't logged anywhere it can read, that is the finding: you're managing a pipeline nobody can see.

Queues are properties of the system; the moment the answer is a team name, the exercise turns political and the data stops being honest. An agent will hand you a name if the prompt allows one. Don't let it. Expect review to win: Faros AI's 2026 telemetry across 22,000 developers found median time to first review up 156.6% and median time in review up 441.5% as teams moved from their lowest- to their highest-AI-adoption quarters. More arriving, same people reading it.

Prompt 4: the break test

Whatever it names is the candidate; if it disagrees with the queue Prompt 3 named, that disagreement is worth an hour of your time. If your AI spend sits upstream of the break point, it's making the pile in front of the break grow faster. DORA's 2024 report estimated a 7.2% drop in delivery stability for every 25% increase in AI adoption; and, announcing its 2025 report, DORA put the mechanism plainly: acceleration "can expose weaknesses downstream." The break test finds yours before volume does.

Prompts 5–7: gates, batch size, inventory

An approval that hasn't caught anything in a year is not a control; it's a queue wearing a control's badge. DORA has said this since 2019: teams needing sign-off from an external body like a CAB were 2.6 times more likely to be low performers, with no evidence the extra approval lowered change failure rate. Quick win: retire the gate that caught nothing, or make it advisory; if it's a compliance requirement you can't drop, make it asynchronous so it stops holding the merge.

This is the earliest tooling-visible signature of AI-era instability. Reviewer defect detection falls off past roughly 200 to 400 lines; Google's study of nine million reviews found a median change of 24 lines and first feedback in under an hour for small changes, which is not a coincidence. The drift is real: LinearB's p75 PR size is 157 lines unassisted and 400-plus AI-assisted; DX's Q2 2026 benchmark saw median PR size nearly double, from roughly 42 to 72 lines, between Q3 2025 and Q2 2026 as AI-generated code hit 52% of what shipped. And watch the no-comments share: Faros found PRs merged without review up 31.3% over the same adoption climb. When 600-line diffs get an LGTM in 90 seconds, review didn't get faster. It stopped. Quick win: a PR size budget, enforced by a bot, not a policy doc.

That's inventory: cost fully paid, value zero, risk accruing while it waits. In DORA's 2025 data only 16.2% of respondents deploy on demand and about 55% deploy less than weekly, so the pile is probably bigger than you think. AI made work in progress cheaper to create than ever; that's why it's the pile to watch first.

Prompts 8–9: WIP and environments

Little's Law makes this arithmetic rather than opinion: average lead time equals work in progress divided by throughput. A team finishing 20 items a week with 40 in flight has a two-week lead time; let agents push in-flight work to 80 while review capacity stays fixed and lead time doubles. Nothing broke and nobody slacked. Producing more without finishing more mathematically slows delivery down. If the estimate and the observed lead time disagree badly, the board is lying: tickets marked done that aren't, or agent work that never got a ticket. Quick win: agent PRs count against the same WIP limit as everyone else's.

DORA's line is blunt: if you have to file a ticket and wait for someone to prepare an environment, you don't have automated deployment. If a developer can't get a production-like environment in under an hour without asking anyone, environments are the next constraint after you fix review. Constraints move; know where yours goes next.

Prompt 10: put it together

The first nine prompts each look at one queue; this one couples the backlog to the PR pipeline and asks for the whole lifecycle, measured the way a value stream map measures it: process time against lead time, stage by stage. Read the gap column, not the totals. Then walk it. Pick one ticket from the thirty and follow it through the map by hand; better, sit next to a reviewer opening a 900-line generated diff and watch them deflate. The map says where the time went; the watching says why. If nobody who runs the team has ever watched one feature travel the whole stream, the draft is still secondhand.

What to do with the answers

You'll come out holding four things: one number (flow efficiency), one queue name (usually review or environments), one break point, and a first-draft value stream map with process time and lead time for every stage. The draft is not the map. The map is a week of walking the stream with the people who work in it, not a program; the draft tells you where to start walking and what to ask. The benchmarks tell you which lane is queuing; don't turn them into targets, or pickup time will improve while review stops.

Three honesty clauses. If the agent keeps saying "I can't tell" because tickets aren't linked to PRs or deploys aren't logged, fix the plumbing first. You're not alone: 60% of respondents to Jellyfish's 2026 engineering-management survey said they need better data to understand productivity. If your CI doesn't actually run the tests, fix that before any flow policy. And if the prompts keep pointing at one overloaded person, the architect every change routes through, that's a role-design conversation to have like adults, not an automation target. The agent will find that person fast and doesn't know it's supposed to be tactful. Aggregate by queue and role before anything leaves the room, and read the output before you forward it.

The Sigao take

Ten prompts, one afternoon, an agent you already pay for. What to do next (the mapping method, the constraint playbook, the flow policies, the 90-day arc) is in our whitepaper, The Bottleneck Isn't the Model. It's free. The AI value calculator puts a dollar figure on the gap; the maturity assessment takes ten minutes. If you'd rather run the first pass with us, write chris@sigao.io and we'll map one value stream with your team.

Sources

• Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement, North River Press, 1984.
• John D. C. Little, "A Proof for the Queuing Formula L = λW", Operations Research, 1961.
• LinearB, 2026 Software Engineering Benchmarks Report and its summary post: p75 pickup, review, and PR-size tiers across 8.1 million PRs, and the agentic and AI-assisted versus unassisted splits. Vendor telemetry.
• Caitlin Sadowski et al., "Modern Code Review: A Case Study at Google", ICSE-SEIP 2018: median change size and review latency.
• Meta Engineering, "Move faster, wait less: Improving code review time at Meta", 2022: p75 time in review as the number that predicts satisfaction.
• Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash, 2026: review-time, PR-size, and merged-without-review shifts as teams moved from their lowest- to their highest-AI-adoption quarters. Vendor telemetry; directionally consistent with DORA.
• DORA, Accelerate State of DevOps 2019: external change approval and the 2.6 times finding.
• DORA, Accelerate State of DevOps 2024: stability per 25% increase in AI adoption.
• DORA, State of AI-assisted Software Development 2025 and its announcement: downstream weaknesses and the deployment-frequency distribution. The latest annual edition published as of this writing.
• DORA, Deployment automation capability guide.
• DX, The State of AI Impact in Engineering: Q2 2026: median PR-size and AI-generated-code trends across 500-plus engineering organizations. Vendor telemetry.
• David J. Anderson, "What We Know About Duration: Workflows", 2016: the 1% to 25% practitioner range; the 5% to 15% figure is Anderson's remark as quoted by Brown.
• Nick Brown, "Uncovering the real numbers behind flow efficiency", 2023: the ASOS dataset, 63 teams.
• SmartBear, Best Practices for Peer Code Review: the 200–400 line review ceiling, drawn from SmartBear's 2006 Cisco case study of 2,500 reviews.
• Jellyfish, 2026 State of Engineering Management: the data-gap finding across 635-plus respondents. Vendor survey.