Agents are a team sport whether you planned it or not.
The moment a second person on your team starts running coding agents, you have questions no single-user tool answers: who can see what, who can steer what, and where the knowledge accumulates.
// One organization. Per-product seats. One subscription.
Individual tools do not survive a team.
These are the problems that appear the week you stop being one developer with one machine.
Access needs a model, not a password
Single-user setups answer access questions by not having them. A team needs to say who is allowed to watch a run, who can drive it, and how that ends when somebody leaves.
Work waits for one specific person
A session blocked on a decision only that developer can answer is a bottleneck with a name on it. That is fine until they are on a plane.
Everyone rediscovers the same things
Four developers running agents on one codebase means the same conventions get worked out four times, and again next month.
Billing has to be explicable
Somebody eventually asks what the team is paying for and who is using it. Per-seat billing on one subscription answers that in a sentence.
What a team gets.
Both products are seat-based and share one organization and one subscription.
Oversight of every session
Follow live activity on the machines connected to your organization, and answer permission and plan decisions from anywhere.
Memory the team shares
What one member agent works out is retrievable by another member agent, because memory is organization-scoped.
Access that ends cleanly
Seats are assigned and removed by admins, per member per product, so access follows employment rather than a shared credential.
One line of billing thinking
A single subscription with one item per product, priced per seat at the same flat rate for both.
The account model, briefly.
Team structure is core mechanics here rather than an upgrade tier.
One organization per user
Each user belongs to exactly one organization, which keeps access, ownership, and billing unambiguous.
One subscription per organization
Products are subscribed independently and billed together on the same subscription.
Isolation in storage
Per-organization isolation is enforced at the database layer with row-level security rather than application checks alone.
When a team plan is not what you need.
The team model adds structure. Structure is only worth it if you have the problem it solves.
- You are one developer with one machine, where an organization and seat model is ceremony you do not need yet.
- You need several separate organizations under one login, which the account model does not support.
- Your primary coding agent is not Claude Code, which is what Virex Remote is built around.
- You want governance controls like SSO and SCIM today, which belong to the enterprise conversation rather than the standard team setup.
Team questions
How do seats work for a team?
Seats are per member, per product. A teammate can hold a Virex Remote seat, a Virex Memory seat, both, or neither, and admins change the counts as the team changes.
Does everyone need both products?
No. Many teams start with one. Because both sit on the same subscription, adding the second later is a line item and a seat assignment rather than a new contract.
Can a teammate see sessions running on my machine?
Machines and sessions belong to your organization, so members holding a Remote seat work inside that shared scope rather than through shared credentials.
What happens when someone leaves the team?
An admin removes their seats, which ends their access to both products. The memories their agents wrote stay with the organization.
Can we have more than one organization?
No. Each user belongs to exactly one organization, which keeps membership, access, and billing unambiguous.
Set the team up once.
Create your organization, subscribe, and assign seats. Everyone joins with the same login.