VIRGO

SUSTAINABLE PROJECT OPERATION

An AI system for running long projects, not just finishing tasks.

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

Four things a project needs to survive its own length.

Continuity

The team never starts cold. Identity, memory, conversation, and accumulated context are preserved, so collaboration compounds instead of resetting every turn.

Verification

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.

Bounded authority

Autonomy at scale needs explicit owner gates. Persona lifecycle mutations require operation-bound CLEAR tokens and a separately attested execution context.

Scale structure

One implicit home workspace extends into separate work domains, and capability stamps with transport denial keep those domains isolated from each other.

QUICK START

From a new machine to a registered persona.

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 add

These 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

Start with the question you need answered.

ONE DASHBOARD, READ-FIRST

The dashboard reads the system. Authority stays on gated paths.

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

The dashboard tells you what it does not know.

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.

Receipts name who acted

The receipt viewer shows the project, agent, and device behind an operation, and bridges from the receipt to the record it produced.

Three hashes stay three

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.

Missing is not empty

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.

Forks and cycles are reported

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

Agents collaborate. State moves. Authority stays bounded.