T-Rax — Multi-Agent Unity Code Generation
A multi-agent graph pipeline that turns a scene description into working C# Unity code, splitting planning from code generation so each agent has one job.
At a glance
T-Rax generates Unity scene logic from a high-level description. Rather than asking a single model to plan and write code in one pass, it splits the work across a graph of agents — an orchestrator, a planner, and an executor — each with a narrow responsibility and a defined handoff.
The problem
Some things are only safe to practice in simulation: an emergency evacuation, a substation intervention, a machine changeover, a civil-protection drill. Extended-reality training works well for exactly these cases — and the organizations that need it most, from municipalities and fire services to hospitals, vocational schools and manufacturing SMEs, are the ones least able to pay for it.
- Every scenario is a software project. Authoring one in Unity is developer work priced in developer-weeks, and there is no version of that job a training officer can do alone.
- Because each scenario is expensive, an organization ends up with two or three of them instead of a library — and then trains only on what it already built.
- When a procedure changes — new regulation, new machine, revised protocol — the scenario is now wrong, and correcting it means going back to a developer who is no longer on the contract.
- The person who actually knows the procedure — the safety officer, the ward nurse, the plant supervisor — has no way to state it and get something runnable back.
How this helps
T-Rax moves scenario authoring away from the developer and toward the person who owns the procedure. The input is a structured description in natural language; the output is working C# scene logic. What sits in between is the part that matters institutionally: the planner writes down what it intends to build before anything is generated, so the plan is a document a human can read, correct, and sign off on.
- Subject-matter experts author, not developers. The scenario starts as a written specification — which is the form a procedure already exists in.
- Revisions get cheap. Updating a drill after a rule change becomes editing the specification and re-running the pipeline, not reopening a Unity project.
- The plan is reviewable before it is built. A training officer can check that the intended scene matches the real procedure while it is still text — the point at which correcting it costs nothing.
- Failures stay attributable. Because the planner never writes code and the executor never re-plans, a wrong scene is either a bad plan or a bad generation. That is what makes the system maintainable by someone who did not build it.
Stated plainly: this is research-stage work, not something an organization can procure today. What it establishes is the shape of the answer — that scenario generation splits cleanly into a reviewable planning artifact and a mechanical code step — and that split is the part which would survive into anything built for real use.
How the pipeline is structured
The separation is the point. The planner never emits code and the executor never re-plans, which keeps failures diagnosable: a bad scene is either a planning problem or a generation problem, never an ambiguous mix of both.
- The orchestrator holds the run and routes state between agents.
- The planner works in three layered stages and outputs task descriptions only — never code.
- The executor consumes those descriptions and emits C#, including the
SetupStandardScenary()entry point, written out toSceneLogic.cs. - The planner–executor workflow is documented as Mermaid and SVG flowcharts alongside the code.
Why split planning from generation
A single agent asked to both plan and implement tends to drift: it writes code that quietly diverges from what it said it would do, and there is no artifact in between to check. Forcing the planner to emit a description first creates that artifact. The plan can be inspected, and the generated C# can be judged against it.