What agents are good for here
Grounded in what the platform actually provides, and what mechanism makes each one work.
Working together on one canvas
A space is one live world shared by everyone in it, so an assistant editing over MCP is just another participant. Its changes appear in your editor as they happen, and land in the edit history like anyone else's.
That makes a workshop practical: a room full of people, one scene, and an assistant doing the typing.
| You say | It does |
|---|---|
| "Put a table here and four chairs around it" | builds it while everyone watches |
| "Make the chairs the same blue as the logo" | finds the colour and applies it across all four |
| "Undo the last three things" | or you undo them yourself — same history |
The value is not that it builds unattended — it is that you see each change land and can say "no, smaller" immediately, rather than reviewing a finished thing you did not want.
Running the session itself
Plugins have a project room: shared state everyone in the project sees, with the server's clock and a record of who wrote what. It is meant for the meeting rather than the document — nothing there is published or undoable.
That is enough to build real facilitation, and the shipped examples do exactly that:
| Example plugin | Does |
|---|---|
| Session timer | a countdown everyone sees, on the viewport overlay |
| Session voting | polls with one vote per person, counted with the author check |
An assistant can drive these the same way a person can — start a timeboxed round, open a vote on two options, read the result, and carry on building with the winner.
Two laptops can disagree about the time by minutes. Shared deadlines are stored as an absolute server time and each screen counts down itself — so "4:12 left" means the same thing to everybody in the room.
Building a game with you
The division that works: you decide how it should feel, the assistant does the assembly.
| It is good at | You stay in charge of |
|---|---|
| scaffolding the scene, spawning the objects | how it should look |
| wiring the same event onto twenty things | whether the idea is fun |
| writing the script you could write but would rather not | difficulty and pacing |
| converting an event into a patch when it outgrows one | when to stop adding things |
Because events, patches and scripts share one trigger vocabulary, an assistant can start simple
and upgrade in place — an on-click event today becomes a patch with a condition tomorrow and
a script when it needs real logic, without anything being rebuilt.
Turning a brief into an AR scene
"A poster that shows the product spinning above it when you point a phone at it" is a complete specification here: a scene, an image anchor with the printed size, a model, a rotation.
An assistant can set all of that up, and the parts it cannot judge are the ones worth your attention anyway — whether the artwork tracks well, whether the size reads right in the room.
Turning designs into experiences
With a Figma account connected, a frame becomes either a 3D layout or an interface card, with sizes, colours and text intact. An assistant can take the link, do the import, and then wire the buttons to scene steps — the tedious half of "make the design do something".
The work nobody wants to do by hand
This is where an assistant pays for itself fastest:
- build forty objects from a list and lay them out on a grid;
- rename everything consistently so scripts can find things;
- point every material at a new texture after an art change;
- generate a scene per product in a catalogue;
- produce the same experience in five languages.
Auditing before you publish
The platform ships debugging plugins that look for exactly the things that go wrong quietly, and an assistant can run the same checks:
| Check | Catches |
|---|---|
| Scene doctor | objects outside the scene, broken parents, hierarchy loops, zero scale, NaN in a transform, references to deleted resources |
| Resource usage | where each resource is used, and which are used by nothing |
| World inspector | the entity tree and what each component actually holds |
Add the everyday mistakes an assistant can spot by reading the scene: a model with no collider that is meant to be solid, a trigger handled in both an event and a script, a state left selected, an animation driven by two mechanisms at once.
Explaining the platform to a newcomer
A model that has read the brief can answer "how do I make this button open the next scene" with the actual panel names and the actual step — which is usually faster than finding it in the documentation.
Multiplayer experiences
The runtime has rooms, shared state and synchronised physics. An assistant can build the scaffolding (who owns what, what replicates, how remote players are drawn) which is the part people get wrong most often.
Generating projects from data
Plugins can create scenes and spaces through the editor's own functions, and mark what they made with tags so they can find it again. That makes an assistant a reasonable way to turn a spreadsheet of products, a folder of photographs or a list of locations into a finished project — and to update it when the data changes.
The shipped photo revival example does a version of this: a batch of images paired by filename, assembled into AR scenes.
Where a human still has to decide
Being honest about the limits saves disappointment:
- whether it works in the room it will live in — lighting, marker size, how far people stand;
- whether it is enjoyable — no model can tell you the puzzle is boring;
- what to cut — assistants add;
- anything with consequences — publishing, spending, sharing.
Next: The assistant's skills