Microsoft released Orchard, an open-source framework for building and testing AI agents, on GitHub. The project’s core idea is that data collection, reinforcement learning and benchmark testing can all run on one shared piece of infrastructure instead of three separately built systems. That targets a real cost in agent research: teams typically maintain distinct plumbing for each stage of a project, and rewriting it consumes time that could go toward the experiments themselves.
The foundation, called Orchard Env, is what Microsoft labels an “environment service.” In practical terms, it is a container-management layer, comparable to a cloud sandbox provider, that spins up isolated compute environments on demand and exposes an API for creating them, running commands inside them, moving files in and out, and shutting them down. Crucially, that layer has no idea what is driving each sandbox. It could be a script capturing an expert model’s actions for later training, a reinforcement-learning loop scoring an agent’s own attempts, or a grading harness running a finished model against a benchmark. The service just manages the box.
That gap between the sandbox layer and whatever sits above it is the substance of Microsoft’s example. A team can point identical sandbox infrastructure at three different jobs: recording a stronger model’s trajectories to train a smaller one, running many scored attempts for on-policy reinforcement learning, and grading a finished model on a held-out benchmark. Mechanically these three jobs are the same request repeated: spin up a sandbox, let something interact with it across many turns, tear it down, and log what happened. Today, most research groups write a custom version of that plumbing for each project, often three separate times for the three uses above, because container orchestration, network rules and cleanup logic tend to get baked directly into whichever trainer or harness a project happens to use.
The claim worth pressure-testing is the one about portability. Research infrastructure gets rebuilt study to study not out of sloppiness but because projects differ in ways that leak past any shared layer: how credit gets assigned across a forty-plus-turn trajectory, what counts as a reward, what domain-specific tools a sandbox needs to expose. Orchard Env pushes those decisions into the recipe built on top and keeps the shared service limited to generic operations: starting and stopping sandboxes, running commands, handling files, and enforcing network rules. Microsoft offers one concrete check on the claim: when the team swapped a standard container setup for Orchard Env while benchmarking on Terminal-Bench 2.0, scores across three different models held steady rather than dropping. That is evidence the sandbox layer does not distort results on the tasks tested, not proof every future recipe will fit its assumptions.
Adopting Orchard also carries a real cost the documentation does not hide. The service runs on Kubernetes, coordinated by an orchestrator that keeps state in Redis and enforces network isolation through Calico, with a documented path to deploying it on Azure’s managed Kubernetes service. That is production-grade infrastructure, not a laptop script. A small academic lab without an existing Kubernetes cluster and the staff to operate one faces real setup work before running a first experiment, even with the four scripts Microsoft provides to automate the deployment.
What actually ships: the Orchard Env SDK and API, a modified fork of the open-source slime reinforcement-learning trainer, and three published recipes, Orchard-SWE, Orchard-GUI and Orchard-Claw, plus two newer projects built on the same environment layer. Every sandbox comes with five agent harnesses preinstalled, including Codex and Claude, so switching which one a team trains or evaluates against does not require rebuilding the container image. Microsoft has also published a Hugging Face dataset with roughly 107,000 software-engineering trajectories and just over 3,000 browser-navigation rollouts, alongside an arXiv paper describing the framework. The repository is licensed under MIT.
A GitHub README cannot say how many teams outside Microsoft have picked up Orchard, how battle-tested the service is beyond Microsoft’s own workloads, or whether the portability claim survives a recipe nobody there has tried. Today’s issue carries several other stories about measurement and harnesses, and the pattern connecting them is that the scaffolding around models is standardizing faster than the models themselves.
Teams currently maintaining separate sandbox stacks for training and evaluation should read Orchard’s API docs before their next infrastructure rewrite; the Terminal-Bench parity result suggests a drop-in substrate is now a real option rather than a research prototype.
Microsoft published the Orchard framework and its documentation on GitHub, with the repository’s most recent update logged in July 2026.
