Agents learn by doing.
Give them somewhere real.

Production-grade RL environments for training frontier AI agents on real engineering work, alongside expert-generated post-training datasets: SFT, preference, critique, and reasoning data.

Scope an RL environment pilot Scope a post-training data pilot See how it works

Two things Train provides

An environment to act in, or data to learn from.

They are different assets, produced differently, and they work well together. You can engage for either one.

RL environments

A place where an agent acts

A runnable task with a defined start, a set of tools, explicit completion criteria and an independent verifier. The agent takes steps and sees what they do.

What it teachesActing across many steps, using tools, recovering from failure, finishing the job.
How it is scoredA verifier checks the resulting state and behaviour, not the wording of an answer.
You run itIn your own training stack. Synthium supplies the environment, tasks and verification.
Delivered asAn environment specification, tasks, an execution interface, a verifier and a feedback specification.

Post-training datasets

Expert-written data to learn from

Demonstrations, comparisons, critiques and reasoning written or judged by qualified domain experts, in the schema your pipeline expects.

What it teachesWhat good looks like, which of two responses is better and why, and where an output goes wrong.
How it is checkedIndependent review against your rubric, with disagreement adjudicated rather than averaged.
You use itIn supervised fine-tuning, preference training, or as a source of evaluation examples.
Delivered asRecords in your schema, with the guidelines and review records behind them where included.

They combine well. Demonstrations and critiques can seed or shape the tasks an agent is then trained on in an environment, and a verifier's failures can point to the examples worth writing. A project does not need both.

RL environments

The environments frontier agents learn in.

Frontier agents won't become capable of complex engineering work by learning from static examples alone. They need to interact with realistic systems, make decisions across multiple steps, observe the consequences, and learn from verifiable outcomes.

Synthium builds high-fidelity, production-grade reinforcement learning environments that help AI teams train and improve agents on complex, real-world tasks.

In practice, each environment is a runnable software-engineering task with explicit completion criteria, independent verification, and reproducibility requirements, so a solution can be told apart from a superficial fix.

Built for agent training. Designed for rigorous verification.

What we build

Realistic execution environments
Reproducible software repositories, services, tools, and operational systems.
Complex, long-horizon tasks
Multi-step problems involving investigation, planning, implementation, and debugging.
Robust verification infrastructure
Independent tests and state-based checks that distinguish genuine solutions from superficial fixes.
Training-compatible feedback
Structured outcomes and reward signals that can support reinforcement learning workflows.
Difficulty-calibrated benchmarks
Tasks designed to expose the difference between memorized patterns and robust problem-solving.

From simulated work to measurable capability

We provide the environments, tasks, and verification systems. AI research and post-training teams can integrate them into their own training pipelines to generate agent experience, optimize behavior, and evaluate progress.

Train agents to do the work, not just describe how it should be done.

ILLUSTRATIVE EXAMPLE

environment

Repository

src/
  api
  workers
  database
  services
tests/
  unit
  integration
  hidden

Task

Investigate intermittent request duplication.

Environment

ConcurrencyDistributed workerPostgreSQLRedis

Verification

Tests
Regression
Race check
Behavior

A sample environment to show the parts. It is not a customer's and does not describe a delivered project.

How an environment or dataset is produced

From specification to something your trainer can run.

Every environment and every item passes the same route — and the ones that don't hold up go back rather than through.

SpecificationYour capability target, rubric, and schema
QualificationContributors assessed against the domain
AuthoringAn expert builds the environment or writes the data
ReviewIndependently checked against your rubric
RejectedWork that doesn't hold up goes back
DeliveryAn environment you can run, or data in your schema

The RL environment lifecycle

From task specification to a feedback signal, and who owns each part.

An episode runs the same way every time. The useful question for a team integrating one is which parts Synthium supplies and which stay in your own stack.

Task specification and objective
The capability to teach, the task family, and what counts as done, written down and agreed.
Synthium supplies
Environment setup and initial state
The repository, services and tools, brought to a fixed starting state by a script.
Synthium supplies
Agent interaction and observations
The agent chooses actions and receives observations. The execution interface defines how.
Shared
Tool use and execution
The agent runs commands, edits files and calls tools inside the environment.
Shared
Success, failure and termination
The criteria that end an episode: completed, out of budget, or a forbidden action taken.
Synthium supplies
Independent verification
A verifier checks the resulting state and behaviour, including checks the agent cannot see.
Synthium supplies
Reward or feedback signal
The verifier's result, turned into the structured feedback or reward you specified.
Shared
Training and model updates
Using that feedback to train your model: your algorithm, your compute, your infrastructure.
Your stack
Difficulty calibration and evaluation
Checking that tasks separate stronger agents from weaker ones, and tracking progress against them.
Shared

Synthium supplies the environments, tasks and verification. Teams integrate them into their own training pipelines. Synthium does not run your model training, and this page does not describe it as part of the service.

