VIRGO

Resident collaboration

Source
docs/design/RESIDENT-COLLABORATION.md
Pinned at
d62e85485903a5537ee2b73c14201597e29bdaa5
sha256
7ce0d4ed7990635c314c02f7c9b017276a8d7ccbb0740349a5e4cf70166959f1

This page is the specification itself, rendered from the pinned source above. Its text is reproduced exactly; only its presentation is added.

Resident collaboration and persona paths

Status: approved product contract (2026-08-04).

Virgo's primary value is a team of AI agents collaborating, not one durable assistant. Resident personas exchange coordination messages, assign and report tasks, raise and resolve decisions, delegate lead-to-deputy work, and consolidate human-facing context through a secretary. The owner enters at explicit approval gates rather than routing every internal handoff.

Why resident native sessions

Persona runtimes are native interactive sessions, never a loop of headless single-prompt invocations. Reinjecting the entire working bundle for each cold turn wastes tokens and loses conversational accuracy. A resident session keeps its native history, accumulated context, memory, and channel state. Checkpoint, resume, and migration preserve that lineage under one logical identity.

A project-duty persona may be anchored to a repository. A lead at work/core/lead, for example, is the persistent lead session for the core project: it accumulates project context, delegates bounded work, and receives deputy reports without becoming an ephemeral subprocess itself.

Address path

Registration asks in path order: scope, optional project, role, then persona name. The path is the transport address; the name is the owner-facing identity and may use a suggested Virgo-constellation name.

  • root/secretary, root/operator: reserved installation-wide roles.
  • home/secretary, work/coordinator: scope-wide, two segments.
  • work/core/lead, work/core/deputy: project duties, three segments.

root is reserved above workspaces and cannot be created or deleted. Project absence means scope-wide; there are no -, all, or reused root placeholder segments. Parsing is by segment count. Role segments come from the class registry, so a role cannot be mistaken for a project.

The registry maps address roles to capability profiles; the path stays short while enforcement keeps the more descriptive profile names:

Address roleBinding arityCapability profile
secretaryroot or scope-widesecretary
operatorroot onlyproject-lead
coordinatorscope-wideteam-coordinator
leadproject-boundproject-lead
deputyproject-boundcoder-deputy

Registration and retirement

virgo persona add registers the address, role/capability profile, native session lineage, character composition, and optional repository binding. Retirement is a durable state transition, not deletion: it stops placement and new delivery while retaining records, snapshots, and the address history. Dashboard edits use the same mechanized registration and retirement paths. The Redis transport requires an authoritative address-directory admission check for every registration and both endpoints of every new publish; a retired PERSONA therefore never regains a lease or receives newly admitted work. Its former path is a seat that may later be granted to a new persona generation under a new for-life name; admission then resolves to that new active holder.

Collaboration mechanics

The hub provides addressed coordination, task and decision records, and fenced delivery. A lead assigns a bounded task to a deputy; the deputy reports progress and evidence to the lead; the lead consolidates; a secretary routes the result or approval request to the owner. Transport identities and fences ensure those messages reach the current resident generation, not a stale duplicate.