Building What’s Next.
A 27-person data analytics firm documents the real journey of going AI-native.
Across nine posts, we'll walk through the infrastructure switches, the workflows we never wrote down, the methodology we're codifying into software, and the things we're still figuring out. It's written for anyone wrestling with the same question: what does it actually mean to go AI-native? We don't have all the answers. But we have an honest story, told as we go.
It was March of 2026. Bill sat down to do spring cleaning on the knowledge base he'd spent the past seven months building.
What he found was 866 folders and 7,122 files, organized three different ways at once. Each version made sense at the time he built it. The August system made sense in August. The November system made sense in November. By March, he was running four interfaces simultaneously and none of them were talking to each other quite right.
The honest assessment was that the system worked. It just worked for a version of him that no longer quite existed.
——————
The experiment had started the previous August, quietly. No announcement, no initiative. Bill cleared some time on the calendar and asked himself a simple question: could he actually change how he ran a business, or was he just going to add a few new tools to the same old process?
Over the following months it grew into something real. A knowledge base. Named agents with distinct working styles. Morning briefings that arrived before coffee. A working relationship that required him to be precise about what he wanted and honest when the output wasn't good enough.
In December he started writing about it publicly in a Substack called The Pragmatic Architect. It wasn't the breathless kind of AI writing. It was grounded. What actually broke, what he got wrong, and the patterns he kept running into.
He wrote about the 95% of companies seeing zero return on their AI investments and traced the cause back to architecture rather than models. Organizations were buying tools and skipping the part where you redesign how information and decisions move through the business. He named the failure modes other people were quietly running into: treating a reasoning tool like a search bar, running four experiments thinly instead of one deeply, mistaking a tool you configured for a colleague who disagreed with you.
At one point he migrated his entire workflow from one AI provider to another in twenty-four hours, because nothing in his system was tied to a specific model.
——————
This turned from a one-man project into a company-wide change.
We're a 27-person data analytics firm, and for fifteen years we've done a particular kind of work. A client comes to us with an audience they need to move. We come back with a picture of who within that audience is actually reachable, which messages will shift behavior rather than just register, and where the investment math leads. The work is grounded in proprietary data and years of methodological judgment about what patterns actually predict behavior, not just what correlates with it. None of it scaled in a way that let us reach the clients who needed it most.
A Senate campaign could afford a full engagement. A smaller competitive state house district, in most cases, could not. The candidate running in a flip-able seat, the campaign manager with a small ad budget, the advocacy organization that needed to know which message would actually move their audience: those were the people who could most use what we did, and the ones our model made the hardest to serve.
The expertise that produced the work lived in a handful of people’s heads. Every new engagement required starting from scratch, because the methodology was inseparable from the analyst who carried it.
——————
At some point, and it's hard to name exactly when, the question shifted. Instead of asking how we make the current work faster, we started asking what it would mean to make the methodology itself available in a fundamentally different way.
We had a name for the trap we'd been circling. We'd seen it everywhere in our consulting work: executives proud of their AI initiatives, buying the right subscriptions, announcing the right pilots, making existing processes run on better fuel… we were building a faster horse.
For Causeway, the honest answer was that we were doing the same work at a better pace. The methodology that lived in three or four people's heads was still in three or four people's heads, just moving a little quicker. We didn't need a faster horse though; we needed to build a car.
To us, that distinction is what AI native means. Not using AI as a tool but expanding AI to what's possible. It's the difference between making the existing work faster and building something that couldn't have existed before.
A car requires different architecture, different principles, and a different theory of how the whole system works. We had the data and fifteen years of methodology. We had Bill's year of working out publicly what AI could actually do, including the failure modes, the traps, and the things most organizations got wrong before they got anything right. What we didn't have was a plan for what the car looked like.
Every decision since has come back to one question. Not are we faster. But are we doing something that wasn't possible before?
——————
This is the first of nine posts on what we did with that question, covering the principles, the architecture, the build, the deployment, and what we still don't know. Not a case study. A build log. Written while we're still doing it, because the cleaned-up version with the rough edges sanded off is the one that's least useful to anyone trying to figure out what to do next.
NEXT IN THE SERIES: Cleaning Out the Garage: Sprint 0. What we put on the table before we wrote a single line of code, and the principle we almost got wrong.