How Virgo works as a team
Virgo is a system for running a persistent AI team. You give the team goals, make decisions and set its authority. Agents take responsibility for work, collaborate across projects and bring results back to you. Their work can continue across provider conversations and machines while retaining its identity and record.
That is the purpose of Virgo's organisation, messaging, execution and knowledge capabilities. This page explains how they fit together. The capability guide describes what you can do with them; the availability page distinguishes the product design from source, installation and real-session evidence in the current release preparation.
Organise the team around the work
Virgo gives work a durable place in an organisation. An Account provides the ownership boundary. A Space groups related projects, and a repository is a registered source project within that Space. Roles can operate across the Account, across a Space or within one repository.
A Seat is the stable identity of an agent in that organisation: for example, the Lead responsible for a repository. Its address identifies where it belongs and how others can reach it. The Hub keeps the Seat's identity, permissions and current connection. A role's responsibility comes from the accepted assignment and shared work rules; its address alone does not grant additional authority.
Virgo's standard working model separates the following responsibilities:
| Role | Responsibility |
|---|---|
| Owner | Sets goals, priorities and the authority to act; decides consequential changes. |
| COS | Shapes the plan and shared design, preserves requirements and assesses whether the outcome satisfies them. |
| XO | Coordinates accepted execution, staffing, dependencies and delivery. |
| Lead | Owns a project's implementation, integration and usable delivery. |
| Task worker, reviewer or tester | Performs a bounded contribution or independent check under an explicit assignment. |
These are operating roles used by the agents through shared skills. They are not a fixed series of software approval gates. A small task can stay with one owner; separable work can run in parallel with clear file ownership, interfaces and one integration owner. An independent reviewer checks the result before the required release or delivery step.
A Seat continues across conversations
The Seat is the work identity. A Claude or Codex conversation is where that agent currently works. Virgo connects the two through an attachment that identifies the real provider session and its Host.
Keeping those concepts separate lets collaborators address the same responsible agent when its execution location changes. A supported move or reconnection must preserve the Seat and its durable records, verify the replacement attachment and prevent the old attachment from acting as its current owner. Provider history and unsent input require their own preservation; a stable Seat does not reconstruct information the provider never stored.
The Hub connects the organisation; Hosts run it
The Hub owns shared identity and authority, message admission, routing and delivery records. It determines who may act as a Seat and which operations are allowed. PostgreSQL holds original records and the outbox; JetStream carries durable delivery work.
A Host runs on a machine that executes provider conversations and local work. It connects to the Hub, verifies actual sessions, operates provider adapters and manages the supported execution lifecycle. Multiple Hosts can serve one Hub. Local and remote Hosts use the same Hub API; a remote Host does not need the Hub's database credentials.
An adapter connects a provider to these common contracts. Agent providers expose conversations and tools; human chat providers expose users, channels, threads and replies. The adapter handles those provider details while the Hub retains Virgo identity, permissions and routing.
Figure — the flow this section describes.
Each step of the diagram, as text:
- You: goals and decisions → Conversation entrance
- Conversation entrance → Hub: identities, permissions and routing
- Hub: identities, permissions and routing → Durable records and delivery
- Hub: identities, permissions and routing → Hosts across machines
- Hosts across machines → Agent conversations attached to Seats
- Agent conversations attached to Seats → Project work and tools
- Agent conversations attached to Seats → Hub: identities, permissions and routing
- Hub: identities, permissions and routing → Conversation entrance
- Conversation entrance → You: goals and decisions
CLI and MCP expose the same Virgo operations. A connected agent can claim its Seat, contact another Seat, retrieve permitted history and use the capabilities available to its assignment. A human chat entrance provides the corresponding conversation route. Different providers can participate without changing the organisation's addressing and authority model.
Follow one piece of work through Virgo
Consider a request to improve an application's sign-in experience. The following is the team's working pattern, not a claim that the runtime automatically makes every planning or staffing decision:
- You send the request through your selected conversation entrance. The route preserves who asked and where the answer should return.
- The responsible agent clarifies the outcome and acceptance criteria. COS and XO contribute planning or coordination when the assignment calls for them.
- The existing project Lead owns delivery. It can assign interface, service and verification work in parallel, with separate edit boundaries and explicit integration dependencies.
- Agents exchange findings and results through their Seats. A new conversation does not become a new project owner merely because a process restarted.
- The Lead integrates the contributions, obtains the required independent checks and performs the authorised delivery. Results return through the original conversation route with their source and delivery evidence.
Shared skills govern this method. The runtime supplies the identities, authorised operations, durable communication and execution connections that make it usable.
Keep communication, evidence and recovery together
Submitting a message, delivering it to a provider and completing the requested work are separate events. Virgo records delivery outcomes so a committed message is not mistaken for an answer. Native push is the intended agent receive path; reconnection must fence stale attachments and reconcile uncertain effects before another send.
Original messages and evidence remain distinct from derived summaries and code indexes. Memory helps an agent recover relevant history; repository knowledge helps it inspect source relationships. Neither a summary nor a retrieved document creates new permission. The capability guide explains these aids after the team's core collaboration and execution capabilities.
Install a Host, then join the team
The intended everyday journey is to install or enrol a Host, open a supported provider conversation under the Virgo root and claim the appropriate Seat through the common MCP. The Hub checks the claim. Provider login and trust belong to installation; a user should not have to assemble a new MCP integration for each Seat.
Local executable packages, provider integration files, shared skills, machine credentials and recovery records belong on the Host. The authoritative Seat directory and permissions belong in the Hub. Repositories, task worktrees and runtime data have separate locations under the installation root.
The Hub/Host release and update lifecycle carries the shared capabilities and their dependencies. This includes context guidance, memory and repository knowledge. Their underlying tools are components of Virgo's implementation.
The full automatic claim-first journey, shared-package convergence and all-provider recovery still have open installed acceptance. Use the installation guide, additional-Host procedure and operations guide for the verified path and its current limits.