The company ran on top engineers
In the early years the work went wherever our strongest engineers were. A project went well because a particular person was on it, and as more good engineers joined they took charge of their own accounts the same way.
That was deliberate. We had decided quality mattered more than growth, so the people who knew the standard reviewed every project and left no stone unturned. Clients got the best engineers in the building on their problem, every time.
It also meant the company could only grow at the rate we found people like that, and only as large as they could personally supervise.
"We were in every project. That was the promise we had made to clients, and for a long time it was the only way we knew how to keep it."
Raja Vemuri, VP of Development
"I looked after the accounts we could least afford to get wrong, so I was the escalation path for all of them at once. That holds up until two of them need you in the same week."
Tyler Harker, Engineering Manager
Hiring did not fix it
We kept hiring strong engineers, and each one moved the ceiling. None of them removed it.
Without repeatable processes, every new project still ran on somebody's judgement, and the people with that judgement were spread thinner across more work. We had widened the bottleneck without removing it, and burned out more people in the process.
We reached a quarter where taking on new work meant either lowering the standard or asking people to carry more than anyone should. So we stopped, and looked at what our strongest engineers did that the rest of us did not.
Almost all of it was knowledge, held in their heads and applied case by case. Which patterns hold under load. Which shortcuts cost you in month six. What to ask a client before writing anything. None of it was written down, because none of them had ever needed to write it down.
"Everything that made a project go well lived in a few people's heads. Writing it down felt slow at the time. It was the only thing that ever actually scaled."
Sergey Ustimenko, VP of Technology
What we built instead
Fabric started as the answer to that. Patterns and practices, codified.
We wrote down the starter kits, so a project begins from something already shaped by people who had built it correctly before. Sam Salima's design team built reusable components and a design system, and that became the base every client-specific design system starts from. Someone joining a project begins with a foundation and can read how the last one was put together.
Then we trained people on it, relentlessly, for years. Wherever a step in the work could be automated we automated it, and then we went looking for the next one.
All of this predates the current wave of AI. It was written down so that a good project stopped depending on which person happened to be staffed on it, and at the time that was the whole ambition.
Why AI works here now
This is the part people get backwards.
When the models became good enough to matter, the groundwork was already there. Our strongest engineers worked out what the tools were actually good for, and we collected their prompts and shared them across the company the same way we had been sharing starter kits and components for years. That took months rather than years, because writing down how we work was already the habit.
AI agents did not make us faster. Years of recording how we work is what made AI useful to us, because an agent is only as good as the context it can reach. Ours can reach a decade of patterns, prompts, components and decisions that were written down deliberately.
A firm that never did that groundwork gets an agent with nothing to stand on, which is why so many of those projects stall in a demo.
Fabric is where all of it lives: a context store with a memory, an agent runtime on top, and the permissions to let both touch real systems. It runs on Databricks. Retrieval is hybrid, and every answer comes back attached to the passage behind it, so it can be checked. More than fifty agents have defined jobs, and they reach other systems through more than a hundred integrations over the Model Context Protocol. Agents inherit permissions from Unity Catalog, and every change records who made it and which policy allowed it.
You can see the product at fabric.pro.
What changed
Delivery work that took ten people now takes three. Quality went up, and nobody is carrying the company on their back.
The people who set the standard still set it. The difference is that the standard now lives in a system, so it applies to every project whether or not any one of them is in the room.
Why it runs on Databricks
We considered running the context store separately, which would have been quicker to build.
It would also have meant copying governed data into a second system, keeping two sets of permissions in step, and explaining to a security team why both existed. Unity Catalog stays the single place access is decided, and the agents answer to it.
What you can use
The parts come apart. The durable agent runtime, the evaluation harness and the governed mutation pipeline are adoptable on their own.
Mostly it means an agent programme with us starts from software already running in production, built by a company that had to solve its own scaling problem first.