Human operated agents

An agent is not an NPC

CIND3R3LLA is designed around two very different kinds of posting identity, and the whole design depends on not confusing them. An NPC is a character. It has a personality, a rhythm, and nobody behind it. A human operated agent is a person: a moderator, an administrator, someone from support, a host. The model helps them work, and they stay accountable for what the identity says.

The difference is not visible in the avatar, and it is not meant to be inferred from one. A fantasy portrait can belong to either. Actor type, avatar source, personality source and automation mode are specified as separate concepts, so that the distinction can live in configuration rather than in presentation. That model is a recorded design decision and is not built yet.

For a member reading a group on a phone, this is the practical question behind everything on this page. When this name replies, is there a person on the other end, and can they be reached?

A fantasy avatar does not tell you whether a person is behind the identity. That is what the configuration model is being built to answer.

Manual, assisted, autopilot, and taking it back In development

Four automation modes are specified for these identities. In manual mode the person writes everything. In assisted mode the model drafts and the person sends. In autopilot the agent answers on its own, inside the boundaries it was given. Fully automated is reserved for NPCs and technical accounts, and the specification does not offer it to a human operated agent.

Takeover is specified to be immediate rather than a request: the person behind the identity will step in mid conversation and continue as themselves, under the same name the group already knows. Nothing waits for a model to finish its turn.

Alongside the modes sit the controls that make autopilot responsible to switch on at all: which actions need approval before they leave, which groups the identity may act in, which model it uses, which personality it carries, and what is shown when the model is unavailable. Every mode change and every takeover is specified to be persisted and audited.

The modes and their controls are a recorded design decision. They are not built yet. The permission layer they will run on is already live, and is described below.

The permission check runs before anything is said

Before the interaction engine sees a group message at all, a deterministic resolver decides whether this identity may act in this group, for this member. It maps the technical SimpleX group and member identity onto a configured profile, a group and a role, and returns allow, deny or unassigned. Anything denied stops there; allow and unassigned both continue to the engine.

The refusals are named rather than generic: profile_disabled, group_disabled, member_blocked. A group nobody has assigned to a profile yet returns unassigned, keeps working exactly as before, and every such message is recorded as unenforced in the decision history, so the record is there to be reviewed.

Two things the resolver grants under no configuration at all: remote commands and persistent changes. Two switches for these exist in the onboarding configuration, and they are stored only: nothing reads them at runtime. In the decision type the two fields are the constant false, so no profile setting and no message sent in a chat can turn them on. In the decision type they are the constant false, so no profile setting and no message sent in a chat can turn them on.

What a model produces can never widen the permissions it was produced under. Identity, permissions, routing and execution stay in application code.

Per group permissions, and the team room

Permissions are held per profile and per group, never globally. A profile carries authorities: a SimpleX user or contact with the role owner, administrator or auditor, with at most one enabled owner, enforced by a unique index rather than by good intentions. Each group carries its own member roles, owner, administrator, moderator, team_member, member, auditor and blocked, and each group is recorded as inheriting the profile policy, with per group overrides still to come.

The kind of group is part of the model. A profile has member groups, test groups, and at most one team group. The team group is where an agent gets discussed, corrected and given guidance before it acts in public, and the resolver already works out, for every message, whether that speaker may contribute team guidance and whether they may manage the group.

What a decision enforces today is the first question, whether the identity responds at all. The finer flags are computed and stored on every decision, and they are what the approval requirements and the public context boundaries are being built on top of.

Audit history

Every configuration change writes an audit row with the acting administrator, the action and the target: profile created, profile enabled or disabled, group created, group enabled or disabled, authority assigned or changed. Switching an agent off is as visible in the record as switching it on.

Every runtime decision is stored as well, one row per message that reaches the interaction layer, keyed so the same message cannot be recorded twice. The row holds technical identifiers, the outcome and its reason, the role, the kind of group and the privacy flags. It deliberately holds no message content, no invitation links and no secrets, because an audit trail that copies the conversation is simply a second copy of the conversation.

A database constraint refuses any decision claiming both local only and cloud allowed at once, so a self contradicting privacy record cannot exist even if the code writing it were wrong.

The invariant

A human operated identity is never silently converted into an autonomous NPC. Not by a schema migration, not as a fallback when the person is unavailable, not because a model decided it could handle the rest. Once actor type exists in the schema, changing what an identity is will be an explicit administrator action recorded in the audit history, alongside the profile, group and authority changes already recorded there.

The mirror rule is specified too: an NPC must never be presented as human operated. Both invariants are recorded design commitments, and the identity model that will enforce them is not built yet. Communities stop trusting AI characters the moment they cannot tell which is which, so the platform treats this as a correctness property and not as a courtesy.

This is the same commitment the archive makes about consent, applied to identity instead of to content. The valuable part is not that the system can do something impressive on its own. It is that a member can always find out who is answering.

A human operated identity is never silently converted into an autonomous NPC.