Abundant
← All articles
product

Introducing Foundry

Jesse Hu4 min read

Today we are launching Foundry, and we’re excited to announce that we’re working with Fireworks AI.

Fireworks has made it easy for teams to serve and train open models: fast inference, fine-tuning, and reinforcement fine-tuning, all on one platform. The infrastructure to run RL is no longer the hard part. The hard part is the hillclimb: defining the rubric for your specific objectives, and then climbing your model toward it. That is what we do at Abundant, and we’re excited to work with Fireworks to bring the two together.

Training is getting easier. Environments aren’t.

A model trained with RL only gets as good as the environment it learns from. If a task is ambiguous, the model learns the ambiguity. If a verifier can be gamed, the model learns to game it. We’ve written about how often frontier models find shortcuts when the environment lets them, and about how much care goes into designing a good task in the first place.

Building good environments is manually intensive work. It takes smart researchers, good taste, and a lot of time spent looking at data. Until recently, this kind of work was mostly reserved for frontier labs. But more and more companies want to own their own intelligence: to take their own data and workflows and turn them into a model that is better at the things they care about. For those teams, the environment is the bottleneck.

How it works

Fireworks customers who want to post-train on their own workflows can work with Abundant to build the environments for it. Foundry turns real product feedback into tasks a model can train on. In practice, we work with customers in four steps:

01

Leverage your data

We start from the data your product already has: the user sessions, the tools, and golden test cases.

The Sources page in Foundry. Three counts: sessions captured, candidate tasks, verified tasks. Below, a stream of incoming sessions from Claude Code, PagerDuty, Cursor, GitHub, and Zendesk.
02

Build custom tasks

We use examples of what great looks like as reference tests, and run reinforcement fine-tuning to improve your agent until it creates the same outcomes.

A task in Foundry built from one coding session. The file list shows the prompt, hidden tests, reference solution, environment, and source session. The instruction is shown on the right.
03

Test like a frontier lab

Run the same QA the frontier labs run on every task, then compare frontier models and your own on the same tasks and see where each one fails.

An experiment in Foundry. A table of pass and fail marks for five tasks across an empty run, the reference solution, and two models, with a column that names why each task failed.
04

Train and ship

Train and serve on Fireworks. What we learn from each training run goes back into the tasks, so the hillclimb keeps going as the model improves.

A training run in Foundry. The score on unseen tasks for the new version next to the live version and the best public model, with a chart of score by version and an approve button.

Verifiers and rubrics that hold up

We audit every environment for quality before it is used for training, and look for the ways a model could pass without actually solving the task. Every task goes through the same five checks before your model sees it.

  1. Rubric review. Before any run, an AI reads every file. It flags leaked answers and weak tests.
  2. Baselines. Every task runs with a reference solution that is checked to ensure it passes verification. It also is run against an empty answer, which must fail.
  3. Adversarial QA. We run adversarial QA on every task to ensure the model cannot reward hack to get the reward without doing the task.
  4. Stress test. We run each task at least five times across at least three different agents. A judge labels why each run passed or failed, and a pass the tests should not have allowed counts as a defect.
  5. Sign-off. A person approves each task version.

Our state-of-the-art method is published at NeurIPS 2026 and ICLR 2026. Read more.

A QA verdict page for one task. The verdict is rejected with two must-fix findings and one should-fix finding. The first finding, tagged exploited, is a leaked hint in the environment found in the pre-trial audit and seen in four agent runs. The second is an exploit from an adversarial run that the grader rewarded.
QA in action. The audit caught a leaked hint in the environment and an exploit the grader rewarded the model on, so the task was pulled from the hillclimb until both are fixed.

Why we’re excited

Fireworks gives teams the infrastructure to train and serve models. Abundant gives them the environments that make that training worthwhile, and runs the hillclimb as a service: on every new checkpoint, we find the headroom, learn why the model fails, and ship the tasks that fill the gap. Together, we can take a team from its own data to a better model, without the team needing to build an RL research group from scratch.

You can already run Abundant tools on your own Fireworks account. See Bring Your Own Key: Fireworks AI for setup.

If you’re building on Fireworks and want to train a model on your own workflows, we’d love to talk. Request early access.

$ _