Meet KAL, your Autonomous Data Office.
KAL is the data function of an enterprise: AI agents that answer business questions from your data, with every answer checked, scored, traced and auditable. Bring the questions that your team hasn’t had time to answer, and we’ll show you what KAL does with it.
What using KAL is like.
You ask a question the way you would ask a colleague: how many active customers do we actually have, who are the most valuable, and what is driving that value. KAL works across your systems, checks its own answer before you see it, and returns it with the evidence attached: what was checked, what was assumed, and why it passed. If you want to challenge it, the trail is right there. That is the whole experience. The machinery stays out of your way.
The workforce sizes itself to the question.
KAL is not a fixed pipeline. A question arrives. A planner works out what is actually being asked, which is often more than one thing. An orchestrator assigns the work. If a research lead decides the problem needs a data engineer, it brings one in and hands over a brief.
A simple question uses three agents. A hard one uses eight. Each runs on the model that suits its job, so heavy reasoning goes where heavy reasoning is needed and routine extraction does not. You are not paying for a large model to count rows.
You would not hire a data engineer for every question your business asks. But one should turn up when the question needs one.
What makes KAL different.
One definition of churn. Not one per question.
The reason most enterprise AI produces numbers nobody trusts is not the model. It is that the model is guessing at meaning. Ask three tools what an active customer is and you get three answers, none of them the one your finance team uses.
We build a semantic layer for your business first: the governed definitions, metrics and relationships that turn a warehouse into something an agent can query without inventing anything. KAL queries through it. When it needs churn, it uses your churn.
That layer is also the reason the audit trail means anything. A query is only checkable if the definitions inside it are the ones your business signed off.
We planted a trap. It found it.
We built a synthetic banking estate to test KAL, and we put a trap in it.
Falling transaction volume is a textbook early warning sign of customer attrition. Every analyst has reached for it. In our data it is worthless.
We asked KAL what predicted attrition. It tested the candidates, reported the ones that held, and ruled this one out, with the comparison it ran and the reasoning recorded underneath.
That is not a lucky run. It is how we test the whole system: cases where we already know the right answer, including the answers built to look plausible and be wrong.
The valuable part of a good data team is not the answers. It is the answers they stop you acting on.
Four things stand between a question and an answer.
It uses your definitions, not its own.
Most AI tools write their own SQL. That means they invent their own version of “active customer” every time you ask, and two people asking the same question get two different numbers. KAL starts somewhere else. Before it queries anything it reads your semantic layer, the governed definitions your business has already agreed, and it uses those. Catching a bad answer matters. Not producing one matters more.
Every claim is a proof, not a paragraph.
When an agent reaches a finding it does not write down what it concluded. It builds a proof: executable code that produces the number, run in a locked-down environment with no route to the outside world. The proof is stored with the finding and has its own address, so anyone can go back to it and run it again.
The numbers in the narrative are bound to the proofs that produced them.
Every figure in your report is a named value published by a proof and referenced by name. The prose cannot drift from the arithmetic, because the prose is reading from it. Anyone who has found a number in a board pack that does not match the appendix will know why that matters.
Assumptions are written down, including the inconvenient ones.
Every finding states the definitions it used and the assumptions it relied on. Where a segment is too small to support a confident rate, it says so. We did not build it to be modest. We built it to be checkable, and being checkable means declaring where you are weak.
And then it is checked.
Each finding is reviewed by an independent AI agent before it reaches you. Because the independent agent is itself a model, we measure it: tested against a large body of cases where the right answer was already known, so its judgement carries a confidence score rather than a promise. Every finding arrives with that score attached.
We will not tell you mistakes are impossible. We will tell you that errors are caught inside the system rather than discovered in a board pack, and that any answer can be taken apart by anyone who wants to.
Read the trust pageEvery answer leaves a map.
Findings are not entries in a log. They are objects. Each one has an address, the question it answers, the proof that produced it, the assumptions it relied on, the values it published and a confidence score. They connect to each other, so an answer is a structure you can walk rather than a document you have to take on trust.
When your risk committee asks how a conclusion was reached, this is the thing you show them.
Your stack stays.
KAL is not another platform to migrate to. Your warehouse, your data platform and your existing tools stay exactly where they are: KAL runs the function around them, the ingestion, engineering, quality, governance and delivery that turn a stack into answers. The tools in your estate give your team a workbench. KAL is the office around it.
No lock in, by design.
KAL is model agnostic. It runs across the major providers and can be directed to use whichever model your requirements demand, including sovereign models or models inside your jurisdiction where regulation calls for them. The choice is yours, not ours: the model layer should never lock you in, or become a compliance risk you inherit.
Where regulation requires it, nothing leaves.
KAL can run the model inside your own environment: your data never leaves it, and no provider is ever in the path. For the buyers who need it, sovereign mode is the difference between a conversation your security team can have and one that never starts.
It starts with the foundation, not the software.
KAL is built to run on a foundation that can carry it, so every engagement starts with the diagnostic: a short, flat fee piece of consulting that maps your data estate and designs the fix. Where the foundations are ready, KAL goes to work. Where they are not, you will know exactly what to fix first, and the plan is yours either way.
How the consulting worksQuestions buyers ask.
Is KAL live today?
Can I trust AI generated SQL?
How are the agents governed?
What does an answer actually contain?
How do we know the write-up matches the analysis?
What if the data is too thin to answer properly?
See it on data like yours.
A discovery call is a conversation with someone senior, no deck, no pitch. Tell us your sector and the questions your business keeps asking its data, and we will show you what KAL does with them.