LogAct: Enabling Agentic Reliability via Shared Logs

Mahesh Balakrishnan; Ashwin Bharambe; Davide Testuggine; David Geraghty; David Mao; Vidhya Venkat; Ilya Mironov; Rithesh Baradi

cs.DCApr 9, 2026

LogAct: Enabling Agentic Reliability via Shared Logs

Authors: Mahesh Balakrishnan, Ashwin Bharambe, Davide Testuggine, David Geraghty, David Mao, Vidhya Venkat, Ilya Mironov, Rithesh Baradi,

Organizations: Meta

Abstract

Agents are LLM-driven components that can mutate environments in powerful, arbitrary ways. Extracting guarantees for the execution of agents in production environments can be challenging due to asynchrony and failures. In this paper, we propose a new abstraction called LogAct, where each agent is a deconstructed state machine playing a shared log. In LogAct, agentic actions are visible in the shared log before they are executed; can be stopped prior to execution by pluggable, decoupled voters; and recovered consistently in the case of agent or environment failure. LogAct enables agentic introspection, allowing the agent to analyze its own execution history using LLM inference, which in turn enables semantic variants of recovery, health check, and optimization. In our evaluation, LogAct agents recover efficiently and correctly from failures; debug their own performance; optimize token usage in swarms; and stop all unwanted actions for a target model on a representative benchmark with just a 3% drop in benign utility.

Figures & tables

Panel of Figure 1 — Figure 1. Existing ReAct / CodeAct agents run in an imperative loop; LogAct is a state machine playing a shared log.

Approach	Key Idea	Assumes	Why Agents Break It
WAL ( Mohan et al., 1992 )	Log before acting	Structured txns with schema + undo/redo	Actions are arbitrary lambdas; no schema
SMR ( Schneider, 1990 )	Replicated state machine on a log	Full, isolated state copy; deterministic execution	Acts on external environment; non-deterministic
Checkpoint ( Chandy and Lamport, 1985 )	Periodic snapshots; restore on failure	State is local and checkpointable; deterministic	External environment not checkpointable; non-deterministic
Durable Workflows ( 30 , 27 )	Record non-det ops; replay on recovery	Predefined control flow; explicit compensating actions	Open-ended control flow (LLM-driven); no predefined undo

Table 1. Existing fault-tolerance approaches and their limitations for agents. None addresses agentic safety.

Figure 2. The LogAct state machine. The agent cycles through four stages; each stage is triggered by playing a typed log entry and concludes by appending one.

Figure 3. A deconstructed LogAct agent on the AgentBus. Physical nodes – Driver, Voter(s), Decider, and Executor – each append and play a subset of entry types.

Entry Type	Appended By	Played By
Mail (inbound)	External entities	Driver
Inference output	Driver	Driver, Voters (opt.)
Intention	Driver	Voters
Vote	Voters	Decider, Voters (opt.)
Commit	Decider	Executor
Abort	Decider	Driver

Table 2. Entry types on the AgentBus, and which components append and play them.

Property	Claude Code	AnonHarness	LogClaw
Integration	Hooks	Surgical	Native
Introspection	Limited	Full	Full
Voter Separation	✓	✓	✓
Driver/Executor Sep.			✓

Table 3. Properties of each LogAct harness implementation.

Figure 5. LogAct imposes low overhead. For a simple task (write a C file, compile, run): (Top) most time is spent in inference rather than voting / deciding; (Middle) logging imposes low storage overhead (2.6KB/s); (Bottom) inference continues to dominate even with slower backends.

Figure 6. LogAct stops all unwanted actions with a rule-based Voter; and restores benign Utility with a dual Voter quorum. Left: Target (No Defense) has high benign Utility, but also an unacceptable ASR; a rule-based Voter stops all unwanted actions (1.4% involve action-less attacks) but also lowers Utility; while a dual voter quorum (rule-based + LLM) restores Utility. Right: Dual voter adds 82% latency and uses 13% more tokens compared to Target (No Defense).

Figure 7. Voters can be hot-swapped. We first add a rule-based Voter to stop attacks; and later, add a second LLM-based Voter to restore Utility. Each switch involves a dynamic change of Decider policy via the AgentBus.

Figure 8. Agentic introspection enables semantic recovery, health check, and optimization. Left: Phase 1 (rglob worker) processes

\sim

1200 folders over 155s before being killed. After a 31s recovery window, Phase 2 (recovery worker) processes the remaining

\sim

800 folders. Right: The recovery agent’s AgentBus. The agent introspects the crashed agent’s bus, determines what was completed, diagnoses and fixes the slow implementation, and finishes the remaining 816 folders in 0.36s.

Figure 9. Agentic introspection makes swarms faster and cheaper. A supervisor agent inspects each AgentBus and sends mail in a 6-agent swarm, resulting in 17% more work for 41% less token usage.

LLM Agent Reliability

Large language model (LLM) agent reliability concerns dependable, safe, and verifiable behavior across tools, multi-step tasks, and changing environments.

See all 832 papers

Sentry: Learning to Recover from LLM Agent Failures at Test Time
Oct 2, 2026Changxiu Ji, Amy Lu, Qizheng Zhang +1LLM Agent Reliability Memory-Augmented Language Model Agents
Department of Computer Science, Stanford University
AgileLog: A Forkable Shared Log for Agents on Data Streams
Apr 16, 2026Shreesha G. Bhat, Tony Hong, Michael Noguera +2LLM Agents
University of Illinois Urbana-Champaign
The Log is the Agent: Event-Sourced Reactive Graphs for Auditable, Forkable Agentic Systems
May 21, 2026Yohei NakajimaAI Agent Auditing Agent Memory Management
Untapped Capital

Oct 2, 2026J/K move · Enter open · S save

Sentry: Learning to Recover from LLM Agent Failures at Test Time

Changxiu Ji, Amy Lu, Qizheng Zhang, Kunle Olukotun

Department of Computer Science, Stanford University

LLM Agent Reliability Memory-Augmented Language Model Agents

Open paper AskPDF arXiv

LLM agents often fail mid-task due to invalid tool calls, repeated actions, or poorly grounded reasoning, and learning from these failures is a path to reliability. We find that how failure knowledge reaches the agent matters as much as what it contains. Failure lessons are conditional: kept in the agent's context, they misfire when their failure is absent, and removing them from an evolving playbook improves performance. Runtime interventions, in contrast, act only when a failure occurs but do not learn from their repairs. We argue that failure knowledge is conditional knowledge and should be conditionally exposed, and instantiate this principle in Sentry, a failure-management layer that runs alongside the agent. When Sentry detects a failure, it retrieves matching lessons from an external playbook to guide recovery, verifies without access to task rewards whether the agent recovered, and stores a new lesson only if it did; the full playbook never enters the agent's context. Across multiple agentic benchmarks, Sentry outperforms the strongest runtime-intervention baseline on every benchmark, by 37% on average, and the strongest context-evolution baseline by 39% on the two benchmarks where both are evaluated; combining Sentry with context evolution yields further gains. Learned lessons transfer to held-out tasks, and controlled experiments show that exposing the full playbook to the agent lowers performance even when relevant lessons remain available on demand.

Abstract

LLM Agent Reliability

Explore similar work

Sentry: Learning to Recover from LLM Agent Failures at Test Time

AgileLog: A Forkable Shared Log for Agents on Data Streams

The Log is the Agent: Event-Sourced Reactive Graphs for Auditable, Forkable Agentic Systems