Continuity
The team never starts cold. Identity, memory, conversation, and accumulated context are preserved, so collaboration compounds instead of resetting every turn.
SUSTAINABLE PROJECT OPERATION
Virgo turns multiple AI agents into a team that keeps a project moving over months: sessions survive compaction, personas survive machines, and the facts the team works from stay checkable. It is built for long-term, enterprise-scale work rather than one-off batch jobs where agents simply pass messages.
Virgo is in active development.
WHY IT LASTS
The team never starts cold. Identity, memory, conversation, and accumulated context are preserved, so collaboration compounds instead of resetting every turn.
Long-lived work cannot rest on memory or assertion. Product records are canonical graph nodes carrying provenance and typed edges, while rendered files are verified snapshot views of them.
Autonomy at scale needs explicit owner gates. Persona lifecycle mutations require operation-bound CLEAR tokens and a separately attested execution context.
One implicit home workspace extends into separate work domains, and capability stamps with transport denial keep those domains isolated from each other.
QUICK START
The first machine becomes the hub; later machines join it. Initialization creates your private canon and home workspace.
01 curl -fsSL https://virgo.codes/install.sh | sh
02 virgo onboard
03 virgo init
04 virgo persona addThese commands execute in the pinned release. Persona up is the approved next lifecycle surface, not yet exposed there. Persona creation can suggest a name, asks for a class, and lets you describe its personality—or start with a sensible default.
EXPLORE THE SYSTEM
Native sessions, role paths, lead-to-deputy work, secretary routing, continuity, and lifecycle.
Read topic →Isolation domains, project duties, addressing, and shared machine capacity.
Read topic →Measured onboarding, fencing, evidence, moves, and autonomous recovery.
Read topic →One persona-facing contract for Teams and future adapters.
Read topic →Pinned store runtime and the designed setup, status, and record surfaces.
Read topic →Private canon, credential boundaries, capability policy, and audit gates.
Read topic →Available commands separated from approved, not-yet-executable designs.
Read topic →Measure failures and diagnose channels without reading private content.
Read topic →ONE DASHBOARD, READ-FIRST
The approved dashboard design covers six screens: status, setup checklist, personas, records, skills, and preferences. Five are built today; preferences remains design-pending and is not yet a screen you can open. One kind-agnostic record viewer browses records, provenance, and graph edges across those views.
The dashboard is authenticated, never displays or edits credentials, and performs no mutation of its own — changes travel the same gated paths as the CLI.
WHAT YOU CAN CHECK
A long project accumulates claims. These are the habits that keep them checkable — each one visible on the screen rather than promised in a document. On the attention panel, for instance, the age is the hub's measurement while the colour is labelled on screen as this dashboard's own opinion rather than a hub verdict.
The receipt viewer shows the project, agent, and device behind an operation, and bridges from the receipt to the record it produced.
Content hashes, manifest hashes, and receipt hashes are rendered by separate helpers, so a manifest hash is never quietly shown as if it addressed a record.
A refused read, a surface the hub does not serve yet, a list it did not enumerate, and a genuinely empty result are four different statements — never one blank table.
Revision history is walked under an explicit bound. A chain that forks or loops is reported as such instead of being silently followed down one side.
SYSTEM AT A GLANCE