What makes an environment production-grade

Properties we specify, and how you can check them.

These are requirements an environment is written against. Whether a particular environment meets them is shown by its validation suite and calibration report where the engagement includes them, not asserted on this page.

Properties of a production-grade RL environment, and how each is checked
Aspect	The specification defines	How it is checked
Initial state	A fixed starting point: a pinned repository state and seeded services, set up by a script.	Re-running setup produces the same state, and the setup script is part of what you receive.
Success and failure	Explicit completion criteria, and what ends an episode: success, a budget used, or a forbidden action.	The criteria are written in the task specification and exercised by the validation suite.
Independent verification	A verifier separate from the agent's view, using state-based checks and tests the agent does not see.	Known-good and known-bad attempts are run through it, and its verdicts are recorded.
Resistance to shortcuts	Checks designed to tell a real fix from a superficial one, such as protected files and hidden tests.	Adversarial attempts are tried against the verifier. A check that can be gamed is changed, and the report says what was tried.
Reproducible execution	Runs are repeatable from the same inputs, and structured traces are produced.	Repeated runs of the same attempt are compared, and any variation is explained or removed.
Controlled execution	What the agent may access and which actions are forbidden, stated in the specification.	The permitted and forbidden actions are enforced by the verifier and listed in the interface documentation.
Difficulty	Tasks sized and ordered so an environment separates capable agents from weaker ones.	A calibration report, where included, shows how reference attempts fared across the task set.

What we assess

Data types, generated to your specification.

Separate from the environments, and bought separately. Every dataset is produced by contributors qualified in the domain, then verified against your rubric and gold standards.

SFT datasets

Expert-written demonstrations that model the behaviour you want to teach, including demonstrations of a task completed successfully.

Preference pairs

RLHF and RLAIF comparisons with the rationale behind each judgment attached.

Critique and rewrite

Structured critique of model output, paired with a corrected version.

Reasoning traces

Step-by-step solutions that expose the working, not just the answer.

Failure analysis and feedback

Expert write-ups of why an attempt failed, usable as feedback examples.

Rubric-based evaluations

Outputs judged against criteria agreed before judging begins.

Domain answer generation

Subject-matter responses in fields where correctness requires real expertise.

Output verification

Expert verification of model-generated candidates before they enter training.

What you receive

What a Train engagement can hand over.

Environments and datasets are different deliverables. A project may be one or the other, or both, and which items it includes is set in the scope.

RL environment

Environment specification
The task family, initial state, tools, permitted and forbidden actions, and what ends an episode.
Standard
Task and scenario definitions
The individual tasks, each with its own objective and completion criteria.
Standard
Execution interface
How an agent starts an episode, acts, observes and ends it, with integration documentation.
Standard
Verifier and scoring logic
The independent checks that decide whether a task was completed.
Standard
Feedback or reward specification
How the verifier's result becomes the signal your training stack consumes. Format agreed with you.
Standard
Test and validation suite
Known-good and known-bad attempts run through the verifier, so you can see it behave as specified.
Optional
Difficulty and calibration report
How reference attempts fared across the task set, reported without headline figures.
Optional
Sample execution traces
Structured traces of example attempts, to show what an episode produces.
Optional
Number of tasks, domains and turnaround
Not assumed from this page. Agreed in the scope before work starts.
Scoped per engagement

Post-training data

Datasets in your schema
SFT examples, preference pairs, critiques or reasoning traces, in the format your pipeline expects.
Standard
Guidelines and rubrics
The instructions and criteria the data was written or judged against, versioned.
Optional
Review and adjudication records
Reviewer decisions, and for disagreements, who decided and why.
Optional
Quality summary
What was sampled and audited, reported plainly.
Optional
Which data types, volume and turnaround
Not every type is part of every engagement. Agreed in the scope.
Scoped per engagement

Which of these an engagement includes is agreed before work starts. A listed item is a capability, not a promise that every engagement contains it.

A sample environment

A task specification, and what the verifier says about two attempts.

An environment is only as useful as its verifier. This sample shows a task specification and the verifier's report on two different attempts at it: one that passes the visible tests the wrong way, and one that solves the problem.

ILLUSTRATIVE EXAMPLE

Sample environment: task specification and verifier report

Task specification

task_id:     EXAMPLE-env-017
objective:   Stop queued jobs from running twice, without
             dropping any.
start_state: repository at a fixed commit; PostgreSQL and
             Redis seeded by a fixed script
tools:       shell, editor, test runner
success:     visible tests pass
             AND hidden regression suite passes
             AND repeated concurrent runs show no duplicate
                 execution
             AND protected files are unchanged
ends_when:   success | step budget used | forbidden action

Verifier report on two attempts

Check	Attempt A	Attempt B
Visible tests	Pass	Pass
Hidden regression suite	Fail	Pass
Repeated concurrent runs	Fail	Pass
Protected files unchanged	Fail	Pass
Outcome	Fail	Pass

