How company archives become RL gyms for AI agents

What is an RL gym, and why do developers want company archives?#

An RL gym is a practice environment where an AI agent attempts tasks, takes actions and receives a score, so it can improve through reinforcement learning or be evaluated before release. Agents meant to work inside companies need practice settings that look like real companies, with messy tickets, half-finished threads and decisions made under constraints.

Company archives supply that realism. TechCrunch reported in September 2025 that leading AI labs wanted more reinforcement learning environments, and Forbes reported in April 2026 that workplace records bought from defunct companies were being fed into reinforcement learning gyms, simulated workplaces where agents practice with real company documents and messages. Research benchmarks take a similar approach: TheAgentCompany, presented at NeurIPS 2025, scores agents inside a simulated small software company.

For founders and wind-down officers, the important point is that an archive used this way is not simply read. It is cut into episodes, reconstructed as a working environment and scored, which raises different questions than ordinary training use.

From archive to scored task: the steps#

The path from archive to scored task runs through eight steps, and the owner has a decision point at most of them. Developers vary in method, but the sequence below covers what a typical project involves.

• 1Inventory: list systems, record families and date ranges, using metadata only.
• 2Rights review: confirm the entity can license each record family and note exclusions such as customer-owned material.
• 3Privacy preparation: replace names with consistent role tokens, remove customer identifiers and scan for passwords and keys.
• 4Episode extraction: cut the archive into self-contained tasks, such as a ticket from open to close or a pull request from first commit to merge.
• 5State reconstruction: capture what was known when each task began, including prior tickets, documents and the code at that commit.
• 6Grader design: define how an agent's attempt is scored, often by comparing it with the real outcome or running the original tests.
• 7Packaging and delivery: hand over the prepared episodes under the license, from the owner's storage or on encrypted drives.
• 8End of term: delete raw records and settle what happens to derived tasks and graders.

Which records make good tasks?#

Records make good tasks when the outcome can be checked. A merged fix with passing tests, a ticket marked resolved without a reopen, or an approval that was granted gives the grader something firm to compare against.

The table maps common archive records to the task an agent could practice, how it might be scored and the concern an owner should raise first.

Records make poor tasks when no outcome survives: a thread that trails off, a ticket closed by an automation without a reply, or a branch that was abandoned. They still have a use as background in another task's starting state, but they rarely support a grader on their own, so they add less to a package than their volume suggests.

What a developer does not need from you#

A developer building an RL gym does not need access to your live systems. Environments are built from exported snapshots, so no logins, admin credentials or API tokens should change hands, and accounts can be closed once exports are verified.

Nor does a developer need the identities of the people in the records. Consistent role tokens, such as support agent A or engineer B, preserve who did what without saying who they were. Automated scanners help: TruffleHog, an open-source secret scanner, checks sources including Git, chats, wikis and logs for credentials and can test whether a found key still works. Revoke anything live, and have a person sample the output.

What owners and wind-down officers control#

Owners and wind-down officers control the terms that decide how far an archive travels. The most overlooked is derived material: tasks, graders and environment code built from your records may be kept after raw records are deleted unless the license says otherwise.

Settle these points in writing before delivery:

• 1Scope: which systems, channels, projects and date ranges are included, and which are excluded by default.
• 2Permitted use: training, evaluation, environment building, or a stated combination.
• 3Sharing: whether the environment may be offered to third parties or stays inside the licensee.
• 4Re-identification: an express ban on attempts to identify people or companies in the records.
• 5Naming: no use of the company's name to label or market the environment without consent.
• 6Deletion: destruction of raw records at end of term with written confirmation, and agreed treatment of derived tasks.

Illustrative: a closed restaurant software startup turns tickets into tasks#

Illustrative: a fictional restaurant inventory software startup shuts down when a planned acquisition collapses. The wind-down officer exports its Jira projects, GitHub organization, Zendesk instance and engineering Slack channels before the subscriptions are cancelled, and a developer building agent environments for software teams asks about the archive.

Not every record becomes a task. The developer keeps only Jira issues with a linked, merged pull request and a passing test run at the merge commit, and only Zendesk tickets solved without a reopen. Abandoned branches, tickets closed by automation and threads with no outcome are used, if at all, as background in other tasks' starting state. The wind-down officer reviews a sample of finished episodes before approving the rest.

Outcome: the license permits environment building and evaluation inside the licensee only, bans re-identification and says what happens to derived tasks and graders at the end of the term: deletion, or retention in de-identified form with no raw text. The estate keeps ownership of the records and a list of which episodes went to which developer.

How SourceX handles archive-to-environment deals#

SourceX handles archive-to-environment deals as ordinary licenses with one extra question: whether environment building is a permitted use. That question is scoped in the Rights step of the SourceX five-step transaction, which runs Supply, Rights, Preparation, Approval and Delivery, and the owner signs it off at Approval before any episode is cut from the archive.

Owners describe an archive by system and date range alone during the fit check, so no message or file leaves early. When a package proceeds, its SourceX Evidence Packet names environment building explicitly if permitted, alongside provenance, the privacy record and release authorization. Whatever its size, the archive is delivered from the owner's own storage or on encrypted drives, since SourceX never hosts multi-TB datasets.