Dev Blog #9: Multi-Agent Workflow, Booms and Curses

Working with one coding agent already changed how much of StormTome I could build on my own. But agents can sometimes be slow. Working with several introduces another possibility: while one part of the game is being developed, something else can move forward too.

It also introduces a familiar problem. With several artificial developers working on the same project, they need to stay out of each other's way.

Why Use More Than One Agent?

The main attraction is efficiency. An agent can spend several minutes investigating code, implementing a change, or checking its work. If another task is ready and independent, it can progress during that time. Backend work, interface changes, and artwork do not always need to happen one after another.

More agents also mean more work to coordinate and more usage to pay for. In the token economy article, I wrote about trying to spend less tasks adjacent to the goal. Having three agents investigate a common problem independantly could easily bring that cost back.

Letting Codex Divide the Work

Codex can already delegate work to sub-agents. OpenAI's multi-agent documentation describes a main agent coordinating separate tasks and combining the results.

I saw this while working on StormTome's first-time user experience (FTUE), the introduction a new player goes through before settling into the game. Codex handed work to three sub-agents, covering the FTUE engine, quest engine, and presentation.

This was convenient. I could monitor the overall feature in one conversation while Codex divided the implementation. The result was efficient, and I did not have to write and distribute each assignment myself. That said, the collaboration was also fairly short-lived. In this workflow, the sub-agents received specific tasks, worked on them, and reported back.

The report also shows that finishing one assignment is not the same as finishing the feature. Focused tests had passed, but combined verification still remained. The central agent still needed to bring all three pieces together and check the whole experience. That distinction connects to a question from my test-suite audit: what were the tests actually proving?.

Handing Out the Work Myself

Another approach to multi agent workflow is more manual. I can work through an idea with one agent, ask it to produce implementation instructions, and paste those instructions into other agent windows.

This gives me more control over who does what. I can keep one conversation focused on planning, send implementation elsewhere, and return with questions or results. I can also choose a different model for each particular assignment. To achieve this, the handoff instructions need to be comprehensive enough to stand on their own.

• What are we building?
• What decisions have already been made?
• Which files or systems does this agent own?
• What should it leave to the others?

Unfortunately, a vague request gives each agent room to make a different interpretation of the same plan. I also become the person carrying information between the windows. If a requirement changes in one conversation, the others do not automatically know. This means I need to keep the work aligned and review the combined result.

Several Developers, One Directory

When I open several agent windows in the same project, they are effectively all working on the same files. One can edit code another is reading, overwrite a change, or see unfinished work and try to fix it. Separate conversations do not get separate workspaces.

In our case, unit testing became a recurring collision point. Agents working on different tasks shared the same test database. One suite could reset its tables while another was in the middle of checking them.

This created failures that looked like coding error at first. The agent spent time investigating its fixtures, only to eventually discover that the real issue is another agent clearing the database underneath it. An agent modifying another part of the FTUE caught exactly this situation and stopped further tests until verification could be coordinated.

For now, database checks need to take turns. The likely next step is to create multiple test environments and assign one to each agent. Separate working copies would help with file changes, but they would still collide if they pointed at the same test database. Merging those seperate workspace would also be time consuming.

I still like the possibility of moving several parts of StormTome forward at once. But opening another agent window also means coordinating that second agent to work with the first. And in many cases, unless the tasks are completely unrelated, ends up not being worth it.