The Log is the Agent

Its core idea is: don’t treat the log as a byproduct of the agent; instead, treat the append-only event log as the agent itself.

In ActiveGraph, goals, rules, tool calls, LLM responses, artifacts, and relations are all written into the same event log; the current state is just a graph projected after replaying the log.

This brings three key capabilities:

• Deterministic replay
• Forking experiments at any event
• Tracing from the final output back to specific model calls and evidence chains

This is not a “smarter agent,” but an underlying architecture more suitable for long-running, auditable, and evolvable agents. https://arxiv.org/abs/2605.21997

The Log is the AgentOpen source (Apache-2.0): https://github.com/yoheinakajima/activegraph. Install with pip install activegraph and reproduce the worked example with activegraph quickstart. Documentation: https://docs.activegraph.ai. Event-Sourced Reactive Graphs for Auditable, Forkable Agentic Systems

Source: https://arxiv.org/html/2605.21997

Abstract

Most agent frameworks are builtaroundthe language model: a conversation loop comes first, then tools, then rules, and finally a logging layer bolted on for observability, with state persisted as retrievable “memory.” We describe ActiveGraph, a runtime that inverts this arrangement. The append-only event log is the source of truth; the working graph is a deterministic projection of that log; and behaviors—ordinary functions, classes, LLM-backed routines, or logic attached to typed edges—react to changes in the graph and emit new events. No component instructs another; coordination happens entirely through the shared graph. This single design decision yields three properties that retrieval-and-summarization memory systems do not provide: deterministicreplayof any run from its log, cheapforkingthat branches a run at any event without re-executing the shared prefix, and end-to-endlineagefrom a high-level goal down to the individual model call that produced each artifact. We present the architecture, a determinism contract that makes replay sound, and a worked diligence example whose full causal structure is reconstructable from the log alone. We discuss—without claiming to demonstrate—why this substrate is unusually well suited to self-improving agents, and how it extends the BabyAGI lineage and prior graph-memory research.

1Introduction

The dominant pattern for building LLM agents grows by accretion. We begin with a chat loop, because conversation is the interface the model was trained for. We add tools when the model needs to act on the world. We add rules and guardrails when the behavior drifts. We add logging because, in production, we need to know what happened. And we store some compressed form of the interaction—summaries, embeddings, a vector index—so the agent can “remember” across turns. In this arrangement the log is abyproduct: an audit artifact written alongside the real computation, never the substrate of it.

This paper describes a runtime built on the opposite assumption. What if the log were not a byproduct but the agent itself? Concretely: what if the rules an agent follows (and the changes to those rules), the tools it is given and the calls it makes, and the content it produces were all the same kind of thing—events in a single append-only log—and the agent’s behavior were nothing more than a set of reactions that fire when that log grows and write new events back into it?

ActiveGraph is that runtime. The event log is the source of truth. The graph that behaviors read and write is a projection of the log, recomputed by areplayoperation that is guaranteed deterministic. Behaviors subscribe to patterns over events and graph shape; when a matching change occurs, the behavior fires, possibly calls a model or a tool, and emits the resulting facts as new events. There is no orchestrator threading state between steps, and there are no workflows in the usual sense—only a population of rule-like behaviors that sometimes chain because one behavior’s output is another’s trigger.

