Formats
- Container images for Docker or your container platform
- Tool schemas as JSON Schema, served over MCP or adapted to your agent framework
- Trajectories as JSONL with step-level fields
- Verifiers in Python, with their own tests
Give your agent a copy of the office to practice in.
We rebuild one of your workflows as a safe environment: the same tools, realistic seeded records, and an automatic check of whether the job was done right. Your experts work through it, and their recorded steps become the demonstrations, tests, and reward signal an agent learns from.
Agents fail at the seams between systems
Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Most of the failures behind that number are invisible in a demo. A claims agent works when the policy lookup returns one result and stalls when it returns three. A scheduling agent books the right crew and forgets to update the work order. A prior-authorization agent drafts a good request and attaches the wrong patient's lab result.
Prompting doesn't fix this. Practice does: many attempts on realistic cases, with a reliable signal of what done correctly means. That requires an environment that behaves like your systems, holds data that looks like yours, and can score an attempt without a person watching every run.
What an environment is made of
Tools with real schemas
Each system the agent touches, such as policy administration, an EHR lookup, the ERP, email, or a document store, is exposed as a tool with a typed schema over the Model Context Protocol or your framework's equivalent. Tools return the same errors, pagination, and odd formats production does.
Seeded data with known states
A replica of the relevant tables and documents, generated or de-identified from your records, seeded with the cases that trip agents up: the policy that lapsed yesterday, the duplicate vendor, the claim with two claimants.
Tasks written from real cases
A few hundred tasks, each with a starting state and a goal phrased the way a coworker would ask for it, split into training and held-out evaluation tasks.
Verifiers
Code that inspects the sandbox's final state and returns a score: was the reserve set within the right range, was the work order closed, did the email go to the right person and nobody else. Partial credit and penalties for unsafe actions where the task calls for them.
Resettable episodes
Every attempt starts from a snapshot, so thousands of runs are reproducible and comparable, and one bad run can't contaminate the next.
What one reviewed trajectory step records
Your practitioners, or ours, complete tasks in the sandbox while every step is logged. Reviewers then check each trajectory against the verifier and the rubric, mark wrong turns, and correct them. The values below are illustrative.
| Field | Example | Why it's there |
|---|---|---|
| task_id | FNOL-0142: hail damage; insured holds two active policies | Ties the step to its task, starting state, and verifier |
| observation | policy_search returned 2 results | What the expert or agent saw before acting |
| action | get_policy with the second policy number | The tool call and its typed arguments |
| rationale | Loss address matches the second policy, not the first | The expert's reason, used in training and in review |
| outcome | Coverage confirmed; reserve set | The state change the verifier will check |
| review | Correct; step 6 should come before step 5 | The reviewer's mark, used to fix or reject the trajectory |
One environment, three uses
Reviewed expert trajectories are training data for supervised fine-tuning: the agent imitates how your best people work, including the checks they make before acting. The same task set, scored by the verifiers, becomes an evaluation suite that any new model, prompt, or tool change has to pass. And once verifiers are trustworthy, the environment supports reinforcement learning, where the agent improves from its own attempts against the reward signal.
Failed agent attempts are worth keeping too. Labeled with where they went wrong, they become negative examples, regression tests, and the clearest guide to which tool or instruction needs work.
Reward hacking starts with a lazy verifier
If the verifier only checks that an email was sent, an agent will learn to send an email. Before a verifier scores anything, we test it against deliberately wrong solutions: the right outcome reached by a forbidden path, partial completion, and actions that would be unsafe in production. We also keep a human review sample on every training run, because agents find gaps that tests miss.
The environment build at a glance
You provide
- One workflow, with API documentation or read access to the schemas of the systems it touches
- Sample records, or permission to generate and de-identify seed data from yours
- Practitioners for 10 to 20 hours to walk through tasks and review edge cases
We deliver
- A containerized sandbox with tools, seeded data, and snapshot reset
- A task set with automatic verifiers and a scoring runner
- 300 expert trajectories, each reviewed step by step
- A baseline report: how current models score on the held-out tasks, with failure analysis
Quality gates
- Every verifier tested against known-good and known-bad end states before use
- Every trajectory passes its verifier and a human review
- No live personal information in the sandbox
- Training and held-out evaluation tasks kept separate
Turnaround
Six to eight weeks
Team
An agent engineer, a backend engineer, an annotation lead, and domain practitioners
Starts at
$26,000
One workflow rebuilt as a sandbox with tools, seeded data and an automatic verifier, plus 300 reviewed expert trajectories.
One workflow, fully built
Agent environment build
Starts at
$26,000
One workflow rebuilt as a sandbox with tools, seeded data and an automatic verifier, plus 300 reviewed expert trajectories.
Request a scoped quoteFurther workflows that share tools and data with the first cost less to build. Trajectories beyond the first 300 are priced per reviewed trajectory.
Questions about agent environments
Do we need reinforcement learning, or is fine-tuning on trajectories enough?
Start with supervised fine-tuning on reviewed trajectories; it is cheaper and often enough. Reinforcement learning pays when you have trustworthy verifiers and a task set large enough that the agent can't memorize it. The environment supports both, and evaluation either way.
Does the sandbox connect to our production systems?
No. It replicates them with seeded data. We need schemas and documentation, and sometimes read access to understand real behavior, but agents in training never touch live systems or live records.
We're not ready to train an agent. Is there anything to do now?
Yes: start logging. Record what your people and any current automations do, with inputs, tool calls, results, and outcomes. Those logs become trajectories later. We explain what to capture in log agent trajectories now.
Which agent framework do you support?
We recommend none by default. Tools are defined once as JSON Schema and served over MCP, which many agent frameworks can call, or adapted to the one you already use.
Can we use the environment only for evaluation?
Yes. Many teams start there: the held-out task set and verifiers become a release gate that every agent change must pass, and training comes later.
Keep reading
Bring us one messy data source and one question.
Tell us what the data is and what you want a model to do with it. A data engineer, not a salesperson, will reply within one business day with questions and a proposed first step.