Four boundaries decide an open-source multiplayer agent harness

What a shared harness has to answer

The hard part of a multiplayer agent harness is the turn that runs with nobody at the keyboard. A shared window changes who can type. What a turn inherits is decided elsewhere: whose memory it reads, what it spends, who can see the record, and what is left when it finishes.

The four decisions share a shape, and the shape is the argument: the project repository is the unit, a run is a session on it, and a person reviews what the session brings back. Each one comes down to a test a team can run, an answer to look for, and the cost of that answer. The record boundary asks two questions: who can see the record, and what the record is.

The test: one run with nobody at the keyboard

Every question here comes down to one experiment a team can run before it commits. Schedule a run for a time nobody will be at the keyboard, and let it fire. Then read four things: what it could see, what it spent, who can read the record, and what is there when it finishes. A harness that looks finished in a shared window can fail all four, because the person who would have answered is asleep.

The test works because it removes the author. In a live session the person typing supplies the context, the credential and the judgement. The harness can look complete while doing none of that work. At six in the morning there is no person to supply anything. Whatever the run does then is the harness's own answer.

A right answer has four parts. The run reads memory the team can read and review. It spends a credential the team chose for it, not a person's whole account. The record is readable by the people who need it and closed to the people who do not. What it leaves is something a person can approve, reject or roll back. A team can write those four down before the first shared run and hold a vendor to them.

Decision one: whose memory a turn reads

A harness built for one developer can keep one transcript, one scratch directory and one set of notes. The person who owns them is the person typing. A scheduled run has no such person. The harness has to answer a question the single-player case never asked: which memory a turn reads when the account that started it is closed, on holiday, or gone.

Three answers are common. The person's memory dies with the account, and the schedule keeps firing with less to read each week. A room's memory is rich and unreviewed. A Monday reader has to work out which parts were theirs and which a colleague said on Friday. A project's memory is committed, so a teammate can read it before approving anything. A new teammate finds the same memory on day one.

The test is the scheduled run. Fire it, then read what it could see. If the answer is a person's notes, the harness is single-player with a shared front door. If it is a room's history, the team has chosen continuity over review. If it is the project, the memory has an owner, a diff and a reader.

Kortix's answer is the third. A session starts from the project's repository, so the memory a run reads is the memory committed there. The same files are what a teammate reads before a change is approved. The cost is that memory has to be written down to travel. A transcript nobody committed is not in the next run.

Decision two: what an unattended run spends

A harness that runs with the login of whoever started it inherits that person's access. That works while one person is the only one using it. In a shared harness an intern's turn and a founder's turn run through the same loop. The six o'clock run is started by nobody at all. The question is what that run spends, and who agreed to it.

There are two routes. The credential can belong to a person, and then every unattended run borrows somebody's whole account. Or the platform can hold the credential and hand the turn a brokered connection. The turn gets a connection, not the value. A team should know which route each credential takes, because the blast radius is different in each case.

The test is to start a scheduled run and watch which credential it uses. If the answer is a person's login, the harness has no answer for the run nobody started. If the answer is a connection the platform opened for that run, the team can name the account behind it and revoke it in one place.

Kortix takes the brokered route for connectors: "Connector credentials are brokered server-side and never enter the machine." A project secret is a choice instead, and the environment is the default exposure: an environment variable, where the machine gets the real value and code in the session can read it. Enforced is the brokered route. The sandbox holds a handle. Kortix substitutes the real value outside the sandbox, only on approved HTTPS hosts. An echoed value comes back as [REDACTED]. Disabled keeps the value on file, and it reaches no session. Egress-enforced is experimental. A team putting several people on one harness should know which mode each secret uses and who agreed to it.

Decision three: who can see the record

Every harness writes something down. The multiplayer question is who can read it. The unattended run is where that gets sharp, because a run that fired at six has no author to ask.

A record scoped to a person answers for that person, and when the person leaves, the record leaves with them. A record scoped to a room answers for the room's members. That suits a discussion and fits a change to a shared branch badly. A record that lands as a diff in a repository answers for anyone who can read the repository. It outlives the tool that produced it.

The test is to hand a new teammate last month's scheduled runs and see whether they can tell what changed and who accepted it. That is also the test an auditor runs a year later with less context.

Kortix's answer is the repository. "Session work reaches main through a change request." The diff is the record, and the change request is where a person enters. The repository is what a teammate or an auditor already has access to. The cost is that the record is only as readable as the repository's permissions. A team that has not decided who can read the repository has not answered this question either.

Decision four: what a finished turn leaves behind

A finished turn can leave a transcript, a diff, or both. A transcript gives the next person context and nothing to approve. A diff gives them something to approve, reject or roll back, and very little of the reasoning that produced it. A team that wants both has to decide where each one lives.

The test is to look at what the unattended run left. If the only artifact is a transcript, the next person has to reconstruct the change by hand. If the only artifact is a diff, the next person can review the change but not the argument behind it. The useful answer is a diff with a transcript attached, and a place to read both after the session is gone.

Kortix's answer is a branch per session. "One isolated sandbox per session. Each session has its own isolated machine and branch." The run's work sits on its own branch, and the change request is where a person reads it. The transcript stays with the session. The cost is a review step: someone has to read the change request before the work reaches the shared branch. For a team whose durable output is code, documents and configuration, that step is the point.

Before the first shared run

The field answers these four questions in different places. QM describes itself as a multiplayer agent harness for work. It gives each person and each room a scope that owns memory, files, a keychain view and a computer. Its approval answer is one organisation-wide posture that a narrower scope can only tighten (QM). The harnesses that grew out of a single developer's terminal keep the record on that developer's computer. Codex can keep runtime state and history in a local SQLite directory. Pi stores sessions under ~/.pi/agent/sessions/ with no permission layer of its own. Hermes keeps session metadata in a local database and defaults unattended runs to deny (Codex, Pi, Hermes). Hosted harnesses keep the record on their own servers. The approval default varies: Amp runs tools without asking unless a plugin says otherwise (Amp).

A team that writes the four answers down has something to hold a vendor to. It also has something to re-read when the first unattended run surprises it. The agent harness comparison puts the named projects side by side on where each keeps its state. If the term itself is the open question, what an agent harness is takes the layer apart. For a shortlist once the four answers are settled, which harness fits sorts the field by who approves a tool call and where the record lands.