The non-coding agentic RL-Gym program

Problem

If you want to train an agent to write code, the world hands you a lot for free. Repos, tests, compilers, a pass/fail signal that costs nothing to compute. Almost none of that exists for the rest of what agents are supposed to do. A model that can refactor a service can still fall apart the moment it has to read a policy document, query a records system, call a scheduling API in the right order, and then explain what it did to a person who was not watching.

That data does not exist in the wild. You can't scrape it, because the interesting part is the interaction, and the interaction only happens inside a system that's willing to change state when the agent acts on it. Somebody has to build the world, write the tasks that live in it, and build the machinery that decides whether the agent actually succeeded. In May 2026 my scope at Deccan AI expanded to lead exactly that: technical direction for the Agentic Pod's non-coding RL-Gym.

How I thought about it

The word "gym" makes it sound like an ML problem. It's mostly a specification problem wearing an ML costume.

The three things that go wrong are predictable. The environment is too forgiving, so every task is solvable by a competent instruction-follower and you learn nothing about agency. Or the verifier is too shallow, so an agent that produced the right final string gets rewarded for a trajectory full of nonsense. Or the task authors, who are annotators working at volume against a written brief, interpret "hard" four different ways and you end up with a dataset whose difficulty distribution is noise.

So I set the direction around two commitments. First, environments hold real state, with consequences that outlive the current turn. Second, every task ships with a verifier, and if you can't write the verifier you can't write the task. That second rule killed a lot of appealing task ideas early, which is what it was for.

Architecture

Environments are multi-turn and span multiple servers, so an agent has to hold context across tool boundaries rather than solving everything in one call. Underneath sits synthetic enterprise state that the agent reads from and writes to.

On top of the environment: a task layer, where each task carries a goal, a starting state, a difficulty tier, and a verifier. Then an evaluation layer, where LLM-as-judge scoring runs over the agent's reasoning and tool-use trajectory rather than just its final answer, with programmatic verifiers checking end state wherever end state is checkable. Rubrics define the parts that programs can't check.

Around all of it, the human layer: the task-design standard, and the calibration process that keeps annotation and QC teams producing the same thing week over week.

What I built

I wrote the task-design and QC standards that the annotation and QC teams now work from, which is the artifact with the widest blast radius. I built LLM-as-judge and reward pipelines that score agent reasoning and tool-use trajectories at scale, plus the task verifiers and difficulty rubrics that set what pass and fail mean. I architected the synthetic enterprise databases the environments run on. And I ran benchmarks across datasets and agent architectures to see what the data was actually teaching. Alongside it, I ran the annotation review process and reviewer management for a BrowserGym web-agent pilot, creating sample tasks, setting prompt-quality standards, and screening tasks for reward hacking.