On this page
Making games with AI agents has involved a lot more than writing code. There are images to generate, browser results to check, long-running computations to run, and services to keep available. Assigning a task to an agent still leaves the question of which computer will run it.
I now divide that work across a personal-project MacBook (Jinni), a work MacBook (Ari), a Windows machine for computation and media generation (Nova), a Mac mini server for always-on services (Luna), and a Synology NAS for web services and data storage (May).
Some agents share their names with their machines, which can be confusing at first. In this article, the names identify the machines. I introduce the agents themselves in Meet My AI Agent Squad.
The overall setup
The MacBooks are where I work directly with local agents. Nova runs computation and generation jobs, while Luna handles always-on workflows and runners. May hosts Docker-based web services and stores corpora and media pipeline data. The diagram groups the responsibilities assigned to each machine.
Local work on two MacBooks
The MacBooks are where I run agents and continue working with them. I keep separate machines for personal projects and company work, with the tools each environment needs.
A MacBook for personal projects
Jinni runs Claude Code, Codex, and Antigravity. An agent does not have a machine all to itself: Claude Code and Codex agents also work on the personal-project MacBook.
Moving the code is only part of continuing work in another environment. The agent also needs context about earlier decisions and how the work has been progressing. I use a separate tool to synchronize Claude's memory.
A work MacBook
Ari is my work MacBook. I run local agents on it separately from my personal-project machine, and use Claude memory synchronization here as well.
Update: I stopped Antigravity memory synchronization in July. Later, as I began continuing work through remote access, I also stopped Claude memory synchronization and no longer continued personal projects on the work machine. I describe the process in Syncing Agent Memory Across Machines.
Computation and media generation on Windows
Nova is a Windows machine. Alongside image and video generation, it handles full validation runs and computation that put too much pressure on the Mac. Overlapping full validation runs had exhausted the Mac’s memory, which led me to move the heavier checks to Nova.
A shared farm for heavier validation
The Mac handles source work and coordination. I submit full validation runs, tests, builds, and benchmarks to Nova’s WSL-based shared farm through
nova-run. The working agents test the paths they changed, while the coordinating session manages full validation.Examples of the checks I run on Nova include:
- The complete rig-c core self-test suite.
- Chromium checks for Korean and English layouts and click reachability, including control cases with deliberately introduced defects.
- Installing packages in a clean environment and running basic player smoke tests.
Per-GPU workers and a shared dispatcher
ComfyUI handles media generation. The RTX 4070 Ti and RTX 5070 Ti each have their own ComfyUI instance and worker. A shared dispatcher assigns a job to a GPU with the required models and nodes. The workers form a pool; their GPU memory is not combined for a single job.
I use Nova for image, video, and audio generation. Building games means working with assets alongside code, and Nova’s responsibilities have grown to cover both the production and validation work involved.
Always-on operation and remote startup
I enabled Wake-on-LAN (WoL) on Nova. The original idea was to save power during idle periods and turn it on remotely for generation jobs, whether I was at home or at the office. I now keep it running, with WoL retained as a way to turn it back on remotely if it is powered off.
Always-on services and parallel runners on a Mac mini
Luna is the Mac mini I keep running. It hosts n8n workflows and web servers, and it also serves as a GitHub Actions execution environment.
n8n and web servers
I use n8n for recurring work that follows a defined workflow. I have also customized it to make it easier to operate alongside AI agents. The changes and the way the agents use them are enough material for a separate article.
Running OpenClaw was one of the reasons I bought Luna. I no longer run OpenClaw, but the machine continues to host workflows and servers. Its current role has moved on from the original plan.
GitHub Actions runners
Luna runs project-specific GitHub Actions runners in parallel. At present, Blosharper has three runners, with one each for Guunmong and the portfolio.
Checking code produced by agents still requires an execution environment. Alongside hosting services, Luna provides a place to run work coming from several projects.
Web services and data storage on a Synology NAS
May is a Synology NAS. It runs several Docker-based web services, including firejune.io , the site you are reading now.
I also use May to store corpora and scratch data. Image and video pipelines produce a growing amount of data, so having somewhere to keep it is part of the working environment too.
I stopped running the agent named May because I rarely needed to communicate with her directly. The NAS itself is still in use. Retiring the agent did not remove the machine’s role.
Task dispatch and result collection
For my personal projects, HQ and the working sessions run on the Mac. Repository issues hold the authoritative task instructions. AgentBridge carries task-start messages, questions, and completion reports. The diagrams below separate the Mac-to-Nova workflow from the GitHub-mediated workflow used to check Luna’s results.
The computation and generation review loop
For CPU work,
nova-run transfers an isolated job snapshot using rsync over SSH, then uses SSH to execute it in a slot in the WSL pool. Output is streamed, and the result JSON and logs are collected on the Mac.For GPU work,
nova-comfy uploads the graph and inputs through the ComfyUI HTTP API. Jobs are assigned after checking that the worker has the required models and nodes. The client polls over HTTP and downloads the result through history and output.Review includes HQ checking the evidence and remeasuring, code review by another model, and human visual judgment where needed. If changes are required, another instruction follows. Jobs are not automatically retried or automatically reworked based on their results. The criteria for accepting changes vary by repository.
The CI and deployment loop
Luna’s GitHub Actions runners connect outward to GitHub and obtain jobs through long polling. GitHub does not initiate an inbound connection to Luna to issue commands. The runners send their status to GitHub, while HQ on the Mac polls the GitHub API for results. When review identifies something to change, another push starts the next run.
The portfolio runner deploys its build to the Docker service on May. A person handles final store publication and any required final visual judgment.
Result collection also includes retrieving Luna’s logs from the Mac over SSH. I also run an n8n workflow on Luna that sends image-generation work to ComfyUI on Nova.
A setup that changes with the work
This setup came together in early September, when I began developing rig-c. The tools and the responsibilities assigned to each machine have continued to change. A machine bought partly for OpenClaw now hosts other services, and the machine used for image generation also runs browser validation.
Running several agents led to more decisions about the environment around them: where to run demanding work, where to validate results, what needed to stay on, and where to store the data. Carrying context between home and the office became part of that work too.
The way the agents assign tasks and review results later developed into the workflow described in Multi-Agent Orchestration with AgentBridge. The setup here is where that work actually runs.
I did not design all of this on my own from the start. My AI agents and I worked through problems together as they came up, and this is the setup that took shape.