How it works

Pairon is a shared conversation where signed-in people direct coding agents that run on computers the team connects.

The agents are Claude Code, Codex and OpenCode. They do not run on Pairon’s servers. A person installs the Pairon runner on their own machine, approves it, and that computer becomes a lane in the conversation.

Pairon is in private beta for engineering teams. It is not a general chatbot, and it does not run agents for marketing, sales or research work.

Without a shared room, each person keeps a private chat with their own agent. The next person repeats the bug, the decision and the files that already changed. Pairon keeps that thread in one conversation: the instruction, who sent it, which computer ran it, and what the team decided.

1. Workspace. The tenant people belong to. Billing and the people list live here. Pairon calls this a workspace, not a team.
2. Project. A workspace-owned codebase. Joining a project from your computer adds your checkout. It does not create a second project.
3. Conversation. One live room. It can be linked to a workspace and a project. That link is not the participant list. A private conversation is visible to its creator and the people they invite.
4. Lane. One computer plus folder attached to the conversation, with its own queue. An instruction runs on the lane chosen in the composer. Several lanes in one conversation can run at the same time, each on its own branch.
5. Instruction. One submitted request. It keeps the agent, model and branch it was sent with. A teammate’s instruction on your lane uses your agent account, and you can limit that to specific people.

Invites use the same words as the product: Viewer, Collaborator and Admin. Viewers can read. Collaborators can send instructions and approve requests in that scope. Admins can manage access, subject to their workspace role. A join link admits a guest to one session. It does not make them a workspace member.

Hand-off. An agent can pass a sub-task to another lane. It sends automatically when that lane is in full access. Otherwise the author of the parent instruction confirms it.

Parallel tries. One instruction can go to several lanes so the team can compare results. It reaches the sender’s own lanes and lanes whose owners accept parallel tries.

Continuation. When a new agent continues someone else’s work, it receives a short brief: the original instruction, the last hand-off note, which files changed, and any failed attempts. The agent still reads the files itself.

Review. When two changes touch the same lines, the room shows both versions: Keep mine, Keep theirs, or ask an agent to combine them. Only asking an agent spends tokens.

Project memory holds verified facts and decisions so the next turn does not relitigate them. The published cost result measures that memory for one agent. It does not measure a team. See the benchmark.

File contents, diffs and terminal output pass through Pairon live and are not stored. Chat, instructions and agent replies are stored. Guests see the transcript and change summaries, not live file contents, unless the computer owner shares them.

Raising what an agent may do on a computer, or allowing a new folder, needs that computer’s owner. The runner on the computer checks the confirmation. The server can relay a request. It cannot grant the permission. The detail is on Security.

Connecting a computer is a separate step from requesting beta access. Getting started lists those steps in order.