Yes. A small team can keep AI coding agents building day and night, with people reviewing in the morning and queuing the next run before they log off. I’m doing it now on the agentic health startup I’m building, with one product lead, one designer and one senior engineer, all part-time. But the cycle only runs when the requirements are already explicit, consistent and written for an agent to read. Getting there took four versions of the spec across three releases. The delivery model is the easier half.
What does the 24-hour cycle look like?
McKinsey’s article “Rewiring software delivery for the agentic era” opens on a product owner at 9 a.m., reviewing overnight progress. A feature has moved from structured requirements to tested code, with edge cases flagged and trade-offs summarized. “No one worked late. AI agents did.”
In their model, people review outputs, resolve ambiguity and align stakeholders during the day. Agents run structured work overnight: enriching requirements, validating architecture, generating and testing code. Humans intervene “only at defined review gates rather than acting as intermediaries.”
That is close to my week. In each mini-sprint I write the spec changes and defect descriptions, with screenshots. The engineer turns them into an instruction for the agents, which run overnight. I QA the result in the morning. His hands-on time is about an hour per round: 30 to 45 minutes writing the instruction, then 15 to 20 minutes checking that the run hasn’t stopped, reviewing pull requests and pushing.
What does the model assume most teams don’t have?
It assumes the requirements exist. McKinsey’s prescription is to codify requirements, standards and architecture “in standardized, machine-readable formats” so agents can hand work to each other. They are right that “structured, connected knowledge is the foundation of agent autonomy.”
What the article doesn’t address is where correct, conflict-free requirements come from. That step decides whether the overnight run produces value or rework.
Our first attempt is the evidence. We finished design with 72 spec documents, over 1,000 pages, before engineering started. They were thorough. They were also written the way design documents get written: decision history, open questions, reviewer comments, and conflicts we had settled in conversation but never on the page. The agents got about halfway and lost the story. Some stopped mid-run on a decision flag nobody had removed. Others burned tokens combing the corpus for an answer.
It took four versions of the spec, across three releases, before the overnight cycle ran cleanly. The version that works converts the 72 documents into 1,300 behavior cards: one behavior per card, stated as what the product must and must not do, grouped into packets the engineer can sequence.
Definition — 24-hour agentic delivery cycle: a delivery model in which AI agents execute structured work overnight and people review, decide and re-queue during the day, stepping in at defined review gates.
Why can’t agents just enrich thin requirements overnight?
They can, and McKinsey lists “enriching requirements” as overnight work. But an agent enriching a requirement fills each gap with the most plausible answer. Plausible is not the same as decided. Someone reviews those assumptions in the morning, and every assumption the reviewer misses becomes code.
Every product mistake gets found somewhere: in the spec, in the build, in testing, or by a customer. The overnight cycle compresses the build to hours, which leaves the spec as the only cheap place to find them. A morning review of agent-written assumptions is a slower, costlier version of a decision the product team could have made the day before.
The fix comes before the run. Decide the behavior first: what the product does, what it never does, and what it does when it isn’t sure. Then the overnight work is execution against decisions, not invention.
Where does the human time go?
McKinsey says roles shift “toward architecture coherence, domain modeling, and AI supervision.” From the product side I’d say it more plainly: the time moves to design and spec writing. Engineering hands-on time collapsed. Product decision time did not. The critical path became how many hours the agents could run, which we now budget the way we used to budget developer hours.
Two lessons I’d add to McKinsey’s list:
Bring engineering into design earlier. I didn’t involve our engineer enough while the spec was being written. More joint work up front would have shortened the four rounds.
Keep people together on purpose. McKinsey is right that humans stay deeply involved. It isn’t only about catching drift. Some of the best product decisions come from two people looking at the same screen and seeing something neither expected. An agent pipeline won’t schedule that for you.
What should a leader ask before adopting this model?
The questions apply to product builds and operations projects alike. Wherever agents execute work from documents, these decide whether the cycle pays:
Are teams changing their own workflows and handoffs, or adding agents to the old ones?
What do the specs look like today, and who are they written for: people or agents?
How are specs cleaned, de-conflicted and formatted before an agent sees them?
How efficiently do the agents run against them, and where do they stop?
How close to the spec does the output land, and how much does each release drift?
Is the outcome what the business needs, across market, user, operations and revenue?
How does PBA fit?
We built Product Behavior Architecture (PBA) for our own workflow, concept through delivery. The workflow we landed on is close to McKinsey’s. The difference is where it starts. PBA is an AI-native product operating system that begins at the business model — market viability, user experience, operational feasibility and revenue model integrity — decides how the product must behave, resolves conflicts across the corpus, and hands agents behavior cards they can execute. That is the layer the overnight cycle depends on.
Healthcare is where I’m doing this work. The pattern isn’t specific to healthcare.
Takeaway
The 24-hour cycle is real, and a small team can run it. It runs on requirements that are explicit, conflict-free, faithful to the business and readable by an agent. Producing those is now the product team’s job, and it is where most of the time goes.
AI builds fast. How are your teams defining and deciding before the build?
Frequently Asked Questions
What is a 24-hour agentic delivery cycle?
A delivery model in which AI agents execute structured work overnight — enriching requirements, writing and testing code — while people review, decide and re-queue during the day. Humans step in at defined review gates instead of passing work between tools by hand.
How small can a team running agentic delivery be?
On the agentic health startup I’m building, one product lead, one designer and one senior engineer, all part-time, keep agents building day and night. The engineer’s hands-on time is about an hour per round of changes.
What do AI agents need before they can deliver overnight?
Requirements that are explicit, conflict-free, faithful to the business and readable by an agent. Without them, agents fill gaps with plausible assumptions, and the morning review turns into rework.
If you want to compare notes on your own delivery model, book a discovery call: calendly.com/besserhealth/discovery
Related: What is a behavior card? · AI Builds Fast. Fixing What It Built Wrong Takes Longer.
