AI engineer writes a single reward function for agent teams: win rate climbs from 51% to 90%

You can train a team of robots or game units to act together only if you tell them in time when they are doing the right thing. Such hints are called a reward function. If you pay only for the final win, the agents barely understand whose actions led to it. So engineers add intermediate incentives by hand, and redo them from scratch whenever the map or the team composition changes. D. Urgun of Karabük University (Turkey) has proposed GARDEN, a method that hands this job to a language model. It goes further than earlier systems: the reward is written once for a whole family of similar scenarios and carried over to new ones without a single edit.

What exactly was tested, and what the numbers are

The method was tested in the JaxMARL library on two benchmarks.

• Overcooked. Two chefs cook soup in a cramped kitchen: they put ingredients into a pot, take out the finished dish, and carry a plate. The standard reward gives 20 points per dish and small bonuses for intermediate steps: 3 for an ingredient in the pot, 3 for a plate, 5 for finished soup. The table layout determines how the chefs split the work.
• SMAX. This is the StarCraft Multi-Agent Challenge benchmark rewritten in JAX: a squad of allied units fights enemies controlled by built-in scripts. The reward is 1 if the enemies are destroyed and at least one of your own units survives. The average over episodes equals the win rate. The standard bonus is given for damage dealt to enemies.

Four scenarios were new to the reward. In Overcooked, these are two kitchen layouts: one with a divider counter and one with a central counter. In SMAX, they are a battle against an enlarged team of marines and a battle with random unit types and starting positions. On these, the final Overcooked result beat the standard reward by 58.2% and 52.5%. The average SMAX win rate rose from 51.0% to 89.9%. For comparison, the author took two approaches with the same number of candidates and trial runs. A fixed diagnostic report reached 84.2%, and Eureka-style reflection (the model edits the reward based on training statistics) reached 79.2%.

How the model finds out for itself what is wrong with the reward

In most earlier methods, including Eureka, the feedback format is set in advance: the model receives summary training curves and rewrites the code based on them. If a coordination problem is not visible in those curves, it goes unnoticed. In GARDEN, the LLM engineer works like a human at a terminal. Through a restricted command shell, it reads the source code of the environment and the algorithm, the logic of the standard reward, configs, trajectories, losses, and checkpoints. When needed, it writes its own analysis scripts. It is not given a ready-made checklist.

It tests hypotheses with trial training runs. These are a limited number of runs of a draft on one of the development scenarios, using the same algorithm, budget, and random seed as the final evaluation. With each version of the reward, the model attaches a short report: what data it looked at, what mechanism it suspects, and where the weak points are.

The process runs in generations of candidates:

• Each candidate works in an independent session and cannot see the drafts and trial runs of its "siblings" in the same generation. Results from earlier generations are available to it.
• After a version is locked, it is trained and evaluated on every development scenario.
• The final reward is chosen by a formula: the average improvement over the standard reward on the development scenarios. Ties are broken by the worst scenario, then by the average result, then by identifier. The model's preferences and data from the new scenarios play no part in the choice.
• The chosen code is frozen, hashed, and used to train new agents from scratch on the hidden scenarios.

The model does not know the scenario number and has to infer it from the map geometry or the team composition. It may read the standard reward code but may not call it from its own code. The reward's trainable "memory" is limited and resets at the start of each episode. Hidden scenarios are protected by sanitized working directories and an action log.

What this means in practice and where the limits are

Transfer here applies to the reward itself, not to trained policies: agents on the new maps are trained anew. The authors stress that they are measuring generalization of the training signal. For engineers, this means savings: one automatically written reward can replace rewriting it for every layout or squad composition. For robotics and logistics, where team configurations vary, this matters especially.

There are limitations. The experiments cover two families of tasks and four hidden scenarios. The author gives no guarantees of transfer: the selection is based on development data, and the hidden results are unknown in advance. For a fair comparison, the standard shaping in Overcooked was kept constant, although in the JaxMARL reference configuration it decays. Testing the method on other environments will be up to the community: the code, prompts, and configurations are in the open repository DoganUrgun/GARDEN.