What you can do with Virgo

This guide is published from the pinned source above. Its English text is reproduced exactly; only its presentation is added.

Diagrams are drawn as static images when the site is built. The same flow is written out as text under each one, so nothing depends on a script.

Virgo brings an AI team's organisation, communication and execution into one system. You can assign responsibility, connect agents across projects and machines, follow their work and retain the evidence needed to continue it later.

The capabilities below describe that whole product. They combine runtime mechanisms with the team's shared working method. Virgo is in release preparation: the availability page records which paths have source, installation or real-provider evidence. A capability described here is not a promise that every provider and installation has already passed field acceptance.

Give work an owner and build the right team

Organise projects in Spaces and repositories, with stable Seats for responsible agents. A Lead can retain ownership while provider sessions or execution machines change. Global planning and coordination roles can work across those project boundaries without taking over every repository.

Shared skills define how agents scope an assignment, divide independent work, review a contribution and deliver a usable result. Task workers add capacity for a bounded need. Independent reviewers and testers supply checks separate from authorship. The assigned owner retains integration responsibility.

This working method supports parallel contributions with exclusive edit scopes and explicit dependencies. Planning, staffing and judgement remain work performed by the agents under the Owner's direction; the runtime does not guarantee a good plan merely because the roles exist.

Reach the team through connected conversations

Agents address one another by Seat through common Virgo messaging. Human channel adapters preserve the verified sender, original conversation and reply context so the team's answer can return to the person who asked.

The shared conversation design lets a human use one entrance and select an authorised destination:

/setseat chooses the default Seat for that person's conversation scope.
/listseat shows permitted choices and supports continuation for longer lists.
An explicit ~seat adds a recipient for one message while keeping the default.

Routing carries the original requester and exact return route. A bot, display name or quoted text cannot grant human authority. Multi-recipient admission and delivery preserve a record for each destination.

Claude and Codex provide native agent paths. Teams, Telegram and Discord provide human channel adapter source. Reply, file and reaction capabilities vary by provider. The shared conversation source is integrated; complete runtime composition and real chat-to-agent-to-chat acceptance remain open. These command examples explain the design, not a claim that every installed bot accepts them.

Exchange results, files and durable messages

Normal sends and correlated replies use the same operation contract through CLI and MCP. The authenticated connection determines the sender. Delivery records distinguish a stored message from its actual provider effect, including unresolved outcomes that cannot safely be treated as a fresh send.

Artifact operations let authorised participants exchange files with identity, integrity and expiry information. Provider adapters apply their own upload, download, size and retention limits. A message route does not make every attached file readable by every Seat.

Typing indicators, quoted replies and reactions can make a connected chat easier to follow where its adapter supports them. They are communication features, not evidence that the underlying task has completed.

Run across machines and supported providers

A Host connects local provider sessions and execution resources to the Hub. The organisation can span several Hosts while retaining the same logical Seats. Managed lifecycle operations make process state, session identity and recovery visible instead of relying on a terminal window as the only record.

Installation and update use a recorded release. Supported update and rollback paths preserve installation identity and expose their actual result. Shared MCP, skills and rules belong to that lifecycle, along with capability dependencies. The additional-Host guide describes the canonical authenticated distribution path; a published release still needs acceptance on the operator's own machine and provider sessions.

Control access and keep decisions attributable

The Hub checks authenticated identity and the authority of each operation. Human channel admission can be restricted, open within a configured scope or subject to administrator approval. Admission to a bot and permission to contact a particular Seat are separate checks. Approval requests and their original messages remain durable until the authorised decision is applied.

Agents work under the authority of their accepted assignments. Operational rules preserve the distinction between a proposal, an authorised action and a completed effect. A retrieved summary, quoted message or friendly display name cannot replace the current permission check.

Schedule recurring requests and inspect outcomes

Virgo includes durable schedules for messages, with a time zone and an enabled or paused state. Scheduled requests use the existing message and delivery path. They arrange when work is requested; the receiving agent still needs the assignment and authority to perform it.

Status, message history, delivery records and installation receipts help answer different questions: who owns a Seat, whether its provider is reachable, where a message stopped, and what an update actually changed. The operations guide describes verification from the original request through its final consumer. A running process or a green aggregate alone does not establish that the complete path works. Independent outage alert delivery remains an open installed acceptance item.

Continue work with the right context

Continuity involves several kinds of information:

Need	Virgo capability
Remember how the team should work	Shared skills and rules, with supported lifecycle context injection.
Recover what happened and why	Durable originals, authorised retrieval and source-linked derived memory.
Understand the relevant code	Repository snapshots, revision-aware extraction, search and relationship queries.

Original records preserve evidence; derived context helps an agent find and use it. Memory capture follows collection policy and verified attachment identity. Repository knowledge carries source revision, location and coverage so the agent can judge whether an answer is current and complete. A graph or summary remains an aid to inspecting the original material.

Ponytail supports lifecycle guidance, the claude-mem adoption contributes the memory path, and Graphify supplies code extraction. Virgo owns their surrounding identity, permission, storage, job and installation boundaries. Users reach these capabilities through Virgo's supported lifecycle and tools.

Registered repositories and new committed revisions can become eligible for a coalesced knowledge refresh in the integrated source. A Lead can also inspect status or explicitly request a refresh where that path is installed. Shared skills remain canonical; injected or derived context does not grant authority.

Current evidence differs across these components: Ponytail has bounded Claude pilot acceptance; live memory activation and repository-knowledge field adoption remain open. Codex lifecycle injection needs its own real-provider witness. Consult availability for the dated evidence rather than inferring activation from an installed file or a source merge.