AI made your teams fast. A change that took a sprint now takes days. Agents write tests, draft specifications and refactor code. People in the business build their own tools.
Then the work reaches the rest of the enterprise. The budget was set last November. The change board meets on Thursdays. The portfolio is re-planned once a quarter. Work that took a day waits six weeks.
That gap is what this series is about.
What is agent-speed agility?
Agent-speed agility is the ability of an enterprise to turn the speed of its delivery teams, its AI agents and its citizen developers into outcomes at the same speed.
It describes the enterprise. A team can be fast on its own. Turning that speed into something customers use takes funding, governance, planning and skills that move at the same pace.
Why does this question come up now?
For twenty years, agile transformations started with the team. That made sense, because the team was the slowest part. Moving from a yearly release to a release every few weeks was the hard problem, and the loops around the team (budgets, approvals, steering) were roughly fast enough for that rhythm.
AI changed the ratio. Producing a change got much cheaper and faster. The loops around the team stayed the same. They were designed for a world where work arrived slowly, so they collect it in batches: a yearly budget round, a monthly committee, a quarterly re-plan.
When work arrives faster, those loops don't speed up. They fill up. Teams produce more, and more of it waits. A 2026 NBER study of more than 500,000 developers shows the pattern: with autonomous coding agents, commits rose by 240%, but releases rose by only 30% (Demirer, Musolff and Yang).
Here is a pattern I see again and again. The “Checkout Crew” finished a change to the payment flow in four days instead of the two weeks they had planned. It was tested, reviewed and ready to release. But the change board only met every second Thursday, and they had just missed it. So a four-day piece of work sat in a queue for another 12 days, waiting for a 20-minute decision.
Where does the speed get lost?
On the way up. I see it in four loops:
- Funding. Money is allocated to projects, once or twice a year. Finished work waits for a budget, and new ideas wait for the next round.
- Governance. Risk and change approval run through committees on a calendar. Routine changes queue next to risky ones.
- Planning. Priorities are reset once a quarter. Anything learned in between waits.
- Skills. Leaders are asked to approve work they can't yet judge. When they can't judge it, they slow it down.
Each loop on its own looks reasonable. Together they set the pace of the enterprise, and the slowest one wins. If your teams can release every day and funding is decided once a year, the enterprise moves at the speed of the budget.
What are the parts of the system?
It helps to see six parts in two groups.
Three sources of speed:
- Delivery teams who own products and turn ideas into working software.
- AI agents that write, test and review alongside them.
- Citizen developers in the business who build their own tools.
Three parts of the operating model, which turn that speed into outcomes:
- Funding that follows value instead of projects.
- Governance that runs at delivery speed.
- Skills that let people judge and direct AI-speed work.
The first group creates pace and reach. The second decides whether that pace lands anywhere useful. Teams without steady funding build things that stop. Agents without skilled people around them produce faster than anyone can check. Citizen developers without governance build a shadow catalogue of apps that nobody owns.
Most enterprises I work with aren't missing a part. They're out of balance. A typical picture: strong delivery teams, AI agents stuck in pilots, citizen developers with nowhere to build, funding decided once a year, governance and skills catching up. Every part exists. The weakest one sets the pace.
What does it look like in practice?
Agent-speed agility doesn't need a new framework. It needs each loop to run at the speed of the work it serves. In practice:
- Fund products and value streams, and rebalance every quarter. Lean portfolio management already describes how. The change is to treat it as the main lever instead of a reporting layer.
- Move routine control into the pipeline. Risk tiers, automated checks and evidence collected as the work happens. People review the exceptions. The same rules apply to code written by people and by agents.
- Plan in short loops. Keep quarterly objectives, and let plans change when the evidence does. In PI Planning, ask what teams waited for last time as well as what they will build next.
- Teach people to judge AI-speed work. Leaders learn what to ask of agent output. Product teams learn to write specifications good enough for an agent to build from. Citizen developers learn to build inside a catalogue with clear risk tiers.
None of this is exotic. Most of it already exists somewhere in your organisation. Agent-speed agility makes it the default.
Isn't this just agile with AI tools?
No. Adding AI tools to teams makes the imbalance worse: the fastest part gets faster and the slowest part stays where it is.
It isn't a replacement for SAFe or any other framework either. Frameworks already contain the loops: Lean portfolio management, PI Planning, guardrails. Agent-speed agility asks one question of each of them: does it run at the speed of the work?
How do you find your slowest loop?
Ask four questions:
- How often do teams release?
- How often do changes get approved?
- How often are priorities re-planned?
- How often is funding decided?
Divide the first answer by the slowest of the other three. If teams release every working day and funding is decided once a year, that is about 260 releases for every funding decision. The number is rough, and it doesn't need to be precise. It shows you where to look.
Then measure waiting time instead of velocity. How long does finished work wait before people use it? That number tells you more about your operating model than any team metric.
Where should a leadership team start?
Pick one value stream. Find its slowest loop. Change that loop for one quarter, and measure the waiting time before and after.
Don't start with a tool, a reorganisation or a new framework. Start with the loop that holds everything else back. Fixing it usually shows you the next one.
Questions leaders ask
Do we need AI agents to start?
No. The four loops already slow your teams down today. Agents make the gap wider and easier to see, which is why the question is urgent now.
Does this replace SAFe?
No. SAFe already describes most of the loops. Agent-speed agility is a way to check whether they run fast enough for teams that work with AI.
How does this work in a regulated industry?
Governance in the pipeline produces more evidence than a monthly committee. Every change carries its checks, its approvals and its link to a specification, which is usually easier to show an auditor.
What is the first sign of progress?
Shorter waiting time between "done" and "in use". When that number moves, the rest follows.
This is part 1 of Keeping pace, a six-part series on the operating model around fast teams. Next in the series: Why does finished work wait for the budget?
If you'd like a second pair of eyes on your slowest loop, book a 30-minute call.
About the author
Alexandru Negrilă
Advanced SAFe Program Consultant, Vienna
I started as a software developer and founded two tech companies. Since then I have led several complete SAFe transformations, the largest in banking and manufacturing, and set up agile, Scrum and SAFe practices at every level: within teams, across external partners and in the portfolio. I also teach SAFe as a certified trainer. Today I help enterprises adapt their operating model to teams that work with AI.