This is a direct descendant of BabyAGI[1 (https://arxiv.org/html/2605.21997#bib.bib1)], which expressed an agent as awhile-loop over a global task list: execute the current task, summarize it against the objective, generate follow-up tasks. ActiveGraph re-expresses that same loop as reactive behaviors over a shared graph, and in doing so converts the agent’s transient state into a durable, inspectable, replayable artifact.

Contributions.

This is a systems paper; its contributions are architectural, not empirical claims about task performance:

1. 1.An event-sourced agent modelin which graph state is a deterministic fold over an append-only event log, and all agent action is expressed as behaviors that react to graph changes and emit events (§2 (https://arxiv.org/html/2605.21997#S2), §3 (https://arxiv.org/html/2605.21997#S3)).
2. 2.A determinism contract and replay mechanismthat makes any run byte-reproducible from its log, including a content-addressed cache that records model and tool responses so replay performs no new model calls (§4 (https://arxiv.org/html/2605.21997#S4)).
3. 3.A forking and structural-diff primitivethat branches a run at any event and answers counterfactual “what if I had done X differently” questions without re-executing the shared prefix (§5 (https://arxiv.org/html/2605.21997#S5)).
4. 4.A worked, fully reproducible example(an investment-diligence pack) in which the entire causal chain from goal to memo is recoverable from the event log, demonstrating lineage as a first-class deliverable (§6 (https://arxiv.org/html/2605.21997#S6)).

We are careful about what we donotclaim. We do not report that ActiveGraph improves task accuracy over any baseline; the contribution is the substrate and its guarantees. We discuss self-improving agents in §7 (https://arxiv.org/html/2605.21997#S7)strictly as an affordance the architecture enables, not as a result we evaluate.

2Motivation: built around the model versus built on the log

Consider what an agent’s state actually consists of. There is the objective. There are the rules it operates under, which may themselves change mid-run. There are the tools available and the record of which were called with what arguments. There is the conversation or reasoning trace. And there is whatever the agent has produced. In the conventional architecture these live in different places: the objective in a prompt, the rules in code or a system message, the tool calls in a framework’s internal state, the trace in a transcript, the outputs in a database, and a lossy projection of all of it in a “memory” store queried by similarity.

ActiveGraph collapses these into one substrate. Every one of them is an event. A rule change is an event. A tool call and its response are events. A produced claim is an event that creates an object, and the link from that claim to the evidence supporting it is another event that creates a relation. Because they are all events in one ordered log, the questions that are awkward or impossible in the conventional architecture become trivial:*Why is this fact in the agent’s working set? What did the agent believe before it changed rule R? What would have happened had it taken the other branch at step 42?*Each of these is a query over, or a re-projection of, the log.

It is tempting to motivate this by analogy to human cognition—we, too, are arguably shaped less by a reasoning engine than by an accumulated history of experiences and the beliefs they produced. We note the analogy only in passing and rest no argument on it; the case for the architecture is mechanical, not cognitive, and is made in the sections that follow.

The borrowed ideas are not new in isolation. Event sourcing and command-query responsibility segregation are established patterns in data systems, and reactive recomputation of derived state from a changing input is the core of incremental dataflow and of spreadsheet engines. The contribution here is the recombination: applying an event-sourced, reactive substrate to the specific problem of long-running agentic systems, where the payoff—auditable lineage, deterministic replay, and cheap counterfactual forks over computations that include nondeterministic model calls—is both non-obvious and, we argue, unusually valuable.

3Architecture

Refer to captionFigure 1:The ActiveGraph runtime as a cycle. The append-only event log (bottom) is the source of truth.Replayfolds the log into the graph (a projection of typed objects and relations). Behaviors subscribe to graph-shape patterns, react to matching changes by calling models or tools, and emit new events back into the log. Operations on the log—deterministic replay, fork-and-diff, and lineage—follow from the log being primary.### The graph is a projection of the log.

The runtime holds an append-only sequence of events. Graph state—a typed set of objects and relations—is never mutated directly by external code; it is computed by folding the event log forward. Loading a run from a store, forking it, or validating it all invoke the same underlyingreplayoperation that rebuilds the graph from its events. Two replays of the same log produce deterministically identical state.

Events.

Every event carries an id, a type, a payload, the actor that produced it, an optionalcaused_bypointer to the event that triggered it, and a timestamp. Listing1 (https://arxiv.org/html/2605.21997#LST1)shows the opening events of a real run: a pack loads, a goal is created by the user, a behavior starts in response, and an object is created carrying aprovenanceblock that names the behavior that created it and the event that caused it.

{

“id”:“evt_001”,

“type”:“pack.loaded”,

“actor”:“runtime”,

“caused_by”:null,

“payload”:{

“name”:“diligence”,

“version”:“0.1.0”,

“object_types”:[

“company”,

“document”,

“question”,

“claim”,

“...”

],

“behaviors”:[

“diligence.company_planner”,

“diligence.question_generator”,

“...”

]

}

}

{

“id”:“evt_002”,

“type”:“goal.created”,

“actor”:“user”,

“caused_by”:null,

“payload”:{

“goal”:“Diligence:NorthwindRobotics”

}

}

{

“id”:“evt_003”,

“type”:“behavior.started”,

“actor”:“runtime”,

“caused_by”:“evt_002”,

“payload”:{

“behavior”:“diligence.company_planner”,

“event_id”:“evt_002”

}

}

{

“id”:“evt_004”,

“type”:“object.created”,

“actor”:“diligence.company_planner”,

“caused_by”:“evt_002”,

“payload”:{

“object”:{

“id”:“company#1”,

“type”:“company”,

“data”:{

“name”:“NorthwindRobotics”

},

“provenance”:{

“created_by”:“diligence.company_planner”,

“caused_by_event”:“evt_002”

}

}

}

}

{

“id”:“evt_005”,

“type”:“behavior.completed”,

“actor”:“runtime”,

“caused_by”:“evt_002”,

“payload”:{

“behavior”:“diligence.company_planner”,

“event_id”:“evt_002”

}

}

Listing 1:Opening events of a real run (abridged from the captured 671-event log). Each object’sprovenancerecords the behavior and causing event; nothing is created without a traceable origin.

Behaviors.

A behavior is a reaction. It declares a subscription—an event type plus an optional predicate and a graph-shape pattern expressed in a Cypher subset—and a body. When a matching change lands on the graph, the runtime fires the body, supplying the triggering event, a view of the graph, and a context handle. The body may create objects and relations, apply patches to existing objects, call tools, or call a model; whatever it does is recorded as events. Bodies come in four forms: a plain function, a class (for behaviors that carry configuration), an LLM-backed routine (whose request and response are themselves logged events), and arelation-behavior—logic attached to a typed edge, so that the act of relating two objects can itself carry computation.

Why a graph, and not just a log.

Event sourcing alone would give a log and a flat projection of current values; the graph earns its place by changing what behaviors cansubscribe toand what operations are cheap. Three things depend on it specifically. First, subscriptions are graph-shape patterns, not just event-type filters: a behavior can fire on “aclaimthataddressesan unansweredquestion,” a predicate over topology that a flat event stream cannot express without the consumer rebuilding the graph itself. Second, relation-behaviors make typed edges first-class carriers of logic, so computation attaches to therelationshipbetween objects, not only to the objects—there is no natural place for this in a keyed key-value projection. Third, the structural diff of §5 (https://arxiv.org/html/2605.21997#S5)is a diff over graph topology (which objects, relations, and patches differ between two runs), which is well-defined precisely because the projection is a graph rather than an opaque blob. The log is what makes state reproducible; the graph is what makes reactivity and comparison expressible. Neither alone is sufficient. Table1 (https://arxiv.org/html/2605.21997#S3.T1)summarizes how these properties distinguish the log-primary design from conventional agent loops and from memory-layer systems.

Table 1:Where the architectures differ. ActiveGraph’s column follows from treating the event log as primary rather than as a byproduct. “Partial” marks properties a system offers in a limited or non-guaranteed form.

No workflow—but not no coordination.

There is no top-level script sequencing the steps of a run. The diligence example in §6 (https://arxiv.org/html/2605.21997#S6)produces 93 objects and 76 relations across three companies without a single line of orchestration code: a planner behavior reacts to a goal by creating a company; a question-generator reacts to the company by emitting research questions; a researcher reacts to each question; and so on. The control flow is an emergent consequence of which events match which subscriptions. We are careful not to overstate this: coordination has not vanished, it has moved. What was explicit orchestration in a workflow engine becomes implicit coordination through the shared graph and its subscriptions. The claim is not that coordination disappears but that making it implicit and data-driven—rather than encoding it in a control-flow script—is what makes runs uniformly replayable, forkable, and inspectable, because every coordinating decision is itself an event rather than a position in some external program counter.

The determinism contract.

Because state is a fold over the log, replay can only be sound if behavior bodies are deterministic functions of their inputs. The runtime therefore imposes a contract: a behavior body must not readrandom, wall-clock time, or fresh UUIDs directly (it obtains these from the event, which carries a recorded timestamp, or from the runtime’s deterministic id generator); it must not perform I/O outside the framework’s tool and model primitives; and it must not depend on mutable global state that changes across fires. The contract is not statically enforced. A behavior that violates it runs correctly the first time and is caught later, at replay or fork, as a divergence error pinned to the first event that fails to reproduce. The next section explains why that is sufficient.

The apparent exception is the case that matters most: an LLM-backed behavior, which is what makes ActiveGraph an agent rather than a workflow engine. A model call is not a deterministic function of its inputs, so such a behavior does not satisfy the contract atfirst execution. The framework does not require it to. The call goes out live, and its response is recorded as an event; the contract applies toreplay, where that recorded response is served from cache (§4 (https://arxiv.org/html/2605.21997#S4)) and the behavior consequently reproduces exactly. Determinism is thus a property of re-projecting a log that already exists, never a claim that running the agent is reproducible. This is a deliberate division of labor: behaviors may freely call models and tools at execution time, and the recording layer is what makes the resulting run