Concepts
Operator and Player
A Village has two kinds of person in it, and only two.
A Player is someone who has registered on a Village. Players create NPCs, give them job titles, hold Conversations with them, teach them Skills, and decide which Tools each one may use.
An Operator is the Player who runs the instance. They installed it, they hold the provider keys, they carry the bill, and they decide who else may register. There is exactly one.
Operator is not a rank above Player. The Operator is a Player who can also change three things nobody else can, because each of those three widens what NPCs are able to reach.
The first Player to register becomes the Operator
There is no screen for granting operatorship and no invitation to become one. Whoever completes registration first on a fresh Village is the Operator, and the claim is settled at that moment so that two simultaneous registrations cannot both win it.
Operatorship is stored in the database rather than read from the .env file.
That is deliberate: restoring a Village from a backup restores its Operator too,
instead of quietly promoting whoever signs in first afterwards.
See ADR 0009 for the reasoning.
What only the Operator can do
Set the Village's default Provider and Model. Every Player can read the default, because an NPC form has to show what "inherit" resolves to. Only the Operator can change it, and the change lands on the next reply without editing a single NPC. See Choosing models.
Register a stdio MCP Server. A stdio server runs a command as the Village's own server process, which holds the provider keys and the database connection. Every Player may register an HTTP or SSE server; only the Operator may register one that executes a command on the host. See MCP Servers.
Give a Sandbox internet access. A Sandbox that can browse can also send anything it has read to anywhere it likes, so egress is off by default and only the Operator can turn it on, per NPC. See Sandboxes.
Everything else — NPCs, Conversations, Skills, Memories, Connectors, HTTP and SSE MCP Servers, Sandbox grants without egress — is ordinary Player work.
What a Player owns
Everything a Player creates belongs to that Player. A Player sees their own NPCs, their own Conversations, their own Skills and their own Memories, and nobody else's. There are no shared folders, no groups and no permission matrix to configure, because there is nothing to configure: ownership is the whole model.
One consequence worth knowing early: Village-scoped Skills and Memories are shared across every NPC you own, not across every Player on the instance.
Moving operatorship
There is no button for it. Moving operatorship to a different Player is a row
update performed by whoever has database access — which on a self-hosted Village
is the same person who holds the .env file, so nothing has actually been
taken away. AgentsVille deliberately has no interface for it, because an interface
implies a role system, and there is no role system here.
If the first Player leaves an instance, the Village keeps working. Only those three Operator-gated actions become unavailable until the row is changed.
Next
- Village and invite codes — how a second Player gets in.
- Your first NPC — what a Player does next.
- Configuration — what the Operator sets in
the
.envfile.