Forge learns teamwork: many agents at once

From "one Forge" to "a team"

Until now, when Forge took a request it basically did it step by step on its own: plan, write code, verify, one after another. Fine for small tasks, but when a request is large and splits into several independent chunks, serial becomes the bottleneck — things that could run at once are stuck queuing. This day introduced a multi-agent Team mode: Forge can raise a number of "teammate" agents who share one task board, each claiming and progressing in parallel, then folding results back together. Technically this is several things working in concert: an executor that can truly run teammates concurrently, an in-process "mailbox" letting teammates message one another, and a shared task table everyone can see, claim from and keep consistent. It upgrades "directing one AI" into "directing a team of AI."

On by default, with a "coordinator view"

Team mode is on by default as of this day (with a switch kept, so you can drop back to a single agent anytime). To keep "a crowd of agents at work" from becoming an unreadable tangle, it comes with a "coordinator view": a coordinator breaks work into tasks, assigns them and watches progress, and from this view you can see clearly "who's doing what right now, and how far along." At the same time, the system hints to participating agents, when appropriate, that "you're in team mode," so their behavior differs from working solo — knowing to claim tasks off the board and collaborate, rather than each going their own way and duplicating effort. On by default means this isn't an experiment tucked in a corner, but one of Forge's default ways of working from this day on.

The editor: a single mesh now stays put in the scene

The editor filled in a key piece of reliability. Previously, after placing a standalone mesh into the scene, its "scene asset" wasn't saved to disk reliably, so on reopening the project or hitting ▶ to playtest, the thing might vanish or fail to render. This day made single-mesh scene assets write back to disk and persist correctly: what you placed is still there after closing and reopening, and renders as usual when you switch to playtest. It also restores a mesh's original glTF materials when you drag it in, instead of turning into an untextured gray blob. For a what-you-see-is-what-you-get editing experience, "what I placed stays there" is the most basic trust — and this day completed it.

A first packaging UI + taking over from your phone

Two more things make "taking your work with you, watching it anytime" smoother. First, a first packaging UI appears in the editor's top bar: the target platform for packaging, the engine-root selection, history and other options moved onto a visible UI (bilingual, too), bringing "export the game into a distributable build" a step closer from the command line toward a graphical interface. Second, a "scan a QR to take over from your phone" capability arrived: scan a code and you can send and receive messages with a working agent on your phone — step away from the desk and still glance at progress or add an instruction. Both point the same way: don't pin creation to one fixed place — easily carry the build out, and hold control of it in your hand.

Steadier: chat no longer freezes + real-process tests

Reliability wasn't left behind either. The chat interface fixed a problem where parsing certain complex Markdown formatting could fall into an infinite loop and eventually eat all memory and freeze — so pasting in oddly formatted content won't drag the conversation window down anymore. Underneath, a batch of "real-process" end-to-end tests was added: no longer just running in an ideal setting, but actually launching the program as a full process, covering key paths like crash recovery, context compaction, background residency and the command-line interface. Tests are invisible day to day, but they're where the confidence to "dare to change things, knowing a change won't quietly break" comes from — one more layer of real testing is one more safety cushion for moving forward.

Everyday commands consolidate to one entry: bun fx

This day also consolidated the project's everyday operational commands: the previously scattered setup / start / stop scripts now live under a single entry, bun fx <command>, and running bun fx on its own prints help for every available command. The common ones: bun fx setup (prepare the environment the first time), bun fx update (only pull the latest root code and sync submodules — no longer also reinstalling deps or rebuilding plugins, so it's narrower and faster), bun fx start (web mode by default), bun fx start app (desktop mode), plus bun fx stop / bun fx restart. Collapsing to one entry means that on macOS, Linux or Windows you only need to remember bun fx; it also untangles "update the code" from "set up the environment" — so pulling daily updates is lighter and less likely to trigger a full reinstall by accident. The README, dev docs and public-site instructions are all synced to this new entry.

What this day means

The keyword of this day is "scale up." Before it, Forge's throughput ceiling was "how fast one agent can work"; with Team mode, that ceiling rises to "how much a team can do in parallel" — a qualitative leap from solo to team, meaning the larger and more splittable a request is, the more it can be pushed at once and finished faster. Around that core, the day steadied several experiences: what you place in the editor stays, the build can be packaged out from the UI, you can keep directing from your phone away from the desk, and chat no longer freezes on odd formatting. Scaling the AI's throughput from "one" to "a team" on one side, and tightening every corner of the daily experience on the other — the ceiling of capability and the floor of experience both rose a notch this day.