Organizations still struggle to strike a balance between getting fast data and getting reliable data, and I’ve seen this tackled from both sides.
When we built Fabi.ai, we chose not to build a semantic layer because our customers wanted to start fast. We set out to deliver answers the day we connected their data, and we thought a semantic layer meant weeks of setup before anyone could ask their first question.
Since joining Omni, I’ve realized this isn't the case. Customers of every size solve this problem without making sacrifices. A semantic layer and agent harness make answers more reliable and efficient. But the real value is in capturing organizational knowledge without slowing down. Nailing this workflow makes Omni's semantic layer good.
The duality between speed and reliability is what Omni was designed around. Two ideas hold the design together. The first is just-in-time data modeling, and the second is our philosophy of meeting users where they are.
This hasn’t changed. What’s new is how people get to their data.
More and more of our users are interacting through AI. Meaning, meeting users where they are increasingly means in a chat in Omni or another connected tool. Until now, you couldn't do data modeling from those interfaces. When you turned up a definition worth keeping in a chat, you had to open the modeling IDE to review and push changes. Our agent, Blobby, could always help with this work once you were there. Now Blobby can accomplish all of this, within the same thread without disrupting your investigation or leaving your chat window.
Our two core principles #
Just-in-time data modeling #
Chris Merrick describes our concept of just-in-time modeling in this 2024 post. It borrows from software’s just-in-time compiler, which compiles only the code a task needs instead of the whole application. Omni applies the same idea to data.
In software engineering, this enables much more efficient resource usage. Efficiency gains hold true for data engineering as well, but the practice provides a much deeper benefit.
Just-in-time modelling combines the technical task of modelling data and the exploratory task of finding new information or meaning in it. Combining these tasks and providing ways to easily contribute this work back to a governed model is how you balance speed and reliability.
Meeting users where they are #
The feedback loop from data consumer to data model is a core reason why it’s so important to meet people where they are. At first, that meant drag-and-drop interfaces, Excel-like spreadsheets, or code. Now it includes AI agents. An interesting by-product of this rise in AI is that more people, regardless of tool, are practicing just-in-time data modelling, most without realizing it. Think about the last time you asked an agent a new question: Did it faithfully follow your curated context and well-defined rules? Did you contribute your findings back for reuse?
If you’ve tried this, one thing becomes clear quite quickly: without enforced guardrails, the agentic approach and workflow for change management lead to metric drift and data chaos.
This puts specific demands on the analytics platform.
First: an easy way to explore and contribute work back to the governed model. If this isn't easy, users build extracts and workarounds, and the organization loses out on the work users have done and the business context they can contribute.
Second: a review flow, so a flood of AI-generated definitions doesn’t fill the model with conflicting logic.
How our architecture enables this workflow #
Omni’s model has four layers:
the raw database (raw tables and schemas)
an in-database model (derived tables and views your team builds in the warehouse)
the governed model (shared semantics and context)
an ad hoc workbook environment
The workbook layer is where just-in-time modeling happens safely. You can explore and model data without touching anyone else’s.
When you find something useful, you promote it into the governed model, where it becomes a shared metric on a branch from Omni, directly tied to git. After review and promotion, it’s included in the governed layer as a definition that everyone, including AI, queries the same way.
The governed layer keeps answers consistent and avoids metric drift. It holds metric definitions, join paths, and access controls. Critically, this is also the layer where definitions from different places meet. Our governed model can read definitions from other tools, such as dbt, Snowflake, or Databricks. Users in Omni interact with and even enhance them through the practice of just-in-time data modelling, ultimately syncing changes back to any of these Systems.
An efficient review process is what keeps the model clean and up to date over time. Omni stores the model in git as code. It lets you create and manage git branches so you can change the model without touching production. A finished branch becomes a pull request.
This puts Omni inside the review and promotion process teams already run, with the same approvers, branch protection rules, and a full history of who changed what. An expert approves a definition before it becomes part of the governed model, so a flood of AI-generated logic never lands there unreviewed.
Omni extends this speed, governance, and review process to users throughout your organization with many interfaces to choose from. Workbooks combine point-and-click exploration, spreadsheet-style calculations, and a SQL IDE. Blobby handles conversational questions, and the model IDE and Omni CLI are there for people who prefer code. Omni’s MCP server connects to Claude, ChatGPT, Cursor, and VS Code, and the IDE plugins support Cursor, Claude Code, and Codex.
Every one of these surfaces draws on the same definitions and review path.
Each of these is a way in and a way back. A metric can start as a spreadsheet formula, a question to Blobby, or a line of SQL, and end up as the same reviewed definition in the governed model. That loop, from the person asking the question to the model that answers it, is what balances getting fast data and getting reliable data.
What’s new: Giving Blobby more promotion power #
Promoting from a workbook isn’t new to Omni, but we’ve made it easier from more places.
Among the largest technical blockers we’ve been working to remove is allowing Blobby to open and manage the PR process. Initially, we’re rolling this workflow out to users who already have permissions to promote changes and update the governed model, making contribution faster and easier. Specifically, Blobby can now:
Choose individual changes for promotion: Review your workbook’s changes, pick the calculations, fields, and joins worth keeping, and promote them to the shared model. Ditch the rest.
Promote from workbook: You stay in the workbook while Blobby does the modeling. Add joins, fields, and promote them without being pulled into the IDE.
Save definition from AI Chat: When a new definition comes up in a conversation with Blobby, ask Blobby to save it. Blobby creates the branch, so the change goes through review.
Here is an example of why this matters:
A sales leader wants to know if new or returning customers are driving sales. They start by asking Blobby. Blobby creates a new metric and joins the tables needed, all in their personal workbook layer.
This new metric turns out to be a definition the whole team wanted. So, they ask Blobby to save it, and Blobby opens a branch with just the changes to push. The changes go through the standard git review process. And once it merges, the whole team can get the same answer.
Where we’re taking the product next #
While this initial rollout focuses on team members with existing promotion privileges, where the approval process is most straightforward, our vision extends much further.
Every user, regardless of technical ability, should be able to work with data and contribute what they learn back to the shared model for reuse. AI makes this possible. But it also creates more work than any person can wade through. If AI can explore but can’t take part in modeling and review, you can’t keep up with what it generates. AI has to participate in the review flow.
We are building towards a solution where Blobby proactively initiates this workflow.
Rather than waiting for a prompt, Blobby will identify new metrics and changes you’ve made to the model automatically and suggest promoting them through the review pipeline to ensure valuable insights aren't lost. Part of this is possible today as Omni leverages conversational feedback to refine the AI context Omni associates with every field. But agents can help define much more than just context. We will expand this automated feedback loop across all fields within Omni and the broader semantic layer.
We also want contribution from everyone across the organization. Domain experts, like financial analysts who manage specialized accounting processes, should be empowered to propose model updates directly through this same governed review framework without getting into the weeds. Data administrators keep final authority over the governed layer and gain collaboration from the subject matter experts nearest to the business. It creates a context engine that truly improves through use.
I’ve seen organizations adopt Omni at every level of analytical maturity, ranging from greenfield deployments to sophisticated, pre-existing semantic architectures. If you’re starting from scratch, you can explore in a workbook from day one, and the model grows from the questions people actually ask. If you already have a mature model, Omni reads definitions from sources like dbt, Snowflake, and Databricks so you build on that work instead of redoing it.
Either way, you don’t have to model everything first. Omni grows with you as your needs shift. Start with the few metrics your team argues about most, and let the rest come just in time.
