Stop Ripping Out Your Tools. Start Stitching Them Together.

We've always known exactly what Zaro does, but sometimes a customer, a representative of a legal firm, in this case, can distil the message far better than anyone on the inside. "So, you're telling me Zaro just helps organise my company's data to be a better interface for AI. That's it."

That's it. Simple, because the truth usually is.

We call it heavier things ourselves: context layer, semantic layer, unified data fabric. All pointing at the same thing she landed on in one sentence: the company's own knowledge, useful to the people who built it, invisible to the AI trying to work alongside them.

She asked the question that matters more than any feature list. "Where do I even start?"

The company data, in her words, was a mess. She had no idea how to make AI useful with it. It's the default state of almost every organisation, and it's the reason enterprise AI keeps landing well in the room and going nowhere after.

The Stitching Instinct

The pattern is always the same, wherever we look. A 1,300-person real estate firm in California, still early in its AI adoption, has data scattered across a dozen different places and no clear route from wanting AI to actually deploying it. A much smaller company further down the same road has already rolled out a string of AI tools and is now trying to build its own semantic layer from scratch because every tool it has added operates on its own isolated island. Different starting points, same conclusion. Nobody arrives asking to throw out what they already run.

What they ask for is closer to what that lawyer meant before she ever got to her sentence about interfaces. She did not want to replace the practice management software, the email system, or the tools her staff already knew how to use. She wanted them stitched together so an AI system could see them all at once.

That distinction matters more than it sounds. Point-to-point integration between two tools is straightforward enough. Point-to-point integration between fifteen tools, each added at a different time for a different reason, is how a company ends up with data everywhere and answers nowhere. The fix was never a bigger rip-and-replace project.

That's precisely the case for a context layer, stated plainly. It sits across everything a company already runs, making the whole of it legible to the systems that try to use it.

Neither Prompt Nor Retrieval

The instinct, when AI stalls, is to reach for a better prompt or a smarter retrieval pipeline. Both help at the margins. Neither is the actual work.

Prompt engineering shapes a single instruction. Retrieval fetches documents when asked. Context engineering sits underneath both: the ongoing practice of deciding what an AI system should know, how that knowledge is structured, who can see and change it, and how it accumulates the longer the organisation uses it.

Qian Zheng, our CTO, describes context as the sum of the connected tools, data, and organisational memory within which an agent operates. Not a document store. Not a single database. The company's entire working memory made available to the systems trying to help run it.

A good model with bad context produces bad outputs. A mediocre model with excellent context produces excellent outcomes. That asymmetry is why point solutions plateau: a better prompt makes one query better, a context layer makes every query better, including the ones nobody has written yet.

Never The App

For months, the instinct across the AI market, Zaro included, was to lead with what the system builds. Show the agent. Show the app it generates. Let the use case speak for itself.

The app is the wrong place to look. On its own, it invites comparison: this looks like Claude, this looks like Lovable; surely a weekend and an API key gets you the same thing. The comparison misses what matters, because the app was never the point. The context layer is the product. Everything else - the agents, the applications, the workflows - is a byproduct of it. What varies from company to company is only the surface that proves the layer is working: a dashboard here, a drafting tool there, an agent somewhere else. The layer underneath does not change. The surface on top does.

Take a concrete case. A finance team asks: "Flag every supplier contract renewing in the next 60 days." The list comes back sourced from the emails, the contracts folder, and the accounting system, each line traceable to the document it came from. Ask a different question next week, about pricing instead of renewals, and the answer comes back sharper, because the system already knows where the contracts live and how the team likes its answers structured. That improvement is the context layer working. The renewal list is just the surface it happened to take that day.

That's the shift in how to read any of these systems. Look at what happens underneath, and imagine every app the company will ever need built on top of it.

A Discipline Not a Feature

A feature ships once and sits still. Context engineering does exactly the opposite; it's dynamic because the information underneath it never stops changing.

Every correction a person makes to an AI's output is context. Every document a team adds is context. Every account history, every pricing decision, every internal note explaining why last quarter's approach did not work, all of it's context, and all of it needs somewhere permanent to live.

That is why bolting a context layer onto an existing tool never quite works. A feature answers a fixed question. A discipline answers a moving one: what does this organisation know today, and how do we make sure it knows more tomorrow than it did this morning?

Versioned, so the history of what changed and why is never lost. Permissioned, so the right people and the right agents see only what they should. Model-agnostic, so switching providers does not mean starting the memory over from nothing.

Together, that's the ongoing job of running a company that wants its AI to get better rather than reset.

Picture the alternative. A team bolts a memory feature onto their existing chatbot. It works for a month. Then someone leaves, a new provider offers a cheaper model, or a client asks who had access to what and when, and the feature has no answer, because nobody was doing the discipline underneath it. Context engineering is what stops that gap from opening in the first place. It's unglamorous, ongoing, and exactly the sort of infrastructure work that only gets noticed when it's missing.

The Mess That Stayed

Consider that legal firm representative for a second, and what the day made visible.

Her firm runs matter files in one system, client email in another, billing narratives in a third, and case history going back years that nobody has ever fully indexed. Ask a junior associate to brief a partner on a client before a call, and the honest answer is it depends how much time they have, and how well they happen to know where things are filed.

Point a context layer at that exact mess and ask it a real question: what's the current status of this client's open matters, and what's changed in the last two weeks, and the answer comes back with the billing note, the email thread, and the associate's last update, each one cited to the document it came from. Nobody migrates anything first. Nobody cleans up a folder structure or builds a new taxonomy. The mess stays exactly where it was.

That's the part that disappears when this stays abstract. The actual chaos already sitting in a company's own systems, the chaos most teams have simply learned to work around, becomes usable in real time, with no six-month implementation project standing between where a company is and that answer.

Any organisation with matter files, client threads, and years of unindexed history sitting in separate systems is looking at the same gap. Worth asking what a single well-cited answer, pulled straight from what's already there, would actually be worth.

Context-Aware Not Context-Compounding

Most AI tools today are context-aware in the narrowest sense. They can read a document you hand them. They cannot remember what they learned five minutes ago once the session ends. Whatever context does survive stays siloed with the person who typed it, because there is no shared layer underneath for it to land in.

Context-compounding is different. Every interaction leaves something behind. A correction made once benefits every future query. A pattern noticed by one team becomes visible to another. The system knows more on Friday than it did on Monday, by design rather than by accident.

This is the distance between a tool that performs well in a demo and a system that earns its place in how a company actually runs. One resets. The other remembers, and gets sharper because it does.

The Unnamed Discipline

Software engineering in 2005 was not yet the profession it is today. Version control was inconsistent. Testing was optional in most shops. The practices that now feel obvious, code review, continuous integration, structured deployment, were still being worked out in public, by teams learning from each other's mistakes.

Context engineering is at that stage now. The organisations doing it well are not publicising a methodology. They are quietly building the discipline before anyone has agreed on its name.

Those who get there early will not be easy to catch. Not because the model they use will be better. The models are converging, and the gap between frontier providers continues to narrow. The advantage belongs to whoever has spent the most time building the underlying memory.

That work starts with a simple question, the one that a legal firm representative asked without needing anyone to teach it to her. Where do I even start?

The answer is always the same. Start with what the company already knows, and give it somewhere to live.