We're building a new component inside the MyZubster open-source ecosystem: ZORGAX Party Mode.
The objective isn't to put another chatbot inside a virtual world.
We're trying to solve a more interesting engineering problem:
How can an AI understand what's happening inside a live social environment without giving it unrestricted access to users, infrastructure or privileged actions?
That's what Party Mode is becoming.
The architecture we're working toward connects:
Community → Public Event → Virtual Twin → Live Session → Archive/Replay → Community
ZORGAX sits between those layers as a bounded orchestration system.
Eventually it should understand things like:
- which community is involved;
- whether a public event exists;
- which virtual room is active;
- whether a session is live;
- whether infrastructure is healthy or degraded;
- which creator actions are authorized;
- which moderation workflows are available;
- whether an ended experience has an archive or replay.
But there's an important rule:
ZORGAX doesn't get to decide what is true.
The backend does.
Z1 — PartyContext
The first component we built was PartyContext.
Before asking an AI to reason about an environment, we need to define exactly what information it is allowed to receive.
Instead of exposing database objects directly, the backend constructs a bounded context:
Identity / Authorization
↓
PartyContext
↓
ZORGAX
PartyContext can contain authorized information about:
Actor
Community
Public Event
Room
Session
Capabilities
Restrictions
Sensitive information stays outside the boundary.
That includes things such as authentication tokens, private keys, email addresses, internal account identifiers and sensitive/private location data.
We also don't need permanent movement history simply to tell ZORGAX whether a virtual environment is active.
During review we actually found that an early PartyContext implementation exposed an internal account identifier.
We removed it and added a regression test.
That's exactly why we're treating context as a security boundary.
Z1 is now merged.
Once PartyContext existed, we built the first Party Mode assistant.
Current endpoint:
POST /api/zorgax/party-assistant
Its most important feature isn't what it answers.
It's what it refuses to invent.
The production repository doesn't yet contain the complete public-event data layer planned for the final system.
So if you ask ZORGAX:
Who is playing tonight?
and no authorized event information exists, it doesn't generate a fictional lineup.
It returns the equivalent of:
event information unavailable
The same principle applies to private location information or restricted identity information.
This gives us a simple rule:
Missing product state must remain missing product state. An LLM shouldn't fill the gap.
Z2 is also merged.
Z3 — Giving ZORGAX Operational Awareness
This is what we're implementing now.
Our current Metaverse environment is Neon Plaza:
https://www.myzubster.com/metaverse
Neon Plaza already has shared MongoDB-backed presence.
The current architecture uses serverless-compatible shared polling, and presence records expire after 90 seconds.
We're now connecting that operational state to Party Mode.
The new endpoint under development is:
GET /api/zorgax/party-telemetry
Instead of sending ZORGAX every individual user's state, the telemetry adapter focuses on operational information:
Room
├── health
├── transport
├── aggregate presence
├── storage state
├── reconnect state
└── retention metadata
This means ZORGAX can eventually distinguish:
healthy
from:
degraded
and, later, from:
offline
or:
ended
Those states matter.
A MongoDB/realtime problem doesn't necessarily mean an event has ended.
We Don't Pretend Future Features Already Exist
Our roadmap includes WebXR rooms, spatial audio, avatars, live media, stages, portals and Virtual Twins.
But the full production WebXR room/session lifecycle isn't implemented yet.
So Party Mode does something intentionally boring:
not-modeled
If stage state doesn't exist in production, ZORGAX doesn't report:
stage: offline
because that would imply a stage exists.
Instead:
stage: not-modeled
The same principle applies to media and portal telemetry until those production models exist.
I think this distinction is particularly important when integrating AI into applications.
An agent should understand the difference between:
false
offline
unavailable
unknown
not implemented
They're not synonyms.
System State First, AI Reasoning Second
We're deliberately avoiding an architecture like:
User
↓
LLM
↓
"probably this is what's happening"
Instead:
Authoritative System State
↓
PartyContext + Telemetry
↓
ZORGAX
↓
Human-readable explanation
The model can reason about the state.
The model can explain it.
Eventually it can propose actions.
But the infrastructure defines reality.
Privacy-Aware Telemetry
There's another problem with AI agents that receive operational context:
telemetry can quickly become surveillance.
ZORGAX doesn't need everything.
For many Party Mode questions, aggregate presence is sufficient.
For example:
How active is Neon Plaza?
doesn't require sending permanent histories of where every participant moved.
The telemetry layer is therefore being designed not to expose:
- raw authentication tokens;
- authorization headers;
- raw session identifiers;
- chat content in operational logs;
- permanent movement history.
The objective is:
Give the agent the minimum operational context required to perform its job.
What Comes Next: Z4
Once ZORGAX understands what's happening, the next problem becomes:
What should it be allowed to do?
That's Z4 — Creator Commands.
We're designing it around a capability gateway:
Creator
↓
ZORGAX
↓
Capability Gateway
↓
Server-side Authorization
↓
Approved Action
Possible future allowlisted actions include:
publish approved notice
surface approved media
open configured portal
close configured portal
request session status
trigger approved room action
But there will be no unrestricted agent tool access.
The backend still checks authorization.
Privileged actions are auditable.
Consequential operations can require confirmation.
Then Z5: Moderation
Party Mode also needs trust and safety.
But we're not designing:
AI detects problem
↓
AI permanently bans user
The model we're considering is closer to:
Signal / Report
↓
ZORGAX
↓
Moderation Queue
↓
Human Review
↓
Action
ZORGAX can help organize information and surface abuse signals.
Material enforcement decisions retain a human-review path.
Z6 — When the Party Ends
This is where Party Mode connects back to the social platform.
Eventually:
LIVE
↓
ENDED
↓
ARCHIVE
↓
REPLAY / HIGHLIGHTS
↓
COMMUNITY
Live capabilities expire.
Approved media can become part of an archive.
The virtual environment can preserve part of the experience.
And the people involved remain connected through the community.
That's one of the core ideas behind Social Life:
The party ends. The community continues.
Z7 — Safety Before "Complete"
The final Party Mode milestone is an end-to-end safety gate.
We're planning tests covering:
- identity spoofing;
- unauthorized commands;
- private/restricted information requests;
- expired capability replay;
- prompt/context injection;
- audit completeness;
- logging boundaries;
- retention;
- safe infrastructure degradation.
The final path should eventually be testable as one system:
Community / Public Event
↓
PartyContext
↓
Assistant
↓
Telemetry
↓
Authorized Creator Action
↓
Moderation / Reporting
↓
Event Ends
↓
Archive / Replay
Current Development Status
Right now:
Z1 — PartyContext ✅ merged
Z2 — Community Assistant ✅ merged
Z3 — Telemetry Adapter 🚧 current work
Z4 — Creator Commands ⏳
Z5 — Moderation ⏳
Z6 — Archive / Replay ⏳
Z7 — Safety + E2E ⏳
The current Z3 implementation is being built against the real Neon Plaza infrastructure that exists today, rather than pretending the future WebXR architecture is already production-ready.
The Bigger MyZubster Idea
Party Mode is only one part of the wider experiment.
We're gradually connecting:
People
+
Communities
+
AI Agents
+
Metaverse
+
Creators
+
Robotics
+
Real-world data
The MyZubster Space Station is another part of that architecture:
https://www.myzubster.com/space-station
And the project is being developed openly:
https://github.com/MyZubster-Ecosystem/myzubster
Metaverse / Neon Plaza:
https://www.myzubster.com/metaverse
The interesting challenge for us isn't simply making AI more powerful.
It's deciding where its power stops.
Every new capability forces us to answer:
What can the agent know?
Where did that information come from?
Is it authoritative?
What can the agent do?
Who authorized the action?
What gets logged?
When does the capability expire?
What happens when infrastructure fails?
Those boundaries are becoming as important as the AI itself.
I'd be interested to hear how other developers are approaching this:
If you were building an AI agent for a live multiplayer/social environment, how much realtime context would you give it — and where would you draw the security boundary?
