Logos is a cross-process agent harness designed to move the composition and assembly of software components out of a single host process and onto a distributed bus. By treating each plugin as an independent process, the system aims to eliminate the single point of failure inherent in traditional agent frameworks where a process crash terminates all co-resident sessions and components.
Moving Composition Out of the Process
Modern agent systems typically load and unload capabilities within a single process, which creates a shared failure domain. If the host process crashes, all components and sessions are interrupted. Hanzhang Jia, Liheng Zeng, Hao Cheng, Yi Gao, and Bo Ma propose that this co-residence is not a mathematical requirement.
The authors establish four lemmas—orchestration externality, carrier substitution, recovery localization, and external resolution—to prove that the reversibility guarantees of the spatiotemporal-composability calculus can be maintained across multiple processes. These lemmas rely on the fact that language-model inference is stateless and that cross-step state can be managed externally.
The Logos Architecture
Logos implements these principles using a ROS-like architecture where a bus facilitates communication between peer processes. The system consists of:
A Router: A Go-based process that manages a routing table, handles registrations, and forwards messages. It does not read payloads or schedule tasks.
Peer Processes: Each plugin, harness, or tool runs as its own operating-system process. This allows for mixed-language environments, such as Python, Node.js, and Go, to operate on the same bus.
Append-Only Transcript: This serves as the single source of truth for all session state. Because the transcript is owned by no single process, it allows for "cold switching," where a new process can rebuild a session after a failure by replaying the transcript.
Resilience and Performance
The researchers evaluated Logos through stress audits and fault-injection tests. In a comparison with a single-process configuration, a single fault in the Logos peer-process construction interrupted only the affected node, whereas the same fault in a single-process setup terminated all co-resident sessions.
In tests involving 80 sessions, the system resumed after kills at various points in the tool-call cycle—including during execution and after announcement—without repeating any effects. The work performed after recovery was limited to what the transcript had not yet recorded. Regarding performance, the authors measured the median cost of a bus hop at 0.215 ms, which they note is significantly faster than the 177 ms first-token latency of the language model, rendering the overhead invisible at the model's time scale.
Limitations and Considerations
The Logos construction is subject to specific constraints to ensure it remains a faithful implementation of the calculus:
Single-Writer Requirement: Each capability name must be associated with exactly one registration. Conflicting claims are handled via explicit refusals.
Ordering: All observers must receive supply-change notifications in the same order, which is enforced by the bus's serialized broadcast mechanism.
Protocol Compliance: Any node acting as a peer must conform to the established wire protocol.
The authors distinguish Logos from other distributed architectures like MCP or Temporal, noting that while those frameworks move tool servers or execution out of the host process, they often keep composition and assembly logic within the host. Logos moves the composition and assembly themselves onto the bus.
Comments (0)
to join the discussion
No comments yet
Be the first to share your thoughts!