Why we rebuilt how we ship, and what it cost us
A senior leader at a Fortune 10 financial institution put the problem to us plainly.
Technology in the AI world is going obsolete in about five months. His organisation takes two to three years to deploy anything. Assessment, ecosystem consolidation, consultancies, then phased rollout across business units and geographies. None of that is waste. All of it exists for good reasons, most of them written down after something went wrong.
So where does he start?
Whatever he chooses today will have been overtaken three or four times before it finishes rolling out. He isn't being slow. He's being careful, in exactly the way his regulators and his board expect. And the result is that he can't confidently pick anything, because he can't name a system that will still be worth having in three years.
That is not a technology problem. It's decision paralysis, and it is where a lot of serious buyers are sitting right now.
What you are actually buying
The instinct is to say long contracts are finished. That's too easy, and it isn't what we hear from buyers.
Three-year commitments still make sense. What has changed is what they're a bet on.
They used to be a bet on a product. You evaluated what was in front of you, decided it was the best available, and signed. That worked while capability moved slowly enough that the best product in year one was still a good product in year three.
Now the commitment has to be a bet on something else entirely: whether the vendor can keep changing at the rate the world is changing. Whether five months from now, when the ground has moved again, this vendor moved with it.
The buyer's position, put to us directly: I don't need a vendor that has a great product today. I need a vendor that continues to have a great product every single day.
That reframes what a vendor owes a customer during evaluation. Showing a good product is no longer the hard part. Demonstrating a credible rate of change is. And you cannot demonstrate that with a roadmap slide, because a roadmap is a description of intentions. The only convincing evidence is how you actually operate.
Why nobody can move
Here is the uncomfortable part. Most large organisations could not be nimble right now even if they decided to be.
The structures that make an enterprise trustworthy are the same structures that make it slow. Guidelines, baselines, policies, approval gates, change advisory boards, sign-off chains. Each one was added in response to something real. Together they mean that a decision to move faster runs into a process that cannot.
It shows up most clearly in how enterprises take releases. Plenty of them run n-1 deliberately. They don't want the newest version, they want the one before it, because the newest hasn't been proven in the field yet. That's a rational policy under the old assumptions.
Run it against a six-month release cycle and look at what you get. You are deploying software that is already six months old on the day it lands. Add your own testing and rollout time and it's older still.
In a world moving at five months, being one release behind isn't caution. If you aren't at zero, you're already obsolete.
The same pressure is already showing up elsewhere. Modernisation plans were built on multi-year horizons because the urgency was modest, and that urgency has changed. Plenty of those plans now need to compress. Release policy is the same problem, one layer down.
Vendors have the same disease, and we had it too. The old rhythm was to accumulate feature requests and roadmap items over three to six months, gang them into a release, test the batch, then push it. Everything in that model assumes the queue can wait.
The benchmark already moved
Frontier AI labs now push releases two or three times a day. Not hotfixes. Real changes, continuously, in public.
That has quietly reset what "current" means. Work that used to be measured in release cycles is now measured in hours. Enterprise software has largely not caught up, and buyers have noticed the gap even when they don't have words for it.
We ship SynthAI about three times a day. We are not claiming that as a virtue. It is the minimum rate at which we think a vendor can honestly promise to still be relevant in three years.
What we had to tear up
Wanting to be nimble does nothing. The constraint is almost never intent, it's machinery.
Plenty of teams want to put out a release in three days and find their own process won't let them. Ours wouldn't. Getting to a daily cadence meant dismantling how we built software, and it was genuinely difficult. Harder than the engineering it was meant to enable.
The first move was collapsing a sprawl of overlapping processes into a small number of primary ones. Not simplifying the work. Simplifying the path the work travels. Most of the delay in a slow release pipeline isn't the doing, it's the queuing between stages, and every extra stage adds another queue and another handoff where something waits for a human who is in a meeting.
The second move was harder and is the reason any of this holds. Most of the execution inside those processes is now carried by structured AI agents rather than people. They run the checks. They exercise regression suites. They validate behaviour against expected outcomes. They carry out third-party assessment and supply chain verification on every change.
The point is not that agents are faster than people, though they are. It's that this work is unbounded. A human team can run a fraction of the validation a release deserves before shipping. Agents run all of it, on every change, without the fatigue that makes the twelfth review worse than the first.
That is also the honest answer to how a security company justifies shipping three times a day. We are not shipping with less scrutiny than a quarterly release. Each change gets considerably more, because the scrutiny stopped being rationed by how many people were available to perform it.
None of this was free. Rebuilding the pipeline took engineering time that would otherwise have gone into the product, and for a stretch it made us slower in order to make us fast. We would do it again, but we would not describe it as a clean process.
Someone else's bad code, on your books
Supply chain is the largest risk in this picture, and it's the reason the validation work cannot be optional.
You can write good software and still be compromised. Somebody else wrote a library, that library was vulnerable, you depended on it. Their mistake is now sitting on your risk register. You carried it onto your books the moment you imported it.
We've written separately about why supply chain became the dominant attack surface, and that argument is about attackers. This one is about us. The same risk changes shape when a vendor moves from quarterly releases to daily ones.
That risk scales with release frequency. Every change that pulls in a dependency is another chance to inherit somebody else's failure. A vendor shipping three times a day without automated supply chain verification is not nimble, it's reckless, and the distinction matters enormously to anyone in a regulated industry.
This is the part of the rebuild we would defend first if challenged. Speed without third-party assessment on every change is not a capability. It is an unpriced liability being transferred to the customer.
Why shipping this fast is safe for you
Fast releases are only worth anything if they don't break what you've already built. Most platforms can't promise that, and the reason is architectural.
Bloo binds late. Telemetry lands raw and unflattened, and what the fields mean is worked out at query time against a catalog that can change without reloading anything. Freeze the meaning at write time and you have frozen the record to today's understanding of the data. Then a source renames a field, and the choice is between breaking what's downstream and losing the information.
Late binding refuses that choice, and it is precisely why we can ship daily without breaking your detections. There is no new contract being shipped between our storage layer and your logic.
Underneath it sits one commitment that doesn't move.
Everything at Bloo is allowed to drift except the record. The raw telemetry, at full fidelity, as it was actually observed. And the logic applied to it: what was looked for, where, under what conditions, bound to which fields.
Elsewhere we've called this a complete memory. Everything else is disposable, our own product included. Four things follow from it, and each costs us something:
We keep everything, forever. You cannot produce evidence from telemetry you threw away, and the call to sample is almost never made by the person who later needs the data. It's also why we price on time rather than volume. A system of record that charges you more for remembering more is a meter with a conflict of interest. The cost to us is storage, permanently, against every incentive to sample.
We save the logic, not the thinking. When an investigation finishes we keep the query artefact, not the model's reasoning. It re-runs for free, it doesn't care which model wrote it, and an auditor can read it. We've argued before that AI in detection should be the librarian, not the judge. The cost is that we can't make the autonomy claims our competitors make freely.
One surface, not four. Completeness cannot be evidenced across systems that don't talk to each other. The cost is deals, because a best-of-breed feature matrix beats us on paper more often than we'd like.
No capability claim before a parallel run. Human analysts and agents work the same queue on the same cases for months before we describe anything as reliable. The cost is deliberately duplicated work, and ground ceded to anyone willing to claim autonomy without earning it.
The rules that settle arguments
Principles are cheap until they decide something. These four end arguments here, and each has cost work that was already finished.
Telemetry gaps before detection gaps. Before a rule gets written, the question is whether the logs exist to support it. A detection that fires on data you don't reliably collect isn't coverage, it's the appearance of coverage, and that's worse than an honest gap because an honest gap gets funded.
Our output is detections, not PDFs. Research that doesn't end in something deployable isn't finished. A beautifully written threat report that produces no rule hasn't been delivered, it's been described.
We show the unfinished work. On a recent partner call we demonstrated live schema extraction across a data fabric, then said plainly that automated conversion into Splunk's query language wasn't done yet. Not "on the roadmap." Not done yet. That's the version of the demo we want given every time, because the other version buys a good meeting and costs you the second year.
No claim before the parallel run. This has delayed announcements we wanted to make. It will delay more.
What we haven't worked out
We don't have a clean answer for when a parallel run ends. "Thousands of cases over months" is true but it isn't a threshold, and nobody in this industry has established what that moment actually looks like.
Cost observability is the second one. Metering consumption honestly is easy to say and harder to build at the granularity that makes it useful. It isn't finished.
Back to the paralysis
The leader who described his problem to us wasn't looking for reassurance. He was looking for a way to make a decision he could defend in three years.
There isn't a version of that decision where the product he picks stays still. The only thing worth evaluating is whether the vendor behind it can keep moving, and whether they've done the unglamorous internal work that makes moving possible rather than promised.
That is why this post is about our release pipeline rather than our features. The features will have changed by the time you read this. The pipeline is the part that determines what they'll be.
Our platform should change constantly, faster than you can buy it, and we should be a little embarrassed by what we shipped a year ago.
What it remembers should not change at all.