Attempt A: why it failed

The visible tests pass only because the attempt edited them to match its own output. The protected-file check catches that, and the hidden suite and the concurrent runs both still fail. The duplicate execution was never fixed.

Attempt B: why it passed

The fix is made where the job is claimed, so a job can be taken once. Every check passes, including the ones the attempt could not see.

Feedback signal

The outcome is binary on the verifier result, with the failed checks attached as structured feedback. The reward and feedback format is part of the specification you agree, so it can match the way your training stack consumes it.

A synthetic example of the parts of a coding-agent environment. It is not a delivered environment, and it does not show that any verifier is free of shortcuts: the validation suite and calibration report, where an engagement includes them, are how that is checked for a real environment.

How it runs

Built to your rubric, not a generic guideline.

We work from your specification and your gold standards, and we measure contributors against them continuously rather than once at onboarding.

Specification
We work from your capability target, rubric, and gold standards — not a generic annotation guideline.
Qualified contributors
Domain experts are assessed against project-specific standards before any production work.
Multi-stage review
Independent review against your rubric and gold standards at every step.
Format delivery
Delivered as environments your trainer can run, or in the schema your training pipeline expects.

Who does the work

Built by people who know the subject.

Environments and post-training data are only as good as the engineers and experts who build them. We staff each environment and dataset with contributors qualified in the relevant domain and measure them continuously against your standard.

Software engineering
Mathematics and formal reasoning
Computer science and systems
Finance and accounting
Law and policy
Medicine and science
Languages and localisation

Engagement and fit

How a Train pilot starts, and who it suits.

A first conversation needs a description of the capability and the format. It does not need your code or your model.

What to bring to a first conversation

The capability to improveWhat the agent should be able to do that it cannot do reliably now.
A task familyThe kind of work, such as debugging concurrency faults, in words.
An existing benchmark or objectiveHow you measure progress today, if you do.
How you consume feedbackThe reward or feedback format and interface your training stack expects.

A good fit when

You train or fine-tune agents and need realistic, verifiable tasks rather than static examples.
You run your own training infrastructure and want environments, tasks and verification delivered into it.
You need expert-written post-training data in a specific schema, to a rubric you set.

Not the right fit when

You want Synthium to run your model training or host your training infrastructure.
You want a general-purpose environment for any task without defining one.
You are looking for a leaderboard score or a public benchmark result.

We never need your source code, credentials or model weights to start. Please do not send them through the pilot form.

Choosing between offerings

Which Synthium offering fits the problem?

They are separate offerings, and they work together where a project needs more than one. Most teams start with one.

When to choose each Synthium offering, and what each delivers
Offering	Choose it when	You receive
Synthium Data	You need data acquired or licensed, or you have data or a task that needs expert curation and annotation.	An assessment of fit and rights, or an expert-reviewed dataset, with the documentation behind it. Scope is agreed first.
Synthium Train (this page)	You are improving an agent or model and need RL environments, or expert-generated post-training data.	Environments with tasks and verification you run in your own training stack, and/or datasets in your schema.
Synthium Agents	You need to know how well a model or agent performs on realistic tasks, and exactly where it fails.	An evaluation specification, traces, expert-reviewed findings and a failure analysis you can act on.
Synthium Red Team	You want authorized adversarial testing of an AI system and documented, reproducible failures.	A scoped test plan, findings with evidence and a severity rationale, and mitigation recommendations.

Keep exploring

Questions about Synthium Train

Do you run our model training?

No. Synthium supplies the environments, tasks and verification, and your team integrates them into your own training pipeline. The training run itself stays in your stack.

How is an RL environment different from a dataset?

A dataset is a fixed set of examples. An environment is a runnable task an agent acts in, scored by a verifier on the resulting state. They teach different things and are provided separately, though they combine well.

How do you stop an agent passing by exploiting the verifier?

The verifier uses checks the agent cannot see, such as hidden tests and protected files, and adversarial attempts are tried against it. The validation suite, where included, records what was tried. We do not claim any verifier is immune; we show how it was tested.

Can the environment run in our infrastructure?

Environments are delivered with an execution interface and integration documentation so you can run them in your own stack. The specifics of packaging and hosting are agreed for each engagement.

What do we need to share to start?

A description of the capability, the task family and the feedback format. Not your source code, credentials or model weights.

Which data types do you provide?

SFT demonstrations, preference pairs, critiques and rewrites, reasoning traces and failure analyses. Not every type is part of every engagement; the scope says which.

Next step

Build the environment your agent is missing.

Tell us the capability you're trying to teach and the format you need, an environment, a dataset, or both. We'll design the contributor pool and quality gates around it.

Scope an RL environment pilot Scope a post-training data pilot

Describe the capability and the task family in words. Please don't send source code, credentials, model weights or non-public benchmark data through the form. If we proceed, we agree a secure route first.

Agents learn by doing.Give them somewhere real.