Four people were the company
In the early years, our best engineers did most of the work. Preetham Reddy, Raja Vemuri and Sergey Ustimenko led the first clients, and Tyler Harker joined a few months later and took the accounts that mattered most. Everyone else worked in their shadow.
That was deliberate. We had decided quality mattered more than growth, so those four 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 be as big as four people 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 turned a four-person bottleneck into a wider one, and burned out more people doing it.
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. We collected the prompts our strongest engineers were using and shared them across the company, which sounds small and was not.
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 now begins with a foundation and can read how the last one was put together.
Then we trained people on it. Relentlessly, for years, until the parts of the work that could be automated were automated.
Why AI works here now
This is the part people get backwards.
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.
Preetham, Raja, Sergey and Tyler still set the standard. The difference is that the standard now lives in a system, so it applies to every project whether or not any 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.