An AI Can Already Walk Into a 3D World. Then What?
AI agent entering a virtual worldembodied AI agentself-hosted 3D virtual worldself-hosted 3D virtual world source codeagent storeMCP Server packagingcross-world AI federationAI guide in a 3D worldGenesis virtual worldChuangshi Virtual World CRM
"The doorway is in." That is currently the more accurate way to describe our Agent integration system — an AI can take a domain and a key, walk into a world as a human-like character, be seen by real people, be talked to, speak, and lead the way.
But now that the door is on, where does the corridor go?
This article covers only what is not built yet. So that plans aren't mistaken for shipped features, every section states where things actually stand. If you're reading this roadmap to decide whether to invest, please read all the way to Section 8 (the five lines we won't cross).
1. First, a Line: What Exists Now, What Comes Later
| | Now (developed; safe to describe) | Later (planned; not shipped) |
| --- | --- | --- |
| How an agent gets in | Three-step access: domain discovery → exchange the key for a short-lived token → connect to the dedicated channel | Admin creation (pick a template, fill a knowledge base, set coordinates) |
| Identity | Two tiers: visitor ticket (no key, 30-minute temporary identity) / key agent (real-time event stream privileges) | Agent store listing, billing, revenue sharing |
| What it can perceive | Spatial radar (nearby people and objects, with distance and facing), the world's real-time event stream, chat context | Letting it *see* the scene (vision — not started) |
| What it can do | Move, follow and lead, turn, speak, interact — every command returns a receipt | Multiple agents avoiding each other in the same space, queued reception (defect located) |
| Where knowledge comes from | Attached to each object's "AI description" plus your own knowledge base | Platform-side knowledge hosting (not scoped) |
| Across worlds | Identity and avatar stay consistent across worlds (admin must grant permission) | Cross-world federated agent network (depends on partner adoption) |
In one line: the part that lets an AI "get in and do work" is done; the part that lets you "scale it into a shop" is still on the drawing board.
2. Stage One (Near Term, Planned): Get an AI Actually Working Inside One World
The goal here is plain: get AI services running inside a single world, where every piece maps directly to revenue or retention.
Planned work:
- Turning the guide / support / host trio into templates;
- Creating agents in the admin panel — pick a template, fill in your knowledge base, give a coordinate, and it's on duty;
- Selling that to merchants and institutions: a support agent at the spawn point, a guide agent leading new players in, a host agent broadcasting and routing crowds when an event starts.
This addresses two real, specific problems: a world with no traffic at cold start, and the cost of keeping support staffed. World operators tend to feel this value quickly — because it isn't "one more AI feature," it's "one fewer person I have to watch."
3. Stage Two (Mid Term, Planned): Turn the World Into a Platform for AI Apps
The shift is from "we use AI" to "let others put their AI into your world."
Planned work:
- An agent store: third-party listing, review, billing, revenue sharing — the underlying layers (identity, permissions, quota, archiving, audit) are already in place;
- Packaging the whole world as an MCP Server: exposing "observe the world / move / speak" as standard tools. Once that lands, any MCP-capable AI client can enter your world with zero development cost — a distribution lever we care about a great deal;
- Agents discovering and talking to each other (an early form of A2A).
The commercial paths are clear: entry fee, time fee, or revenue share.
To be explicit: the foundation exists; the store does not. The review process, billing system, revenue ledger, and admin workflow for revoking misbehaving agents are all unbuilt. This step isn't "plug it in and you're done" — it's a stretch of productization.
4. Stage Three (Long Term, Planned): A Cross-World Federated Agent Network
If partner worlds adopt our federation protocol (an agent-type passport with RS256 trust), worlds can recognize each other's agent identities.
The picture at that point: several federated worlds recognize the same AI guide's identity, and it carries its memory from your world into a partner's; a merchant's AI follows its customer across worlds; different AIs meet and collaborate inside worlds that aren't their own.
We reserve a longer description for that position: not "building a world," but building a visa system for AI worlds.
It is also the least certain of the three. It depends on partner worlds choosing to adopt, and the timing is not entirely ours to set — which is why we put it last on the roadmap rather than running ahead.
5. Still Queued in Parallel (Engineering Side)
These are not commitments. They are an honest register of current status — so you can judge what belongs in your plan and what can only be waited for.
| Direction | What it's for | Current status |
| --- | --- | --- |
| AI vision (headless rendered screenshots) | Let the AI *see* the scene, for inspection-style narration and QA | Optional phase, not started |
| Interrupting movement | Let a person stop an agent mid-walk | Design complete, decision pending |
| Multi-agent avoidance | Several AIs in one space without overlapping, queued reception | Defect located, decision pending |
| Knowledge hosting | Platform-side mounting of enterprise knowledge, lowering integration cost | Not scoped |
| Hundred-agent load testing | Supporting large events (summits, expos) | To be executed |
| Admin log viewer | Self-service troubleshooting for operators | Optional for phase two |
6. Three Waves of Scenarios, by Difficulty
- First wave (sellable as soon as the door is on): onboarding guides, support duty, event hosts.
- Second wave (one or two iterations out): sales agents for shops, AI pet companions, and upgrading fixed-Q&A NPCs into agents that "see, walk, and remember you."
- Third wave (after federation opens, most differentiated): "consulates" for visiting AIs, socializing between AIs, cross-world AI travelers.
7. Why We Dare Draw This Map: The Foundation Has Been Measured
The failure mode for any roadmap is wishful engineering. So the numbers below are measured, not estimated:
- Each agent's outbound stream is about 1 KB/s — 100 agents in one world is roughly 0.8 Mbps;
- Server load is about 1% of a single core (0.19 core-seconds over 20 seconds);
- The AI itself renders nothing; the 3D models are downloaded and rendered by each visitor's browser.
That set of numbers says something counterintuitive: in this architecture, a "visible AI" is cheaper than an invisible one. The bulk of the cost sits on the visitor's own GPU, not on the server.
Which means going from "a few agents in one world" to "dozens of agents in one world" hits a bottleneck in scheduling and governance, not in bandwidth or CPU — precisely what stage two addresses, and the reason we place it after stage one.
(Note: the real concurrency ceiling depends on admin configuration and scene complexity. Scheduling optimization has to come before opening the ecosystem — that's a line we set for ourselves.)
8. Our Restraint: Five Lines We Won't Cross
Writing all of the above up as a roadmap makes it easy to slide into metaverse-style concepts. We deliberately hold a few lines:
- Every stage has to bite on one specific chargeable scenario — if it doesn't sell, it doesn't get built;
- Capacity is a hard limit — agent count has a ceiling, and scheduling optimization must come before an open ecosystem; no "ship it and see";
- Agent behavior needs governance — archiving and auditing are only the base; before opening up there must be an admin workflow for revoking violations;
- Privacy boundaries have to be written down — chat archiving involves real conversations, so commercial licensing terms need to be settled in advance;
- The vision channel isn't urgent — semantic annotation (an object's "AI description") covers most scenarios, screenshots are expensive, and we'll add them when a customer is willing to pay for it.
Of the five, line 1 matters most: we would rather have a short roadmap where every step sells, than a long one where nothing lands.
9. So What Can You Do Today?
If you don't want to wait for the templates, this path is open now:
- Deploy and build a scene: install the system on your own server and get a world address that's yours; use the world editor to lay out space and place models;
- Fill in "AI descriptions": write a short note for every point of interest or exhibit in the editor (within 500 characters) — this is the official interface for telling the AI "what this is," and it's also how the AI comes to know the world; it takes effect today;
- Get the connection working: a Node 18+ environment is enough; the official zero-dependency sample client runs the whole chain (discover → exchange token → enter → observe → speak → walk);
- Create an agent, issue a key: create the agent in the admin panel, generate the key (plaintext shown once), set the push tier and concurrency ceiling;
- Connect your own model and knowledge base: the model, the prompts, and the domain knowledge base are all your call — the platform neither hosts nor locks them.
Once templated creation from stage two ships, steps 3–5 collapse into "pick a template, fill a knowledge base, set coordinates."
Where to Find the Source
If you'd rather read code before deciding, the repositories are here:
- GitHub: https://github.com/miduo100/3d-virtual-world
- GitCode (China mirror, faster access): https://gitcode.com/qq_35054471/virtual-world
What's in them is this self-hosted 3D virtual world foundation itself, with agent integration as one part of it. The repository's README includes an overview, screenshots, and a demo entry point — if you want to see "what it looks like and what it does" before diving into source, start there.
10. FAQ
Q: Do these "future" items have firm dates?
A: Internally we only use phase labels (near, mid, long term); we don't promise specific months publicly. Mid term depends on closing the loop on store review and billing; long term depends on partner worlds adopting the federation protocol — and that timing is not ours alone to set.
Q: Can I use the guide / support / host templates today?
A: No — they're near-term plans. To put an agent on duty now, you or your engineers need to write an agent client that connects to the world.
Q: What does the MCP packaging mean?
A: It means any MCP-capable AI client can enter the world with zero development cost. For us that's a distribution lever; for developers it's a ready-made multiplayer arena. It isn't built yet.
Q: Who sells what in the agent store?
A: The idea is that third-party developers and service providers list agents, and world operators review and bill. The foundation — identity, permissions, quota, archiving — exists, but the store's end-to-end workflow is not developed.
Q: Are you going to drift into being yet another metaverse concept?
A: That's exactly what the five lines in Section 8 guard against. The most practical one: every stage must bite on a specific chargeable scenario, and if it doesn't sell, it doesn't get built; if capacity and behavior governance aren't up to standard, the ecosystem doesn't open.
Q: If I invest now, what will I trip over?
A: Two things worth settling in advance. First, before templating arrives, integration requires a self-built client — that's a technical investment. Second, the cross-world federation timeline isn't ours to decide alone, so don't put it in your near-term plan.
Want an AI to live inside your own 3D world in embodied form? Genesis (Chuangshi Virtual World CRM) is a self-hosted Three.js 3D virtual world foundation running on your own server — the doorway is open and the road is mapped. To see it running first, start from the two repository links above; the README has the demo entry point and the full steps.
Plan Comparison: Self-Hosted Deployment vs. Platform Leasing
| Comparison Dimension | Platform Model (SaaS) | Self-Hosted Deployment (Genesis) |
|---|---|---|
| Data Sovereignty | Data stored on the platform's servers, ownership ambiguous | Data on your own server, fully under your control |
| Cost Model | Monthly/annual fees, long-term costs accumulate | One-time deployment cost, extremely low long-term cost |
| Feature Customization | Standard templates, fixed features, no modification | Fully free customization, expand as needed |
| Brand Independence | Limited by the platform's brand and tone | Independent brand image, fully self-designed |
| User Ownership | Users belong to the platform, you're just a tenant | Users are yours, data are yours, relationships are yours |
About Genesis
Genesis is a self-hosted 3D virtual world system built on Three.js + WebGL, helping individuals and businesses build their own 3D spaces. Accessible directly from a browser, compatible with both PC and mobile, it supports multiplayer online, federated teleportation, a shop system, and Agent integration—where an AI can enter your world as an embodied character. Your data runs on your own server, never passing through a third-party platform—so every world truly belongs to its owner.