RL environments: why AI labs pay for real company workflows

An RL (reinforcement learning) environment is a sandbox where an AI model attempts a task with a fixed set of actions, and an automatic grader scores each attempt so the scores can update the model. For agents meant to do office work, the sandbox is a working copy of business software, filled with records, plus tasks that have a known correct outcome. AI labs pay for real company workflow records because those records make the copy realistic and the grader hard to fool.

If you have written integration tests, you already understand most of this. The rest of this post covers what an environment contains, what one episode looks like as data, what environments cost to build, and which records from an ordinary company are useful.

What is inside an RL environment?

Four things: a starting state, an action space, a task and a grader. Epoch AI, which interviewed 18 people across environment startups and labs for a January 2026 FAQ, describes each task as a prompt with an objective, scored by a grader that is "typically automated, such as a unit test or an LLM judging against a rubric." It adds that environments are often delivered as Docker containers.

The examples in this table are illustrative:

Public research environments follow the same pattern. SWE-bench built 2,294 tasks from real GitHub issues and the pull requests that resolved them, across 12 Python repositories. tau-bench puts an agent in a customer-service setting and grades it by comparing the database at the end of the conversation with an annotated goal state.

What does one episode look like as data?

An episode is one attempt at one task: the starting state, every action and observation in order, and the reward at the end. If you have used Gymnasium, the loop is familiar. reset() returns the first observation, and each step(action) returns the next observation, a reward, terminated, truncated and an info dict.

For an office agent the observation is usually text or a screenshot, the action is a tool call, and the reward usually arrives once, at the end. Here is an illustrative episode record for a task built from a resolved support ticket. The field names are ours, not a standard.

{ "task_id": "refund-4812", "instruction": "Customer reports a double charge on order 99173. Resolve per refund policy v3.", "initial_state": "snapshots/crm-2024-03-11.sql", "steps": [ {"t": 0, "action": {"tool": "search_orders", "args": {"order_id": "99173"}}, "observation": "2 charges of $48.00 on 2024-03-09"}, {"t": 1, "action": {"tool": "issue_refund", "args": {"charge_id": "ch_2", "amount": 48.00}}, "observation": "refund pending"}, {"t": 2, "action": {"tool": "reply", "args": {"text": "We refunded the duplicate charge."}}, "observation": "sent"} ], "reward": 1.0, "terminated": true, "truncated": false } 

The grader for a task like this can be a few lines. In the tau-bench style, it compares the end state with the state the real support agent reached:

def grade(final_db: dict, goal_db: dict, keys=("refunds", "order_status")) -> float: """Return 1.0 only if every graded table matches the recorded outcome.""" return float(all(final_db.get(k) == goal_db.get(k) for k in keys)) 

The goal state is the expensive part, because someone has to know what "correct" was. In a real company's records it is already written down: the ticket was refunded, the invoice was approved, the pull request merged and the tests passed.

Why do labs need real company records?

Because a grader is only as good as the tasks behind it. Epoch AI's interviewees named reward hacking, a model finding a way to score without solving the task, as a top quality concern. One said that high reward "must mean the task was actually solved." Synthetic tasks written in an afternoon tend to be tidy and guessable. Real records carry the partial refunds, escalations and reversed decisions that make a task hard to game.

The same interviews describe enterprise workflows (CRM updates, filing reports, spreadsheet work) as a major growth area after math and coding. Buyers building simulated workplaces look for archives that capture disagreements and tricky judgment calls, MIT Technology Review reported in October 2026.

Labs also use one environment in three ways, per Epoch AI: for reinforcement learning, for benchmarking, and for fine-tuning on attempts that solved the task. A set of good tasks has more than one use, which is part of why builders pay for the inputs.

What does an RL environment cost to build?

These figures come from Epoch AI's interviews, as of January 2026:

At $200 to $2,000 a task, a few thousand resolved tickets with clear outcomes are a meaningful input. That is the economics behind builders paying companies for data. As of November 2026, Handshake AI says its employer data partnerships typically range from $100K to $4M, and micro1 has announced a commitment to spend $1 billion over 12 months on enterprise operational data for reinforcement learning environments. Both are published ranges and announcements, not offers. Our RL environment companies tracker lists who builds environments, for which domains, and which say they pay for company data.

Which company records make good environment data?

Records that pair a task with its outcome and link across systems. A ticket tied to the email thread and the commit that fixed it is worth more than any of the three alone, because a builder can turn it into a task with a reference answer.

1. Support tickets with resolutions. Each one is a task with a known correct ending.
2. Code repositories with issues and commits. The SWE-bench recipe: issue, fix, tests.
3. CRM pipelines and activity history. CRM work is among the most-cited enterprise workflows.
4. Spreadsheets and reports with their inputs. The inputs are the starting state, and the approved report is the goal.
5. Project trackers. Multi-step tasks with dependencies and owners.
6. Slack, Teams and email threads. Context and coordination, but also the most personal information.

Builders look for consistent IDs across systems, recorded outcomes, real exceptions and years of history. They also need names replaced consistently rather than deleted, so a thread still reads as a conversation after de-identification. The guide to RL environments and company data has a fuller table, and the workflow data guide shows how to describe one workflow end to end without exporting anything.

Common questions

Is an RL environment the same as a training dataset?
No. A dataset is a fixed set of examples a model learns from. An environment is working software with data, tasks and a grader, where the model acts and gets scored. The same company records can feed either, so a license should say which uses it allows: training, building environments, evaluating models, or all three.

What is an RL gym?
Another name for an RL environment. The term comes from earlier reinforcement learning toolkits such as OpenAI Gym, now maintained as Gymnasium. Several environment builders sell "RL gyms" to labs, and the word now covers office-software replicas as well as games and physics simulators.

Do I need to export data to find out whether it is useful?
No. A first conversation needs a description at company level: which systems, how many years, roughly how many records, and whether outcomes are recorded. Exports come later, under an NDA, and only after the de-identification approach is agreed with the buyer.

Can an operating company license records, or only a closed one?
Both. Closed startups are common sellers because their archives are complete and no longer needed, but environment builders also license copies of records from operating companies. An operating company usually wants a non-exclusive license, limits on use and a deletion clause at the end of the term.

If your company has tickets, CRM history or code with outcomes attached, our free estimate asks six questions and needs no files.

Origin Data Partners is an independent data partner that helps companies get their data bought. We are independent of the companies named here, and a buyer may pay Origin when a deal closes.