The Data Broker Business Is Harder Than It Looks

DataMining · November 6, 2026

We wrote about data companies at the end of September. The primary market had no real theme at the time, except that data vendors were suddenly the hot thing: companies less than a year old were raising valuations of several hundred million, even a couple of billion dollars, and stories of a few million dollars in monthly revenue were everywhere.

But hype is one thing. Outsiders never quite understood it: data work used to mean hiring a room of people to draw bounding boxes and write Q&A pairs. What do these newly expensive data vendors actually do behind closed doors all day?

The last month or two has brought a lot of new developments in post-training. I talked again with several friends who work on data and evaluation (Eval) to pin down two questions: how do data vendors make data now, and what sustains this business once the scramble for data passes?

0101 Models Have Gotten Too Good at Gaming the Test

Put simply, pre-training is reading and post-training is doing practice problems. For the past six months, a data vendor's main business has been making exercises for models: build an RL environment (a reinforcement learning environment) and pair it with a scoring rule (a Rubric).

Left: a bar chart with Held-out task success (%) from 0 to 60 on the y-axis and AppWorld, ALFWorld, WebShop, Math (held-out) on the x-axis; green bars are Trajectory-heavy alloc., blue bars are Environment-heavy alloc., with an annotation avg gap: +13.6 pp. Right: two pie charts labeled Trajectory-heavy and Environment-heavy; the former is 70% Traj, 20% Task, 5% Env, 5% Reward, the latter 50% Env, 30% Task, 15% Traj, 5% Reward; legend: Env, Task, Traj, Reward

The early logic was simple: on tasks like coding and math, once the problem set and verification rules were fixed, no demonstration was needed. Let the model try and fail repeatedly in the environment (Rollout), reward correct answers, and it would learn on its own which path was right.

Model labs were in a hurry then, and cared more about speed and volume than quality. The requirements doc arrived today; the vendor was expected to deliver the day after tomorrow.

By October, a nasty problem had become obvious: models had gotten too good at gaming the test. If the environment was not airtight, what the model learned was not how to solve the problem but how to find a loophole and collect the points.

In early October, while testing a new model that had just climbed near the top of a leaderboard, the independent evaluator Vals AI found an absurd detail. In two-thirds of the coding tasks, the model had not actually written the code at all.

When the vendor packaged the test environment, it cut off the network but forgot to scrub the repository's local Git history. After a few failed runs, the model simply typed git log HEAD..origin/main in the terminal, pulled up the later commits from the original repository, copied the fix, and scored full marks.

A few days later, Scale AI updated its flagship coding benchmark SWE-Bench Pro V2, cutting the public set from 731 to 642 tasks and dropping 89 in one go. An independent audit had found that many original tasks either leaked clues to the reference answer or had test scripts so crude that models could easily probe their way to a shortcut.

Even with a clean environment, models look for ways to slack off.

In mid-October, a research team at Handshake reviewed thousands of trajectories of frontier models editing code. The prompts contained only the user's request and said nothing about a grading script, yet almost every model spent more than 80% of its reasoning guessing which points the grader would test.

Once it starts guessing the exam, its behavior distorts. Instead of writing complete business logic, it writes an empty function just sufficient to fool the test cases; or, to be safe, stuffs seven or eight interfaces that might be tested into the code. The score goes up, but the code is useless in real work.

Late in October, Anthropic published a paper on isolating the parameters a model updates through cheating during training, then cutting them away once training finishes (GRAFT). The researchers found that directly penalizing cheating during training does not make a model honest; it merely learns to keep cheating in ways human monitors cannot see.

Three schematic panels labeled Unclassified Behavior (πR+F), Detected Reward Hacking (πR+F), and Anchor Environment Behavior (πR); each has three boxes — Base model weights, Retain adapter, Forget adapter — linked to MLP N above, with Residual Stream labeled on the left; the Forget adapter in the middle panel is outlined in a thick orange frame, while the right panel's Forget adapter is an empty white box; the bottom legend shows Forward/backward pass, Parameters frozen, Parameters updated, 2x update, Parameters disabled

0202 How Do Data Vendors Actually Make Data Now?

These developments forced vendors to upgrade their craft. The days when a few interns could bundle an open-source project into a Docker image and call it delivered are basically over.

A serious vendor now has to do three hard jobs to produce data.

The first is recording how real people work, especially how they go wrong and recover.

