What Customers Want: Data Gravity

Data Gravity

Data gravity is the pull of owning the business’s most critical data: the data other systems depend on, and the data that’s hardest to migrate (We cover it here in Control Point Patterns).

Customers want their agents to read from and write to their existing data. Agents need input data and context to execute, and outputs and outcomes to get better over time. Securing these critical data sets is your path to independence from the frontier models and to sustainable gross profit.

Input Data

Companies building agents are relearning the old adage: garbage in, garbage out. 

Why build directly on top of Foundation models with the 21% → 95% → 65% accuracy progression we described in The Case for an Application Layer? Why not just build agents on a control point that has already done the work: data transformed, normalized, and organized into a taxonomy the industry understands, with an accuracy the customer already trusts?

Case study: OneStream

Our portfolio company, OneStream, exemplifies this approach. It pulls raw data out of its customers’ ERP, MES, and HR instances and runs it through consolidation, normalization, and a defined financial taxonomy.

“80% accuracy is 0% useful for a highly regulated company or finance in any company. You need the governance to control access, the auditability to trace every number back to its source…

“The enrichment carries judgment, not just math. OneStream can tell an agent that the cash number reads $79 million — and that only 30% of the calculations behind it have run, so don’t publish it yet.” 

– Tom Shea, Co-founder and CEO of OneStream

Context

Control Point incumbents also have critical context that agents need to do their work.

“All of the LLMs are terrible at accounting. They all plateau right around 80% accuracy… They can understand accounting, of course, but they know nothing of any individual business — its location, its industry, its supply chain, its customer base.” 

– Jeff Seibert, CEO of Digits

Where does this context come from? Often industry ontologies and firm-level (your customer’s) taxonomies are encoded in the Control Point’s workflows or Systems of Record. Control Point onboarding often documents firm-level SOPs, who does what, and the edge cases nobody else writes down. 

Proposals can neatly articulate the firm’s experience, offerings, details of the work, personnel, and pricing. 

Client intake and onboarding offerings more deeply capture the needs, attributes, semantics, and workflows of the firm’s customers. 

Ongoing customer support will keep surfacing tribal knowledge, and communications will leave a running record of what the client asked for, what changed, and what got decided.

Outcome Data

Storing outcomes is critical to helping agents get better over time, but it’s also strategic. Knowing the outcome is also strategic. You want to know and demonstrate exactly how your products (software and agents) are impacting business outcomes for your customer. Even if you don’t charge based on outcomes, it’s central to understanding if you’re succeeding and communicating your value to your customer.

Aman Narang, CEO of former portfolio company Toast, described how outcome data comes to life for restaurants on the Q2 2026 earnings call:

“… Over 14 years, we’ve watched good and bad operators run their businesses, so long enough to learn what they do and how the best ones think and adapt. We know what a smart change looks like versus a bad one, when a staffing pattern signals trouble and which pricing moves hold up in a given market. 

“…we plan to build on Toast IQ Grow and roll out a series of agent products on top of our software platform using our data and content advantage.” 

– Aman Narang, CEO of Toast

Data Moats

So far, we’ve discussed why data gravity is important to a System of Action. Here’s how you protect it:

Be the sensor, not the storage

The canonical example is visual AI. A visual AI company is well protected when it owns the cameras and the video feed, because the models can’t access the information the camera collects in the field. It’s far more defensible than owning the storage and analysis step alone. 

Most of you don’t own cameras. You can still be a sensor: the place where data first gets captured from the real world.

Here are some ways to be a sensor: 

Define the output.

If your product defines what finished work looks like (the form, report, or record that marks a job as done), every completed job flows back through you. You’re the only party who sees the output, and the only one who gets to judge whether it was right. 

Entwine the data in the workflow.

Data generated as a byproduct of the work rather than collected as a project creates a moat that others can’t access.

“We’re not only reading data (from the EHR), but we’re also creating new-new data that didn’t exist before!” 

– Jeff Liu, CEO of Assort Health

Perhaps the most valuable sensor is the write path. When you are the system that writes to the record, whatever gets written is, by definition, the real thing. Own the write path, and you own the outcome. Own the outcome, and you own the learning loop.

Build domain depth.  

Domain depth lives in industry ontologies and firm-level taxonomies. Make both dynamic so they keep pace with the workflows: ontologies for the industry’s products, processes, and people; taxonomies for each customer’s own codes and fields; plus the domain calculations, the logic, and the formats.

This is the layer that makes your data legible to an agent in the language your customers use, and it is tough and slow for new entrants to reconstruct.

“The taxonomy is rigid in a way, but it’s always evolving as we add new workflows… Every time you make an association, it compounds. You start with a single type of document. Suddenly you have five types. Suddenly you have 15 types with 26 subtypes underneath….” “(You start with one taxonomy, but) later, as the litigation evolves, suddenly you learn that for this particular type of case, the kidney cancer isn’t eligible by itself — it has to have originated from the kidney; you can’t have metastasized from a different place.” 

– AI-native founder

Operational Artifacts 

Better than holding critical data is holding the artifacts that drive the answer and trigger action. 

The artifact is how your customer thinks about her business, and it gives her all she needs to make a decision. A contractor runs her jobs off the WIP report (see the Adaptive case study below). The strongest artifacts become the standards the whole industry acts against. Banks lend on FICO scores from Fair Isaac. CPG marketers buy TV against GRPs. Hotel managers are compensated on RevPAR targets. Each of those started as a byproduct of operations and became an industry standard. Once you are the industry metric, the trust loop runs in your favor and is hard to interrupt.

The Scoreboard.

One sneaky-important Operational Artifact is the Scoreboard, the measure by which a business understands the success of a job and your contribution. If you and your customer agree on how value is calculated, you have an open path to sell additional agents and workflows that put points on that Scoreboard.

Create a System of Record that doesn’t exist.  

Sometimes the System of Record for a job doesn’t exist. The job may start small and depend on data and calculations spread across several Systems of Record, or on data nobody has digitized. Getting it right may require subjectivity, reasoning, or collaboration among multiple personas, all challenging to automate before generative AI. 

If you can aggregate, digitize, and normalize it, you create a System of Record that never existed.

Build the subledgers and schedules that carry the operational detail an agent needs to act. Do that for several small but critical jobs, and you build formidable gravity.

Case study: Adaptive

Our portfolio company Adaptive is doing this in construction right now. 

Construction accounting is a deeply collaborative job between the field and the back office. Accountants can’t get work done without understanding the current story of what’s happening on site. Every company has a general ledger (GL), but the GL only stores numbers. It has no capacity to capture the unstructured story of a project. So accountants spend most of their time outside the GL, collecting the latest project context, then manually updating the numbers in the GL.

Adaptive pulls in the unstructured project context scattered across email, texts, and project management tools, and does the accounting work on top of it. It started with job costing (agents assigning costs to the right job, cost code, and cost type) and has expanded into WIP reporting, billings, change orders, and contracting. All run on the same mechanism: ingest the project context, understand how it connects to the financials, and act. The story of a project, which the numbers depend on, now sits in a System of Record for the first time.