The Internet's Data Is Nearly Exhausted—Your Workflow Is AI's Next Mine
Deep thoughts on AI and aspirations —— ByteDance Deep Thinking Circle
The data business keeps turning the page. During the self-driving and early large model era, Scale AI made its first fortune on data labeling; when training shifted toward expert data, companies like Mercor and Surge followed; now demand has changed form again—model labs are circling something new: data generated from real enterprise workflows. Public internet data has been repeatedly mined out. This vein has barely been touched.
Why now? The answer lies in the main thread of model progress.
Tasks Got Longer, Sandboxes Can’t Keep Up
The keyword for this generation’s model competition is long-horizon tasks. The unit of work models handle is expanding from a single code change to an entire file, a whole codebase, and ultimately a complete project.
The longer the task, the harder it is to manually construct an environment. Real projects are full of historical state, tool dependencies, organizational rules, and unexpected branches. In a codebase that’s been running for eight years, which modules no one dares touch, which processes can’t bypass approval—experts sitting in sandboxes can’t conjure these details out of thin air. Lab budgets have thus shifted from expert labeling to reinforcement learning environments, and now to real-world data procurement.
This market also has a structural mismatch. Model companies typically have many engineers and little data; enterprises are the opposite—lots of data, few people who understand training. This mismatch creates two types of businesses: one supplies data to labs, the other transforms enterprise business processes into trainable environments and sells training consulting along the way.
Good Data Has One Standard: Right at the Capability Boundary
There are two kinds of data. One is captured from real work, close to a recording of the work process—screen operations, collaboration records. The best version even reconstructs the intent behind actions. GitHub exemplifies this data type: commit messages, issues, and solutions threaded together, the entire journey from problem appearance to resolution. The other is artificially constructed—find experts, design tasks, execute in sandboxes, collect results. Constructed data suits early capability ramp-up, but as models begin handling longer chains and higher economic value tasks, real data becomes increasingly valuable.
There’s a counterintuitive evaluation criterion here. Many teams design tasks with the logic that creating something the model can’t do presents an opportunity. But making frontier models fail isn’t hard at all—what’s hard is getting the task right at the capability boundary. A task where the model doesn’t get it right the first time, allowed thirty-two independent attempts with a 30% success rate, indicates it’s occasionally finding the path but unstable—this data has training value. Another task, two hundred fifty-six attempts without a single success, is likely beyond scope or too niche, feeding it in won’t help it learn. Picking data isn’t about picking the hardest, it’s about picking what’s just within reach.
The market is booming, and the pitfalls are systemic. Several types of data corruption circulating in the industry are worth remembering: packaging constructed data as real data; deliberately increasing difficulty in evaluation sets to create the illusion that models still have much room for improvement; quality control relying on piling up manpower, quality collapses when scale increases. My experience is that looking at a data company’s hiring structure reveals its DNA: frequently hiring project managers means it’s selling manpower to fulfill orders; only hiring engineers means it’s building a factory. As data value migrates toward the real end, pure constructed data companies may only have a two-year window left.
Should Your Company Train Its Own Model
When workflows become training data, enterprises naturally wonder: should we do it ourselves? There’s plenty of discussion in Silicon Valley, but those who actually commit have specific reasons.
Customer service companies were among the first to develop in-house. General models are trained to be friendly and compliant, but enterprises don’t want models to accommodate every refund request—this preference can’t be solved with prompts. Another reason is cost: if a coding tool company buys models at external API prices, every new user acquired means paying a toll to competitors, who use that money to subsidize their own products. Training in-house to 80-90% of frontier model capability at 10-20% of the cost levels the playing field in perceived competitiveness.
But self-training is essentially trading one-time capital expenditure for long-term inference costs. Whether this calculation works depends on four multipliers: data uniqueness, times evaluation clarity, times task frequency, times single improvement value. If any multiplier approaches zero, the investment doesn’t hold.
| Multiplier | What It Determines | What Zero Looks Like |
|---|---|---|
| Data Uniqueness | Whether general models can learn it | Data is just messy, not unique |
| Evaluation Clarity | Whether training can steadily optimize | Engineering with no acceptance criteria |
| Task Frequency | Whether costs can be amortized | Capability used twice a year |
| Single Improvement Value | The ceiling on returns | Savings amount to pocket change |
A positive case is food delivery platform menu entry. Over 100,000 merchants onboard annually, uploading menu images. The system must convert image information into electronic menus according to internal platform rules—items, add-ons, specifications each have their own standards. General models recognize menus but don’t understand this internal ruleset, so the platform used internal data and external vendors to train a small model that understands its business standards. All four multipliers positive—the calculation works.
Self-training has a hidden advantage. Companies occupying real workflow entry points naturally produce high-quality agent execution trajectories—this type of data can be priced at thousands of dollars per instance in external markets. Plus, enterprise task scope is narrow, no need to worry about cross-domain generalization, making capital efficiency actually higher. General labs doing coding reinforcement learning must be careful not to regress other skills; vertical companies don’t have this burden.
The Boundaries of This Business Need to Be Clear Too
Three sober judgments.
First, the data market is a wave-riding business. Whenever a capability bottleneck is broken, the most valuable data changes form, and players turn the page with it. If last round’s winners bet wrong on the next round’s demand type, moats instantly become sunk costs. When valuing data companies, don’t value by assets—value by window period.
Second, enterprises generally overestimate their data uniqueness. Most so-called unique data’s problem is messiness, not uniqueness: inconsistent standards, unrecorded processes, unclear permissions. Among the four multipliers, what goes to zero first is often not uniqueness, but evaluation clarity—tasks where “done well” can’t even be defined make training impossible; no matter how much data, it’s just raw material piled up.
Third, this is an exchange with implicit conditions. Enterprises hand over workflow details in exchange for model capabilities or better services—data sovereignty and boundaries are worth spelling out in contracts. The more valuable your process data, the more you should clarify what you’re getting in return.
For entrepreneurs, the criterion is simple: data companies without a roadmap toward real data aren’t worth investing in or building. For enterprises, calculate the four multipliers first. If the math doesn’t work, don’t touch training—treat data as a negotiable asset to exchange for better model services. The best position is always the party occupying the workflow entry point. The mine is in your ground; mining methods can be negotiated slowly.
Key Points: Long-horizon tasks make real workflow data the new scarce resource; mismatch at both ends of the data market spawns two types of companies—data suppliers and environment builders; good data sits at model capability boundaries, too hard or too easy has no value; enterprise self-training depends on four multipliers—data uniqueness, evaluation clarity, task frequency, single improvement value; value data businesses by window period, uniqueness is often overestimated, evaluation clarity most often absent; occupying workflow entry points is the best structural position.