What the agentic operating model produced: 90 days to 5, multiple releases a day, zero incidents

Operating models are easy to describe and hard to prove. These are the numbers from a fintech of more than a hundred people, providing technology, payments and operations for consumer lenders, running on the model described in this series. They are the ones I put my name to.

Lead time: 90 days to 5

Before the model, the lead time from an accepted story to production was about ninety days, on an on-premise stack with manual environments and a release cadence measured in weeks. After, it is five days for 85% of all work. The remaining 15% are the stories that genuinely need longer: new integrations with a processor or a core, regulatory changes that require a review window, and the occasional thing that turns out to be bigger than the epic said.

What moved the number was not the agents writing faster. It was the working mock removing the back-and-forth over requirements, the locked tests removing the back-and-forth over "done," and the decoupled release removing the wait for a deployment window. The agents made each of those cheap enough to do every time.

Releases: multiple a day, zero incidents in a year

Every merge deploys dark. Releases happen when a person decides, several times a day, behind feature toggles, blue/green, API-versioned. In the last year there have been zero production incidents attributable to a release.

That number deserves a caveat so it is believed: zero incidents does not mean zero bugs. It means nothing a customer experienced as an outage, a wrong payout, or a broken flow that required an emergency fix. Bugs that reached production were caught by monitoring and turned off with a toggle, which is the whole point of decoupling deploy from release. A release you can reverse in seconds is a release you can make calmly.

The business: 2× revenue, 3× customers, margin held

Over the same period revenue doubled, the number of customers served each month tripled, and unit margin was held between 45 and 50 percent while the team grew from forty people to a hundred and ten. The last clause matters most. Growth that destroys margin is a cost center with a good quarter. The operating model let the company add capacity in product and engineering without the cost base growing faster than the business, which is the number the board actually asked about.

It scales to multiple teams and people

The most common objection to any agentic model is that it works for one senior engineer with a strong opinion and falls apart at team scale. This one ran across a product and engineering organization of more than a hundred people, with multiple teams working the same pipeline on the same codebase, each with its own stories in flight and its own named people at the gates. The guards do not care how many teams there are. The ledger records every gate. The hard part at scale was not the agents; it was training the product leads to own the ROI and the outcomes, which is why the leadership practice exists.

The second proof

The same model also built LPG's payments platform, where the stakes are sponsor banks and card networks and the rulebooks are theirs: the card-network operating rules, PCI, the sponsor's own program requirements. A platform that banks run merchant programs on is not a place to discover that your agents cut corners. It was built greenfield, from an empty repository, with the model enforced from the first commit.

What the numbers don't say

They do not say the model is free to install. It took months to build the hooks, guards and ledger, and it takes weeks to install in a new organization. They do not say agents replaced the engineers; the team grew. And they do not say this works without a leader who will hold the gates when the schedule is screaming, which is the part no tool provides.

The full write-up is on the agentic operating model page, and the case study is on the track record.