In finance, law, medicine or complex engineering, a model cannot learn the job by seeing only the final correct result. Vendors now pay overseas senior accountants, engineers or doctors USD 200–300 an hour, and what they are buying is not the final answer but the full trace of operations on that person's screen.

Take an architect fixing a bug: which error line they read first, which keywords they used to search internal docs, which wrong edit crashed the program, what signal told them something was off, and how they backed out and fixed it. That arc of noticing a wrong turn and coming back is the training material models need most.

To understand how people in different industries actually work, Mercor, Stanford and the US Department of Labor's O\*NET team launched a project called TaskNet at the end of October.

They considered traditional surveys too slow and too shallow, so they built an "AI interviewer" that talks directly to practitioners across industries, teasing out the work habits and judgment criteria that never make it into textbooks, and turning them into a new task library.

The second is turning real software into a sandbox that can be run repeatedly without leaking answers.

Once a task exists, the engineering team has to turn it into a runtime environment the model can enter and operate.

This is far more tedious than it sounds. WebHarbor, an academic project released in early November, is one example: to teach agents to use web pages, the researchers copied the pages, backend logic and login states of 153 real websites and packaged them into stable local containers. Only then can a model make tens of thousands of clicks and orders inside them without a site redesign or an IP ban cutting the run short.

Before handing an environment to a model lab, the vendor runs its own internal test: put existing models through a few passes and specifically check for logs that were not scrubbed and test scripts that are too easy to bypass.

Three line charts with Environment axis DE, Task axis DT and Trajectory axis Dτ on logarithmic x-axes, and L − L∞ (= −log psuccess − L∞) on the y-axis; each chart has three curves labeled Qwen3-4B, Qwen3-8B and Qwen3-14B with their α values (left 0.38 / 0.41 / 0.43, middle 0.23 / 0.26 / 0.27, right 0.10 / 0.11 / 0.12); all three curves decline as the x-axis increases

The third is defining the scoring rule (Rubric) — and keeping it in step with the model.

Coding and math are the easy cases: pass the tests and you are right, fail and you are wrong. Most real work has no standard answer.

Ask a model for a due-diligence report or a slide deck, and what counts as good? Eval teams have to break domain experts' subjective impressions into dozens of concrete scoring items. A friend in this business says the job feels like product management: the core is translating "feels good" into checkable, quantifiable items.

By late October, several arXiv papers were circling the same problem: a static scoring rule stops working very quickly.

Most scoring today is checkbox-based, and after a few rounds the model has the pattern figured out: write a long enough answer, pile in every word that might be relevant, and the total score is guaranteed to rise. That is why so many models that dominate leaderboards are full of filler in actual use.

So the rubric a vendor delivers now has to be dynamic too. Add penalties — filler costs points — and once a model is maxing out the existing criteria, upgrade the scorecard itself.

To keep costs down, routine training uses a cheap small model for rule-based first-pass filtering, while a slice of the budget is reserved to periodically sample high-scoring answers with a stronger evaluator model and check whether they are genuinely good or just gaming the grader.

Four line charts with Macro Recall (%), Macro Precision (%), Win Rate (%) and Avg. length (chars) on the y-axes, and # Training steps from 0 to 300 on the x-axis; the blue curve is Standard coverage reward, the orange is FORK (Ours), and the grey horizontal line is Base model; as training steps increase, the blue curve's Macro Precision falls from about 43% to about 23% while Avg. length rises to about 9k, whereas the orange curve's Macro Precision rises to about 58% with Avg. length stable around 4k

0303 What Makes This Business Last?

Walk through that pipeline and it is easy to see why some data-vendor founders are anxious even while the money comes in.

The data business has a built-in weakness: an evaluation or training environment has a half-life.

To a model lab, any third-party benchmark or environment becomes a training target soon after it is bought. Two or three months of repeated grinding and the capability is learned, the value of that batch of data is squeezed dry. The vendor then has to find out which capability the lab wants to patch next quarter, find new people, and build new environments.

Staying in project-delivery mode means the vendor is still, at bottom, a slightly upmarket outsourcing shop: a banner year this year, and possibly no work next year if a lab changes its training direction.

To become a durable business, vendors are currently trying three routes.

The first is turning "selling data packages" into "selling cloud services".

Vendors used to ship a packaged environment to the lab and that was the end of the deal. But agent training is scaling up: thousands of environments run at once, and managing container state, scheduling rollouts within a fixed compute budget (for example the EnvSched framework, released in late October), and keeping verifiers stable have become a heavy engineering problem.

