Why we decided to open source Relate

We have been deep in the weeds of various clients' workflows. Each one could have been its own SaaS tool. Our view is that going forward this will no longer be the case. Agents can now produce decent user interfaces with hardly any guidance, and pretty good ones in the hands of someone with "taste".

So does this mean that software is dead? Not in our view. There are many low-level components which we should not be rebuilding for each app. Yes, agents do know how to implement an idempotency key. They also know when to implement one. But they will not implement one each time they should. The knowledge exists in the model weights, but that knowledge may not be applied. In production, you will hit a bug and need to fix it. There are millions of similar cases.

There is a gap between what a model knows and what it reliably does. Researchers have documented a related “knowing-doing gap”^{1The knowing-doing gap in LLM tool use} in tool use: a model can recognise that a tool is needed and still fail to use it. Knowing the right thing to do does not guarantee doing it when it matters.

So why go through the pain of "hand-rolling" low-level components from scratch? We believe there is great value in using software that is battle-tested across multiple deployments. Especially when it is open source and can be patched by developers across the world (or their agents).

Defining a permission-aware business ontology, which connects your systems, is exactly this sort of problem. Lots of boring, repetitive code that should work efficiently and without errors. That is Relate.

What Relate does

You define your business once: customers, invoices, campaigns, and how they relate.

• Sources hidden behind the semantic model. Connect your CRM, billing database or data warehouse. Apps and agents never see them. They read and write semantic business objects.
• Permissions down to the field. Every read is filtered for whoever is asking. Finance sees revenue, the account manager doesn't.
• Composite objects. An account built from three systems is one object, so you do not need to rebuild it in every app.
• An activity timeline. What changed on an object, when, and where it came from. Full lineage of how work is done.
• Aggregations and analytics. Totals and breakdowns over the same model, using the same global permissions.
• One model, every interface. MCP, HTTP, an SDK and a CLI all read the same thing.

We are early, not ready for production workloads, and definitely not yet battle-tested.

We would very much appreciate your feedback or a GitHub ⭐.

Relate on GitHub · Relate website