Logos: An Agent Harness on a Cross-Process Bus — Paper Breakdown
This post dissects the Logos paper (AAMAS 2027, arXiv: 2608.28553), which redesigns AI agent fault tolerance by splitting agents across processes connected by a message bus.
The Problem: Single-Process Agent Architecture
Typical agent systems run all plugins (weather lookup, payments, email) in one process sharing one event loop and one failure domain. One uncaught exception in a third-party SDK kills the entire process:
- All in-flight sessions die at once
- Plugin upgrades, config reloads, and new tools all require restarts
- Every online user suffers every downtime
- Router (Go): maintains a rebuildable node registry, forwards messages by recipient; its death doesn't affect other nodes.
- Harness (Python): one process per session, running input synthesis → LLM call → output settlement.
- Tool (any language, e.g., Node.js): each plugin is an independent process; crashes affect only callers.
- Transcript: an append-only JSONL log owned by no process, recording every round (inputs, tool calls and results, streamed text). Mathematically a carrier of the "free monoid." Settlement order: durable before visible.
- Paper: Logos: An Agent Harness on a Cross-Process Bus (AAMAS 2027)
- arXiv: 2608.28553
- Authors: Hanzhang Jia, Liheng Zeng, Hao Cheng, Yi Gao, Bo Ma
- Code reference: DeepSeek harness (v0.1.0-rc.5)
The Idea: Separate Organs from the Body
Authors from the University of Sussex, Zhejiang Gongshang University, and Shanghai Shuyuan Information propose Logos: agents' "brains" and "organs" live in different processes and communicate via a bus, with formal correctness preserved.
The foundation is a spatiotemporal-composability calculus. Logos proves its reversibility guarantee holds across process boundaries via four lemmas:
1. Orchestration externality — LLM calls are stateless pure functions; state lives outside the call, so calls can execute in any process given the context. 2. Carrier substitution — session state can migrate to any durable carrier; recovery from it is observationally equivalent to in-place recovery. 3. Recovery localization — component recovery requires no coordination with other components. 4. External resolution — dependency resolution moves to an external capability-name routing table.
Theorem 1 (cross-process reversibility): these lemmas' conditions derive solely from the calculus's assumptions plus the stateless LLM interface, so spatiotemporal composability holds across processes.
Architecture: ROS's Soul, an Agent's Body
Logos borrows ROS's peer-process, name-routed philosophy:
Cold Switching
When a harness dies, a new process replays the session transcript and resumes from the breakpoint, with a guarantee that recorded effects are not re-executed. Tests injected kills at four boundaries (during tool execution, after return before persistence, after persistence before broadcast, after broadcast) across 80 sessions — all 80 recovered with zero duplicated effects.
Performance
| 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× in-process calls but only 1/823 of LLM first-token latency — effectively invisible. Stress tests (50/100/200 concurrent callers, 3500 calls) achieved zero loss, duplication, or misrouting. Router kill recovery: 858 ms median over 20 trials; end-to-end session restart cost: 1.36 s.
Single- vs multi-process comparison: single process is faster only for empty-load swaps (250.9 ms for 5 dependencies vs 126.3 ms + parallelism for Logos), but with real work, serial re-execution erases the advantage — 20-dependency recovery took 1003.0 ms single-process and froze unrelated sessions 987.2 ms, vs 0 ms frozen sessions under Logos.
Comparison with Existing Frameworks
| Feature | LangGraph | AutoGen | Temporal | Logos | |---|---|---|---|---| | Process isolation | ❌ single | ❌ single | ⚠️ workflow engine | ✅ per-plugin process | | Fault recovery | ❌ none | ❌ none | ✅ event replay | ✅ cold switching + append-only log | | Formal guarantees | ❌ | ❌ | ⚠️ partial | ✅ calculus-based theorems | | Multi-language | ❌ Python-centric | ❌ Python-centric | ⚠️ SDK limits | ✅ protocol-neutral | | Hot plugin updates | ❌ restart | ❌ restart | ⚠️ redeploy | ✅ dynamic mount | | Plugin fault isolation | ❌ everything dies | ❌ everything dies | ⚠️ workflow granularity | ✅ single-node isolation |
Limitations
1. The router is currently a single point (further sharding is possible) 2. Proof coverage needs per-key verification and formal semantics for loss/partition/reconnection 3. Evaluation was on one machine; true multi-machine distribution is untested 4. Provider churn tested at 50; 1000+ untested
Why It Matters
As agents move from demos to production, reliability becomes the hardest requirement. Logos's core contribution is proving agent reliability can be grounded in formal methods plus distributed architecture, with lemma conditions drawn entirely from existing assumptions — a deployable design, not castles in the air: one plugin dies, the rest are unaffected, session state lives in an append-only log, and a fresh process inherits memory in about a second and keeps running.