Beyond One Machine: What Distributed Team Changes

For JiuwenSwarm, distributed Team is not simply a switch that makes a local collaboration larger. It changes how a teammate is discovered, how readiness is established, how business state is shared, and what a workspace path means. This chapter follows a teammate from idle registration to active participation, then separates the control plane from the data plane so a reader can tell which resources must be reachable, which must be shared, and which should remain isolated.

Local and distributed are different runtime contracts

A local Team can run multiple members in one process or on one machine with in-process coordination. A distributed Team keeps the same conceptual Leader and teammate roles but places runtime components across processes or hosts. The current documentation associates distributed mode with an explicit runtime role, a transport such as pyzmq, and an external A2X registry used to discover idle teammates.

The important difference is not the transport name. It is the ownership of the transitions that make a teammate usable. In a local run, the runtime can construct and coordinate members within a relatively contained environment. In a distributed run, a Leader must find a remote process, reserve it, send enough information for it to join the intended team, and receive an explicit indication that the member is ready. Network reachability, storage visibility, ports, and cleanup become part of the Team's semantics.

The repository also gives local and distributed modes different session behavior. Local runtime can support multiple concurrent Team sessions in one channel. Distributed runtime keeps one active Team session per channel: creating or switching to another session first stops the active or pending distributed Team so remote resources and transport connections are not reused ambiguously. This is a behavioral constraint, not a user-interface detail.

The control plane finds and admits a teammate

The distributed startup path begins on the teammate side. An idle teammate process registers a bootstrap endpoint with the external A2X registry. At this point it is not yet a member of a particular user-created Team; it is an available runtime that can be reserved.

When a Leader needs a member, it asks the registry to reserve a blank teammate in the configured dataset. The reservation identifies a service and a reachable endpoint and has a limited lease. The reservation step matters because discovery and assignment are different actions. A list of available processes does not by itself prevent two Leaders from trying to claim the same one.

The Leader then sends the bootstrap payload through the direct transport path. The payload gives the remote process the information it needs to apply the Leader's route and adopt the requested member identity. Direct delivery is used for bootstrapping, not as the final proof that the member is ready. The teammate builds or retargets the runtime needed for the new Team and acknowledges readiness through the Team's normal message channel. Only that acknowledgement moves the remote member to ready status in the documented path.