The Vertical Comes First
Most people building agents start with the agent. They choose a model, connect some tools, write a prompt, and then discover that the model does not know enough about the business to do useful work. So they point it at a warehouse. There it finds hundreds of tables built by different teams, with different definitions, at different grains, and no reliable way to know which answer the company actually believes.
The agent is not missing intelligence. It is missing a world.
Triple Whale arrived at this problem from the other direction. We started before agents were useful. We chose one vertical, ecommerce, and spent years making the whole thing legible to software. Every important source. One canonical schema. The business logic, identities, relationships, and measurements required to understand how a merchant actually works.
That became a data platform operating at a scale few vertical software companies ever reach. Then agents arrived, and we realized we had already built the layer they were missing.
Sabre2 is what happened when we took everything we learned building the data platform for ecommerce and turned the method itself into a product. A native warehouse, an ontology, and an agent harness in one system. The result is simple to say: anyone can begin where we spent years ending.
Vertical
A vertical is not a market segment in a slide deck. It is a complete model of how a kind of business works.
In ecommerce, that model has to understand orders, customers, products, sessions, spend, campaigns, refunds, subscriptions, support tickets, shipments, and customer journeys. It has to know that Shopify, Amazon, Meta, Google, TikTok, Klaviyo, Recharge, Gorgias, and ShipStation are describing different parts of the same company.
Most software companies choose one slice. The ad platform knows ads. The store platform knows orders. The email platform knows messages. The warehouse stores whatever the customer sends it. The merchant is left to assemble the business in the space between them.
We chose the whole vertical.
Triple Whale was the first company to take a complete modern commercial vertical and build one industry-wide data model for it at scale. Not a schema for each customer. A schema for ecommerce itself, which every merchant inherits when they connect.
This sounds like a data architecture decision. It was really a product decision. Once the business has a shared grammar, every application above it can begin with meaning instead of files.
Schema
Every source system has its own opinion about reality. Shopify and Amazon settle revenue differently. Meta and Google report spend on different clocks. Subscription tools think in billing cycles. Support tools think in tickets. Shipping tools think in packages.
None of them is lying. They are answering different questions.
A useful data platform has to preserve what each source says while creating a stable set of business objects above them. An order has a grain. A customer has an identity. A product belongs to a catalog. A campaign spends money over time. Refunds change the economics of an order without erasing the order. Relationships and definitions have to survive all of this.
That is what the schema contains: not just columns, but the accumulated decisions required to make the business coherent. Which object owns the truth. How entities join. What changes over time. Which metrics are canonical and which are modeled explanations.
A generic warehouse gives you storage. A vertical data platform gives you meaning.
This is why the work compounds. Every connector improves more than ingestion. It teaches the model another way the real world refuses to fit neatly into a table.
Scale
A schema drawn on a whiteboard is easy. A schema that survives Black Friday, partial refunds, exchange orders, subscription renewals, delayed settlements, multiple currencies, changing APIs, and millions of customers is something else.
Triple Whale’s platform scans on the order of fourteen trillion rows a day and tracks more than $100 billion of GMV a year. Those numbers sound like bragging. They are really a description of the test suite. Scale teaches the schema where the theory breaks.
It also forced us to solve a problem that becomes important later for agents. The warehouse had to be broad enough for someone to ask a question we had not anticipated, but bounded enough that the question could not break the system or silently redefine the business.
Dashboards fail the first test. Raw warehouses fail the second.
So we built the governed middle: curated tables, known grain, typed functions, stable joins, source-aware definitions, and measurement anchored to the same underlying truth. We did it so a merchant could answer hard questions without first hiring a data team.
In retrospect, we were also making the business safe for a machine to read. A warehouse that is safe to hand an intern is a warehouse that is safe to hand an agent.
We modeled one vertical. Sabre2 turns the method into infrastructure.
Abstraction
Sabre2 came from looking at everything we had built for ecommerce and asking which parts belonged to commerce and which parts belonged to the act of making any business legible.
The commerce objects were specific: orders, customers, products, spend, and journeys. The method was general: connect messy sources, discover their shape, resolve entities, infer relationships, preserve history, encode business rules, orchestrate pipelines, and expose the result through a governed data layer.
Sabre2 is the abstraction of that method.
This distinction matters. We did not take the ecommerce schema and rename its tables until it looked generic. We took the machinery that let us build and operate that schema, then made the machinery capable of organizing new domains.
That changes the starting point. Before, building something like Triple Whale meant spending years on connectors, pipelines, identity, modeling, governance, and warehouse operations before the first intelligent application could be trusted. With Sabre2, the accumulated method becomes infrastructure.
Ecommerce is the first and deepest proof. It is no longer the boundary.
Warehouse
Most agents borrow context at the moment they need it. They search a document, inspect a screen, call an API, or generate a query against a warehouse someone else designed. This can produce an answer. It does not produce a stable understanding of the business.
A model’s context window is temporary. A warehouse is the memory the business can audit.
That is why the warehouse is native in Sabre2 rather than attached later. Ingestion, schema, ontology, SQL access, permissions, and execution live in one system. The warehouse is fully managed and designed for AI access, but the important word is native.
Native means the agent does not meet the company as a pile of unfamiliar tables every time it wakes up. It inherits known business objects, stable definitions, current state, and the boundaries governing what it may read or change.
As new data arrives, the context changes with it. As actions happen, their results flow back into the same system. The data layer and the action layer can become one loop instead of two products connected by a brittle handoff.
Moby meets your data where it already lives.
Connect Snowflake, BigQuery, Amazon Redshift, Databricks, Microsoft Fabric, or PostgreSQL through the same governed context layer, so Moby can reason and act from the systems your team already trusts.
Moby is built on the same production foundation proven across more than $100 billion in GMV.
Agents
Large language models are surprisingly good at reasoning and surprisingly helpless around a business they cannot read. Give a model access to a browser and it can click. Give it a pile of tables and it can write plausible SQL. Neither means it understands the company.
Suppose an agent is asked whether to increase a campaign budget. It needs to know the campaign, current spend, customer economics, contribution margin, recent changes, inventory constraints, the company’s target, and whether it is allowed to act. It also needs to know which definitions the company trusts and what happened after the last change.
The language model is only one part of that system. The rest is context and control: shared business objects, tools, permissions, memory, approvals, logs, and a loop that can plan, act, and verify.
This is why the data stack and the agent stack are becoming the same stack. An agent should not translate the business from scratch every time it wakes up. It should inherit a living model of the business, query the same truth the team uses, and operate inside explicit boundaries.
Once that foundation exists, anyone can build what we built without first becoming a data platform company. A media buyer can inherit the economics of an account. A merchandising agent can understand products, inventory, and demand. A support agent can know the customer, the order, and the promise that was made. New agents can be built around outcomes instead of integrations.
There is a limit to the phrase “anything with agents.” An agent can only do what its data, tools, and permissions support. That is precisely why the data platform matters. It makes those boundaries explicit and buildable.
People will see the agents at the top and assume the agent is the invention. It is only the visible floor. The hard part was turning a business into a world software could understand.
We started by building the data platform for one vertical. Sabre2 turns that work into a way to give any agent a world.
The vertical came first. That is why the agent can come next.