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

Architecture

• ActiveGraph replaces transient agent state with reactive behaviors over a shared graph, whose state is a deterministic projection of the append-only event log.This re-expresses the BabyAGI task loop as reactive behaviors and makes transient state durable, inspectable, and replayable.Source: §1 · p. 2

Replay

• A determinism contract and content-addressed cache make runs byte-reproducible from their logs without new model or tool calls during replay.The cache records model and tool responses; replay uses those recorded responses rather than assuming model calls are reproducible.Source: §1 · p. 2

Forking

• Forking branches a run at any event and supports structural comparison without re-executing the shared prefix.The primitive supports counterfactual questions about changing an earlier action.Source: §1 · p. 2

Worked example

• The worked investment-diligence example is fully reproducible, with its entire causal chain from goal to memo recoverable from the event log.The authors present lineage as a first-class deliverable.Source: §1 · p. 2

Scope

• The paper presents architectural contributions, not evidence that ActiveGraph improves task accuracy over a baseline.Self-improving agents are discussed as an architectural affordance, not demonstrated or evaluated.Source: §1 · p. 2

Conventional architecture

• Conventional agents scatter objectives, rules, tool calls, traces, outputs, and lossy memory across separate stores.The log is typically an audit byproduct rather than the substrate of computation.Source: §2 · p. 2

One substrate

• ActiveGraph represents rules, tool calls and responses, produced claims, and evidence links as events in one ordered log.Replay folds the log into a graph projection of typed objects and relations.Source: §2 · p. 2, Figure 1 · p. 3

Queries over history

• Questions about why a fact entered the working set, what preceded a rule change, or what another branch would yield become queries or re-projections of the log.These questions are awkward or impossible in the conventional architecture.Source: §2 · p. 3

Architectural motivation

• The contribution recombines established event-sourcing and reactive-recomputation ideas for long-running agents, where model calls complicate replay and counterfactual forks.The paper describes this application as non-obvious and argues that its payoff is unusually valuable.Source: §2 · p. 3

• The graph is a projection of the event log, rebuilt by folding events forward so repeated replays produce identical state.Source: §3 · pp. 3–4
• In the captured run, each created object’s provenance identifies the behavior and event that caused it.Source: §3 · p. 5
• Behaviors subscribe to event and graph patterns, then run as functions, classes, LLM-backed routines, or logic attached to typed edges.Source: §3 · p. 5
• Graph-shape subscriptions, relation-behaviors, and topology diffs make the graph useful for reactivity and comparison, while the log supplies reproducible state.Source: §3 · p. 5
• Coordination emerges when one behavior’s output matches another’s subscription, replacing an external control-flow script without eliminating coordination.Source: §3 · p. 6
• The determinism contract bars behaviors from using unrecorded randomness, time, UUIDs, external I/O, or changing global state; model responses are recorded for deterministic replay.Source: §3 · p. 6

• Given a log, replay deterministically reconstructs identical graph state on every run.Source: §4 · pp. 6–7
• Content-addressed model and tool responses are served from the log during replay, avoiding new calls when request hashes match.Source: §4 · p. 7
• The recorded response makes replay deterministic, but the paper does not claim that live agent execution or model inference is reproducible.Source: §4 · p. 7
• Strict replay compares re-fired behaviors’ events against the recorded stream and reports the first divergence; permissive replay can make fresh calls when hashes differ.Source: §4 · p. 7

• A fork copies the parent’s events through a chosen cutoff, then continues independently so the runs can be configured and compared without changing the parent.Source: §5 · p. 8
• Forks replay the shared prefix from cache rather than rerunning behaviors or making model and tool calls, so only post-cutoff execution is new.For a 200-step run forked at step 150, the first 149 steps, including model calls, are free.Source: §5 · p. 8
• Matching event IDs through the cutoff verify parent-fork lineage, and structural diff reports changed objects, relations, and patches.Source: §5 · p. 8
• Frames suit short-lived branches that reconverge within one run; forks suit branches needing independent persistence, inspection, or diffing.Source: §5 · p. 8

• The bundled quickstart runs offline against recorded fixtures, needs no API key, and produces byte-identical logs across runs.It completes in under thirty seconds; these counts are specific to the bundled quickstart pack.Source: §6 · p. 8
• 671 events produced 93 objects and 76 relations across three companies, using 103 model calls and 48 tool calls without orchestration code.Source: §6 · p. 9
• Each memo claim links its creating behavior and model request to the triggering event, question, source document, and supporting evidence.Source: §6 · p. 9

7 An architectural affordance for self-improving agents

• The paper does not present or measure a self-improving agent; turning these affordances into a working system remains future work.The authors claim only that the substrate removes specific obstacles to self-improvement.Source: §7 · p. 9
• Logged rules and behaviors make self-modification replayable, allowing audit and rollback to a run before the change.Strict replay also reveals how behavior diverged after modification.Source: §7 · p. 9
• Fork-and-diff can compare a proposed change with its parent without repaying for the shared history.The proposed change is applied in a fork that is run forward and structurally diffed against the parent.Source: §7 · p. 9

8 Related work

• Unlike layered memory systems [2], [3], [4], [5], ActiveGraph makes the log primary, yielding total provenance and exact replay; prior graph-memory research motivated this inversion.The cited systems improve personalization and context carry-over but retain a dedicated memory layer feeding an otherwise stateless model.Source: §8 · pp. 9–10
• ActiveGraph applies event sourcing and reactive dataflow to agents with nondeterministic model calls, handled through a content-addressed response cache.The paper identifies the underlying mechanisms as established data-systems patterns rather than new contributions.Source: §8 · p. 10
• Blackboard systems share the model of independent sources reading and writing shared state; ActiveGraph adds an event-sourced substrate for replay, forks, and traceability.The paper argues that LLM-backed behaviors and natural-language or generated coordinating logic address constraints of older blackboard systems.Source: §8 · p. 10
• ActiveGraph is a direct architectural successor to BabyAGI, replacing its mutated global task list with state projected from an append-only event log.It preserves BabyAGI’s task-generating, self-extending character while making steps durable, inspectable, and replayable.Source: §8 · p. 10

9 Limitations and conclusion

• A per-run budget halts runaway cascades but does not guarantee termination; replay currently processes the full log, and concurrent or distributed writer ordering is unresolved.Schema evolution remains an operational burden, and recording side-effecting tool responses makes replay deterministic without undoing the tool’s initial external effect.Source: §9 · p. 10
• The determinism contract burdens behavior authors and is enforced dynamically; recording responses consumes storage, and prompt-changing forks re-execute affected calls.The paper reports no large-scale task-performance evaluation; its quantitative artifacts demonstrate mechanisms rather than benchmark performance.Source: §9 · p. 11
• For long-running agents that must explain, reproduce, and revise their actions, the log-based design combines deterministic replay, counterfactual forks, and lineage from goal to output.The authors present these properties as the point of the architecture, not as measured downstream task advantages.Source: §9 · p. 11