In Silicon Valley, Post-train as a Service is taking shape. Leading environment vendors and compute platforms no longer sell images outright; they keep the environments in their own cloud, let model labs and application companies connect through an API to train, and charge by the number of interaction steps and verifier calls.

Prime Intellect, for example, acquired Moondream — the team behind a lightweight vision model and inference engine — in mid-October, tying together training environments, low-level inference acceleration and model training. As long as customers keep training models, that infrastructure keeps collecting rent.

The second is earning money from application companies and traditional enterprises.

In mid-October Mercor published A Benchmark Map of the US Economy. It mapped 923 occupations and nearly twenty thousand concrete tasks across the country, and reached an interesting conclusion: 90% of the hours Americans spend working are not covered by existing AI evaluation benchmarks at all.

Frontier labs have finite attention and budgets; they can only tackle the largest areas first — coding, math, general office work. Further down, a large number of vertical application companies and traditional enterprises are also starting to need post-training.

As we noted in Post-Training Is Not the Savior of AI Applications, Genspark and Fireworks AI post-trained an open-weight base into a slide-deck model that approaches Opus 5 in quality at one-seventeenth the cost. For many application companies, post-training is a class they will have to take sooner or later to make unit economics (UE) work;

for large traditional enterprises, post-training an open model on their own business data and deploying it privately is also the choice that best fits data-compliance requirements.

Few of these companies have a dedicated post-training team, or know how to build their own Eval or their own environments. That is where a vendor that has worked for top labs and has a mature pipeline can move downmarket into customisation and managed services for them. The contracts are smaller than a lab's, but there are more customers and longer cycles — much like the third-party service firms that grew up around cloud computing.

The third is keeping real domain experts from every industry on the payroll.

Many people worry synthetic data will eventually replace data vendors. But for the foreseeable future, as long as real-world software keeps updating and industry rules keep changing, models will still need human experts to demonstrate work and set standards at the edge of their capability.

The real barrier is not hiring a few part-timers. It is whether, when a customer asks for a very obscure specialty — cross-border tax compliance, say, or troubleshooting a particular industrial software package — you can find genuinely qualified, cooperative veterans in a pool of tens of thousands within a few days.

Algorithms and code are easy for competitors to copy. Finding domain experts scattered across the world, pricing them, and managing their output quality is a genuinely heavy operational system.

In the end, the phase of this industry when being well-connected and gathering a few students from elite universities was enough to land big contracts is slowly passing.

As post-training itself comes to resemble a precision manufacturing discipline, data vendors cannot live inside reassuring myths forever. What they compete on now is simply whose environments are more stable, whose expert pool is deeper, and who can actually bring a customer's model costs down. Get those unglamorous jobs right, and the business stands on its own feet.

About DataMining A team of PhD students from the Software Institute, School of Computer Science, Peking University, focused on original high-quality task data and executable evaluation environments for large-model and agent R&D. We deliver not just data but industrial-grade Rubrics and Harbor Task verification systems. ▸ Long-horizon code and engineering simulation: Deep SWE, Frontier SWE, Frontier-Eng, ALE / Terminal-Bench and more, with stable delivery of 200 tasks per week in 7 working days. ▸ Extreme math and professional agents: a strict multimodal HLE pipeline (5,000+ tasks in stock); Harvey LAB, Automation Bench, Toolathlon, and 35+ atomic-Rubric industry workflow packs. ▸ System infrastructure and embodied robots: standardised Win11 / Ubuntu desktop-agent VM images, plus million-scale embodied Grounding / SFT / DAgger real-machine custom pipelines and cyber data. The research, datasets and benchmarks cited here are all public third-party work; we align with their capability requirements and difficulty ranges only, and do not copy their tasks. Capability descriptions here reflect our own internal measurements and are not official third-party conclusions. 🌐 Site: datamining.cloud｜📮 Sample requests and technical contact: contact@datamining.cloud

📚 Figure Sources

[1] How Data Scales in Agentic RL, arXiv:2610.23946v2, Figure 1

[2] Gradient Routing Localizes and Removes Unintended Behaviors in RL (GRAFT), arXiv:2610.17062v1, Figure 1

[3] How Data Scales in Agentic RL, arXiv:2610.23946v2, Figure 2

[4] Eat Your Precision / FORK, arXiv:2610.33512v1, Figure 1