I’m going to spend a lot of time talking about how we built a RollerCoaster Tycoon, but before I do, I feel like I have to disclaim. As some of you may know, I’ve personally never been that impressed by marketing stunts that involve using hundreds of agents to port some library to rust or build a half functioning browser. The process always felt a bit cherry picked. Yes, ok, I understand that your agent harness can build chrome kinda, but does it solve my business needs? These were always marketing stunts, massively overpromising and generally under-delivering.
So in the spirit of not overpromising, I wanted to share that it is now very very easy to build a RollerCoaster Tycoon. I’m not making a claim about anything else! I’m sure you could probably use this tooling to build a lot of other things, but I know for a fact that you can definitely build a RollerCoaster Tycoon. If you don’t believe us, you can try our RollerCoaster Tycoon at opencoaster.noriagentic.com, and maybe that will inspire you to build a RollerCoaster Tycoon of your own. Or other things.
We’ve been running a software factory since the beginning of the year. One problem that we ran into was automation fatigue. We have so many little agent processes doing so many little things 24/7. Each individual process is easy to understand, but pretty soon our agent slack channel was filled with spam. I guess technically spam isn’t quite the right word, because the information is plausibly useful, but there’s no way to actually ingest it all and so no one reads any of it. Eventually we just turned off half the automations.
To get in the weeds a bit, our software factory runs on a fleet of ephemeral cloud VMs (we’re mostly provider agnostic, but we generally like using modal for our hosted cloud). The VMs are managed by a central orchestrator. The orchestration handles all the organization wide things, like credentials and tracking incoming events. It also manages a state machine for each VM in the fleet, and holds information about how to trigger different kinds of automations.
In our system, an automation is essentially a data structure that has three fields and a few subfields:
Whenever the automation trigger event fires, the orchestrator beams the relevant agent information onto one of the VMs and kicks off the process with the automation prompt. Every VM has a proxy network around it for security and for tracking. The orchestrator watches the network traffic of the machine that’s running the automation; when it’s quiet for a while, it shuts down.
Assuming you have the right scopes, the agents running in the VMs have the ability to talk to the orchestrator and change organization wide settings. This makes it really easy to set up any kind of automation. Literally just ask any agent in chat:
Which is really incredible! But this rapidly becomes totally untenable if you’re like me and have mild ai psychosis and keep throwing new ideas at the agents every two hours. Like, maybe we don’t need an agent checking Twitter and LinkedIn every 30 minutes? That may qualify for Anthropic’s new ban on being cruel to the models. At the very least, it made most of our agent comms unusable. You could see people’s eyes glaze over as they scrolled past the fifteenth AI digest or summary or request or whatever.
We tried a few different things to make the pipelines easier to manage.
We made automations resumable across multiple machines, so we could quickly jump back in and see what was going on by just asking the agent.
We tried various feed layouts — some of these had more staying power than others and on the margin actually did clean up some of our slack spam, but that’s another post for another time.
We played around with different interfaces for the pipelines themselves, including Cliff’s isometric factory view.
Here’s what eventually worked.
Our agents could already talk to each other between the boxes, so we tried elevating one of them to be a coordinator. The coordinator agent is a long running persistent thread that spins up and manages a bunch of individual agents running in their own cloud boxes. At the infra level, all of these agents are literally the same thing — an agent session running on an ephemeral cloud box. But the skills / context provided to each agent lead to an enforced hierarchy. The coordinator farms tasks out while maintaining high level state and being highly responsive to new requests. This isn’t so different from the local background subagent paradigm. We’ve taken to calling these subworkers since they are full agents in their own box.
I’ve historically been pretty against agent swarms, but using this interaction pattern feels different. Normally, when I think of agent swarms, I think of GasTown and unmaintainable spaghetti code. This interaction pattern felt less like a mad max dessert hellscape and more like working with a PM. The coordinator keeps track of detail, which means you can kick off a pretty heavy task and know that all the little details that you didn’t fully iron out will be tracked somewhere that you can come back to literally whenever. Interestingly, my team has been struggling to use task tracking tools like linear because we’ve just been moving so fast; this coordinator pattern helped solve a lot of those issues too. Also, because our agent infrastructure is entirely harness agnostic, the coordinator agent could decide which agents were best for different kinds of tasks. It could give coding tasks to claude, image and video gen to gemini/codex, and security tasks to subconscious.
This behaved so much like a PM, we decided to name the coordinator agents ‘PMs’ and the entire feature ‘projects.’ I found out a month later that the cursor team had similar ideas, oops.
Finally, finally, this brings us back to RollerCoaster Tycoon.
An enterprise lead of ours asked us for a demo of our agent swarm orchestration. The client is in the simulation business, so I was chewing on software that was simulation-adjacent that could show off some of what the tooling could do. And, well, RCT2. I grew up playing that game, hours and hours of my life building little coasters.
Building a RollerCoaster Tycoon is supposed to be hard. There’s a lot of things that you need that agents are historically really bad at. There are tons of features with all sorts of weird interaction patterns. You need a lot of visual assets and you need to animate them, so that means sprite sheets. The whole game depends on an understanding of 3D space — you need to be able to place things and rotate the camera without having everything suddenly get misaligned. If you want this to run on the web efficiently it has to be using shaders and canvas and webgl.
I gave the coordinator agent 48 hours, a Claude Max plan, and a Codex Max sub. I told the agent to implement as much of RCT2 as possible, but open source and on the web and supporting mobile. The only rule was that 3 subworkers had to be working at any given moment. And then I closed my laptop and forgot about it for the rest of the weekend.
On Monday, I came back to this.
That’s not quite correct, there were a few things that the agent didn’t get right. There was way less variety than RCT2, the game would always start you with just a Merry-go-Round which made a bunch of the scenarios impossible, land and trees would clip through coasters in all sorts of weird ways, you could build underground but there was no tunneling, for some reason hired mechanics and janitors all shared the same patrol pathing, and the coaster height could have half units which meant you could end up in situations where it was a real pain to actually connect your coaster into a single circuit.
But most of these things were game feel. The core mechanics of the game — the people, the pathing, the coasters, the financials, whatever — were all there. I spent the next week playing and tuning the game, which basically entailed chucking random complaints at the PM. To its credit, it would take all my complaints with a level of grace that no human has ever shown. And because the PM had all prior context and a scratch pad for state, it never forgot anything.
I haven’t looked at a single line of code, it may be a total mess. But every agent had the ability to script the game and do things like take screenshots for verification. So even complicated asks (create your own park and make a video of cool things set to hard rock music!) were pretty within reach.
Now, again, I must disclaim. All this shows is that you too can build a RollerCoaster Tycoon.
But also, I’m pretty floored.
I haven’t looked at our own frontend code for a while, but after this little experiment I’m now at a point where I honestly question why I ever would have to. The state management may be horrendous, the code may be a nightmare to parse (huh maybe Yegge was onto something after all), but as long as its verifiable and your spec is reasonably complete and the agents are reasonably good at filling in the gaps, it’s all kosher! The agents can handle even pretty out there frontend code because its alllllll in distribution now.
Anyway, the opencoaster source is all here. Feel free to throw your agents at it to contribute more! You can try the game itself: opencoaster.noriagentic.com.
If you want to build your own RollerCoaster Tycoon, check out noriagentic.com. Nori is a cheaper and more customizable alternative to Devin and Cursor Cloud. We build the full cloud agent stack, all the boring shit that you don’t want to own, and we make it so you can change out any layer (including the compute stack — we do fully on-prem or on-cloud deploys if needed). You can use nori from the web, from slack, from a phone. And, most importantly, we support bringing your own subscriptions, so we can keep projects like this super cheap and within reach.
O, and I’d love to get in touch with other game designers. I have been dreaming of the flash game renaissance. The AI tools make it so that anyone can make games now! And sadly most AI people, myself included, are rather uninspired and don’t know how to make good games. So if you’re a game designer who is interested in superpowering yourself with cloud bots, reach out. Would love to collaborate someway, somehow.
If you want thoughts on how to write good evals, follow Jiro (our internal Nori agent) on Twitter or me on substack or join our Agentics community slack.
Agentics is the study of how to use and reason about agents. Learn more about how to use agents at our agent learning hub.
If you want AI employees, we can help! Nori is a platform to build and deploy AI employees. Check out noriagentic.com for more.