How Agents Build and Ship Nexus

• Sessions and subagents. Each working session is one Claude Code session in its own worktree and branch on the laptop. It dispatches subagents: developers for implementation, and two standing reviewers (a code reviewer and a critic). Sessions choose their own beads. When the owner asks, one session coordinates: it assigns work, collects results, and prepares a release.
• The conexus instance. A separate Claude Code session in the conexus repository runs the managed engine, and so it hosts the tuple space that every other session coordinates through. It also hosts the adapter that turns GitHub events into CI board posts, deploys each engine release, and runs the cloud gates. It is a peer of the other sessions: it receives requests in its mailbox and answers there.
• GitHub runs CI on every push to develop and on every pull request, and it runs the release workflows on tags.
• A second machine on the local network runs full test suites and gates for the sessions. It is also a self-hosted GitHub runner for the mac release builds.
• The owner pushes every release tag, approves every cloud deploy, and decides changes of scope or direction.

The sessions share state through two kinds of record: short signals in the tuple space, and longer notes in Nexus memory.

A tuple is a small record with a schema. It lives in the engine, outside every conversation, so it outlives the session that wrote it and every session reads the same row. The Nexus Tuple Space describes the operations, and Coordination describes messages between sessions and agents.

Each session holds a short name in a directory in the tuple space, and a message addressed to a name reaches the session that holds it. Each session and each subagent has a mailbox. A session subscribes to the boards it cares about, and its own Nexus server then pings it for each new post and each new message in its mailbox. No session polls, whether it waits for CI, for a peer, or for a reply.

A post or a message carries a short signal and names a memory entry for anything longer, such as a measurement or a list of affected documents. Work items are beads in a shared tracker.

The conexus plugin gives every session the same agents, skills, and hooks, so the sessions work the same way without instructing each other. A session hands most work to background subagents: developers, the two standing reviewers, a debugger, planners. Skills carry the checklists, such as the two release procedures. Hooks enforce the practice that nobody should have to remember: they brief each subagent when it starts, refuse to close a bead without both reviews, and record every dispatch.

Claim and announce

A session claims a bead and posts the claim on the team boards, with the worktree it uses and the files the change touches. Other sessions receive the post, so two sessions do not start the same work. The team boards also carry advance warnings when a change affects files that other sessions work on.

Build and review

The session creates a worktree on a feature branch and dispatches a developer subagent, which writes the failing test and then the fix. Hooks record every dispatch in a ledger, so a subagent that started and never reported shows up as missing. The two reviewers then read the change, the session fixes their findings, and it records a review marker that names both reviewers.

Test

Each machine runs one engine build or engine test suite at a time, and a lease enforces it. Every worktree on the machine sees the lease, and it ends by itself if its holder stops. Each machine also runs one full test suite at a time. The session posts on the team boards when it takes the full-suite slot and again when it releases the slot. For heavy runs, the session moves its branch to the second machine over ssh. That machine has its own clone and its own lease, so it runs a suite while the laptop builds.

Push

Before it pushes, the session reads the CI board for the latest develop commit, because a push cancels the CI run of that commit. Another session can be waiting for that run. The push script then sends only the commits and files that the session names, so a peer's work never goes out with the push. The script holds the push lock only while it pushes. The session posts the push on the team boards and fast-forwards the primary checkout, which stays on develop as the shared reference and which nobody edits.

GitHub then runs CI. For each state change of each run and job, GitHub sends a webhook to the adapter, which verifies it and writes one post to the CI board. The session receives the pings and reads the verdict for its commit with the status reader. A red commit gets a fix as a new commit, and other sessions read the verdict before they build on a commit. The bead closes when the close gate finds the review marker.

Release the client

The coordinating session creates a release worktree, which a push to develop cannot move. Then it bumps the version and runs the release battery. The battery builds the artifacts once, runs the end-to-end gates in parallel, and prints one verdict table. A gate that finishes without its verdict line counts as missing, never as passed. A red gate is fixed on the release branch, and the battery runs again. The session opens a pull request to main. The owner merges it and pushes the release tag. The release workflow checks the tag against the version and against the tagged commit's CI results, publishes the package to PyPI, and creates the GitHub release. Each client release pins exactly one engine version.

Release and deploy the engine

Before an engine tag, the coordinating session builds the candidate native binary and runs the shakeout, an end-to-end test of that binary. The owner pushes the engine tag. The engine workflow builds and smoke-tests native binaries for Linux and macOS, signs every asset, and publishes the GitHub release only when every asset is present. A failed build job leaves the release as a draft until a rerun completes it. A gate then installs the published binary on a bare machine and tests it.

The deploy request is a relay, not an approval. The coordinating session sends the tag and its gate evidence to the conexus instance's mailbox. The owner types the approval in the conexus instance itself, and the conexus instance refuses an approval that another session relays. The conexus instance then deploys the engine and runs its cloud gates. While those gates run, the coordinating session posts a freeze on the team boards. The freeze names the step that the session waits for, and the other sessions hold their pushes. Afterwards, a session on a cloud-mode machine checks that the engine's contracts reach real client code through the public edge.

The wire-contract ledger decides the order. It lists each engine change whose client half has not shipped, and marks whether an old client still works against the new engine. When every entry is safe for old clients, the engine deploys before the client release. Otherwise, the conexus instance must record that the redeploy is armed before the client tag, and the release gate checks for that record.