Faster Model, Better Agent? Training Efficient AI Agents

Notes from PyTorch Meetups Madrid, and what OpenEnv means for engineering teams

The first-ever PyTorch Meetup Madrid was last week! Ricardo Noriega (PyTorch Foundation Ambassador) and I (AAIF Ambassador) opened the event, after us, Carlos Camacho (Red Hat) talked about serving agents at scale wiht d-llm, and Sergio Paniego Blanco (Hugging Face) talked about training them wiht OpenEnv.

Note: While I'd love to write a full post about all the meetup discussions and sessions, this one will focus on the OpenEnv presentation. You can watch the full recording here.

A small model that solved more tasks and used fewer tools

I came home thinking about one result from Sergio's talk: a cool experiment where a small model, after training, solved more tasks and used fewer tools to do it. Most conversations I hear about agents are about which model is fastest, but this one was about how much work the agent does before it finishes.

The training setup used OpenEnv, which has just joined the Agentic AI Foundation (AAIF). I didn't really understand the value OpenEnv could bring before the meetup, but I ended up testing it myself after the session. This post is a short intro to OpenEnv and how it connects with the broader ecosystem, such as MCP and Goose.

Training an agent is different from training a model

Ask a coding agent to fix a bug. It reads a file, edits it, runs the tests, sees a failure and tries again. Writing code that looks right is only part of the job. The rest is deciding what to do after each result.

Sergio covered three ways to train for that: learning from recordings of agents doing the task (supervised fine-tuning), learning from a stronger teacher model (distillation), and learning from scores on the model's own attempts (reinforcement learning). Hugging Face's post-training curriculum explains all three.

The third one needs somewhere for the model to practice. That's an environment.

So, what is OpenEnv exactly?

In practice, an OpenEnv environment is like a small server, usually running in a Docker container. Inside it you put three things:

• The task: for example, fixing a bug in a Python function that should apply a discount to a shopping basket total (but doesn't)
• The tools the agent can use: like reading a file, editing it and running the tests.
• The code that checks the result and gives a score.

Your agent sits outside and talks to it through three calls: reset() to start a new attempt, step() to take an action, and state() to see where things are.

obs = env.reset()
obs = env.step(CallToolAction(tool_name="run_tests", arguments={}))
print(obs.reward, obs.done)

OpenEnv doesn't decide what counts as a good answer (you write that). What it gives you is a standard shape, so the same environment works with different agents and different training libraries, like Hugging Face's TRL.

How can an environment like OpenEnv help with agentic AI adoption?

With everything we've seen so far, you might be thinking: "OK, but my team doesn't train models" (and most of the teams, don't!) The good news is you can still use an environment to test and measure your agents.

And that matters, because many teams are stuck between a prototype or demo and a production-ready agent they can trust. Last year, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, because of rising costs, unclear business value or weak risk controls.

Here's how an environment can help with three of the most common challenges engineering teams face.

Measurement: "Is our agent actually good at our tasks?"

In LangChain's survey of more than 1,300 professionals, only about 52% of teams run evaluations, while nearly 89% have observability. In other words, most teams can see what their agent did, but fewer can tell if it did it well.

With an environment, you get numbers: how many tasks the agent solved and how many steps it needed, across different models and providers. It works like a test suite, but for your agent.

Note: Over three-quarters of organizations use more than one model in production or development. Maybe you want a cheaper model, a local one, or the new release everyone is talking about. Today most teams try it for a few days and go by feel.

Cost and speed: "Our agent gets there, but it takes forever"

Every extra tool call costs time, tokens and money. Sergio's result is about exactly this. In his experiment, LFM2.5-2.6B went from solving about 42% to 54% of tasks it had never seen, averaged across four harnesses. On tasks the base model already solved, it used 31% fewer tool calls. And while fewer calls and fewer tokens aren't the same thing, it shows that efficiency can be measured and improved, not only the final answer. Even before any training, an environment records every step, so you can see where your agent wastes time.

Risk: "We can't let an agent experiment on our real systems"

Part of the problem is that the only way to really know how an agent behaves is to let it act. And nobody wants it learning on the production database.

An environment is a safe copy: a fake calendar, a copy of the repository, a test database. The agent can fail as many times as it needs without touching anything real.

A real example: Turing built Calendar Gym on OpenEnv to test how agents schedule meetings: which calendar to use, what they have permission to change, and which actions must happen first. According to the OpenEnv maintainers, agents succeeded about 90% of the time when tasks named explicit calendar IDs, but only about 40% when the same tasks used natural-language descriptions.

That's the kind of thing you want to discover in a sandbox, not in production!

Note: An environment doesn't make your agent secure in production. That's a different job, and it's where projects like agentgateway come in, with policies on what an agent can access. What an environment gives you is a safe place to test before you get there :)

The connection with MCP

Some OpenEnv environments expose their tools through MCP, so any MCP-compatible agent can use them. The docs explain how this works.

OpenEnv is now part of AAIF

Since the meetup, AAIF announced four new projects: Agent Skills, Open Responses, OpenEnv and OpenSandbox. Hugging Face contributed OpenEnv, which it launched with Meta in 2025.

For me, this closes the loop of our first meetup. The PyTorch side brings training and serving, many of the AAIF projects bring the open standards agents use to work (MCP, Goose, AGENTS.md), and I'd say OpenEnv sits in the middle, where you test and train agents on the tasks you actually care about.

Testing it myself helped me understand all of this much better than reading about it. Next, I want to build a small environment from real tasks and see what it tells me about an agent like Goose. I'll share it here when I do!

Thanks to Ricardo, Carlos, Sergio, Red Hat and everyone who came! Watch the full recording (in Spanish) and follow PyTorch Meetups Madrid for future events.