This post analyzes the AAMAS 2027 paper *Logos: An Agent Harness on a Cross-Process Bus* (arXiv: 2608.28553), by Hanzhang Jia, Liheng Zeng, Hao Cheng, Yi Gao, and Bo Ma (University of Sussex, Zhejiang Gongshang University, Shanghai Shuyuan Information).
The Problem: The Single-Process Death Quagmire
Typical agent systems run all plugins (weather lookup, payments, email, etc.) in one process sharing one event loop and failure domain. One uncaught exception in a third-party SDK kills the whole process: every active session is lost, and any upgrade, config change, or new tool requires a restart that takes all users down with it.
The Logos Approach: Separate Organs from the Body
Rather than patching the single process, Logos splits the agent into peer processes communicating over a bus—clearly inspired by ROS's peer-process, name-routed design.
Components:
- Router — maintains a rebuildable node registry and forwards messages by recipient; its death doesn't affect other nodes.
- Harness — one process per session, running the "input synthesis → LLM call → output settlement" loop; session state comes from transcript replay.
- Tool — each plugin is an independent process exposing a capability; its crash only affects the harness calling it.
- Transcript — an append-only JSONL write-only log owned by no process, recording every round, input, tool call, result, and streamed text. Mathematically, it is the carrier of a free monoid.
- Concurrency: 50/100/200 callers over three rounds; zero loss, zero duplication, zero mismatch (3500 calls at 200 concurrency all paired).
- Contention arbitration: 100 nodes claiming one node ID → 1 winner, 99 explicit rejections; 30 rounds of churn across 50 providers produced identical supply-change sequences in two observers.
- Router recovery: 20 kill trials, all nodes survived; median recovery 858 ms via supervision-based reconnect.
- End-to-end recovery: 80 sessions killed at four boundaries of the tool-call cycle — all recovered, zero duplicated effects; restart cost 1.36 s.
- Single vs. multi-process: recovering 5/10/20 dependencies costs 250.9/501.5/1003.0 ms serially in-process, versus ~126.3 ms in parallel with Logos; unrelated-session freeze time drops from 987.2 ms to 0 ms at 20 dependencies. The single-process advantage exists only for unloaded swaps.
Key rules: long tool results are truncated only in the projection shown to the LLM (full text stays in the file), and settlement order is *durable before visible*.
Theoretical Foundation
The paper builds on the spatiotemporal-composability calculus and proves cross-process reversibility via four lemmas whose conditions come only from the calculus's assumptions plus the stateless LLM call interface:
1. Orchestration Externality — each LLM call is a stateless pure function; state lives outside the call, so calls can run in any process. 2. Carrier Substitution — state can migrate to any durable carrier; recovery from it is observationally equivalent to in-place recovery. 3. Recovery Localization — component recovery needs no coordination with other components. 4. External Resolution — dependency resolution moves to a capability-name-indexed routing table on the bus.
Together these yield Theorem 1: spatiotemporal composability holds across process boundaries.
Key Mechanisms
Cold switching: when a harness dies, a new process reads the session's transcript, replays recorded steps, and continues—with the guarantee that recorded effects are never re-executed.
Language neutrality: the Go-based router, Python-based harnesses, and Node.js tools all run as peer nodes on the same bus.
Performance Results
| Metric | Value | |---|---| | Bus hop median latency | 0.215 ms (p99: 0.377 ms, max 3.045 ms) | | In-process call median | 0.005 ms | | LLM first-token median | 177 ms | | LLM full inference median | 1896.8 ms |
Bus overhead is 43× an in-process call but only 1/823 of first-token latency—effectively invisible. Other results:
Comparison with Existing Frameworks
| Feature | LangGraph | AutoGen | Temporal | Logos | |---|---|---|---|---| | Process isolation | ❌ | ❌ | ⚠️ workflow engine | ✅ per-plugin process | | Fault recovery | ❌ | ❌ | ✅ event replay | ✅ cold switch + write-only log | | Formal guarantees | ❌ | ❌ | ⚠️ partial | ✅ calculus-based theorem | | Multi-language | ❌ | ❌ | ⚠️ SDK-limited | ✅ protocol-neutral | | Hot plugin swap | ❌ | ❌ | ⚠️ redeploy | ✅ dynamic mount | | Failure isolation | ❌ total loss | ❌ total loss | ⚠️ workflow granularity | ✅ per-node |
Limitations
1. The router is currently a single point (death only affects the routing-change window, but sharding is future work). 2. Proofs need per-key verification and formal semantics for loss/partition/reconnection. 3. Tests ran on one machine; true cross-machine distribution is unverified. 4. Provider scale tested at 50; 1000+ remains open.
Why It Matters
As agents move from demos to production, reliability becomes the hardest requirement. Logos's core contribution is proving that agent reliability can be guaranteed through formal methods plus a distributed architecture—with no added mathematical assumptions. When one plugin dies, the others are unaffected; session state lives in an append-only log, and a fresh process inherits memory in about a second and keeps running.