How Does ActiveGraph Make AI Agents Resumable?

TL;DR

ActiveGraph makes long-running agents easier to audit and resume by treating one immutable, typed event log as the agent’s ground truth. Actions and agent changes update a projected graph, while independent behaviors react through shared state. This design provides native replay, rollback, and forking, with policies controlling which modifications are automatic, tested, or sent for human approval.

Transcript

[music] >> Hi everybody. Thanks for coming. I'm excited to be here. AI engineer warfare has been so fun meeting everybody. Um, but I'm here to talk about active graph, which is my new open-source experimental approach to building agents, which looks a little bit different than maybe you've been building agents. Uh, it's definitely experimental. The... Read More

Key Insights

• ActiveGraph is an event-sourced graph runtime that treats a typed, immutable event log as the source of truth for both an agent’s actions and its internal changes. The log projects a graph representing the agent’s current state.
• The log-centric architecture replaces direct communication among LLM components with shared graph state. Each component observes relevant changes and emits events, reducing dependence on a single conversational loop while preserving a complete record of how execution progressed.
• Behaviors are workers that subscribe to graph changes and produce new events. A planner can react when a goal is created, add research and writing tasks, and connect them so completing research unblocks the memo-writing task.
• Behavior subscriptions can use graph queries to detect complex conditions. A contradiction detector, for example, can activate when a newly created claim conflicts with another claim, and subscriptions may also incorporate criteria such as confidence percentages.
• Views provide context by selecting a relevant subset of the graph for a behavior. This makes context management programmable through graph queries while still allowing other context-management methods to be used where they are appropriate.
• Policies determine which graph modifications are permitted and which require safeguards. Adding a research source may be allowed automatically, while changing a prompt can require human involvement and changing a fact can require checking for contradictions.
• Replay, rollback, and forking follow naturally from the immutable event log. During a 500-question evaluation, an expired API key interrupted execution around question 350, but the system rolled back one step and resumed at question 353 instead of restarting.
• Log-based memory can combine structured sequence information with embeddings. In the LongMemEval experiment, the query was embedded, relevant messages were retrieved with nearby messages before and after them, and the resulting selection was fitted into the available context.

Questions & Answers

Q: What is ActiveGraph and how does it structure an AI agent?

ActiveGraph is an event-sourced graph runtime for building auditable agents. It records every action and every change to the agent in one immutable, typed event log. That log serves as ground truth and projects a graph representing current state. Behaviors observe graph changes and emit additional events, so execution proceeds through shared state instead of direct communication among LLM components.

Q: How does ActiveGraph differ from an LLM-centered agent architecture?

An LLM-centered architecture begins with a model, then adds tools, memory, response handling, and logging around it. ActiveGraph begins with the log itself. Actions and agent modifications enter the same immutable history, which projects shared graph state. Behaviors, including LLM-powered ones, react to that state and communicate by emitting events rather than sending messages directly to one another.

Q: How do behaviors work in ActiveGraph?

Behaviors subscribe to graph changes and emit events that update the graph, potentially activating other behaviors. They may be deterministic or include LLM reasoning. A planner can respond to a newly created goal by adding research and memo-writing tasks, while a relation behavior can make completion of the research task unblock the writing task. Subscriptions can also contain graph-query conditions.

Q: What are policies used for in ActiveGraph?

Policies define how the graph is allowed to change. They can permit routine additions directly while requiring a proposed patch, testing, contradiction checks, or human approval for more sensitive modifications. The examples distinguish adding a research source from changing a prompt or fact. This gives the runtime explicit control over what an agent may alter autonomously and what requires additional review.

Q: Why does ActiveGraph support replay, rollback, and forking?

Replay, rollback, and forking are supported because the agent’s history is stored as an immutable sequence of typed events. The current graph is projected from that history, so execution can be reconstructed, moved back to an earlier point, or branched. In one evaluation, an API-key failure did not require restarting all completed work because the run could roll back and resume near the interruption.

Q: How can the ActiveGraph log be used as agent memory?

The event log can serve as memory because it contains both content and structured sequence information. In the LongMemEval experiment, the system embedded the query, found relevant messages, retrieved several messages before and after those results, and fitted the selection into context. The initial approach did not use semantic ingestion, fact extraction, or entity extraction, although later experiments added semantic ingestion.

Q: Can familiar agent architectures be built on ActiveGraph?

Familiar agent harnesses can be reconstructed on top of ActiveGraph by expressing their steps as behaviors that observe and modify shared state. The presentation demonstrates a ReAct-style agent in which creation of a goal adds a thought and creation of a thought triggers reasoning. The sequence is familiar, but the components coordinate through graph events rather than direct calls or messages.

Q: How does ActiveGraph support agent self-improvement?

ActiveGraph supports self-improvement by recording agent changes in the same event system as ordinary execution and controlling those changes with policies. The described loop can fork the agent, propose a patch, run sandbox tests, and retain the patch only when accuracy improves. A related lab reads the creator’s blog posts, runs experiments, and once identified a bug in its own code and opened a pull request.

Summary & Key Takeaways

• ActiveGraph reverses the usual LLM-centered architecture by building an agent around its log. Every action and every change becomes an immutable, typed event. Those events project the agent’s current graph state, keeping execution history, memory, and agent evolution together while enabling replay, rollback, and branching from earlier states.

• Behaviors monitor selected graph changes and respond by emitting new events. They can be deterministic or use LLM reasoning, and they communicate only through shared state. Graph-query subscriptions can detect conditions such as contradictory claims, while views supply each behavior with a relevant subset of the graph as programmatically managed context.

• Policies govern how the graph may change, including whether a modification can happen directly or needs a proposed patch, tests, contradiction checks, or human approval. Schemas, tools, behaviors, views, and policies can be assembled into modular packs, allowing familiar agent patterns and self-improvement workflows to run on the same event-sourced foundation.