# Active Graph Agent Runtime (BabyAGI 4) — Yohei Nakajima, Untapped Capital

AI Engineer · 2026-07-22

<https://aiengineer.podhood.com/ce036ae5-b571-4cbf-8094-a9c5ebf33abd>

Yohei Nakajima presents ActiveGraph, an event-sourced graph runtime that flips agent architecture around an immutable event log instead of the LLM, enabling native replays, rollbacks, and forks. He explains how behaviors react to graph changes and emit events, policies control which modifications require human approval or contradiction checks, and packs bundle object schemas, tools, and LLM behaviors. Nakajima demonstrates self-improvement loops that fork the agent, propose patches, run sandbox tests, and accept changes only if accuracy increases. He shares surprises: AI writes this architecture better due to decades of training data on blackboard and Kafka patterns; debugging shifted to querying the ActiveGraph DB; long running agents resume from failures instead of restarting; and his ActiveGraph Lab found a bug in its own code and opened a PR. The episode argues that long-running agents need an experiential world model derived from their own logs, not just reasoning capability.

## Questions this episode answers

### What makes ActiveGraph's agent architecture different from traditional LLM-based agents?

Instead of building around the LLM and adding memory or logging, Yohei Nakajima's ActiveGraph builds around an immutable typed event log that records every action and change to the agent. This log projects a graph that is the agent's state, providing replays, rollbacks, and forks for free. LLMs never talk to each other; they communicate through shared state, inspired by blackboard architectures. Behaviors react to graph changes and emit events, creating a decoupled, auditable system.

[2:06](https://aiengineer.podhood.com/ce036ae5-b571-4cbf-8094-a9c5ebf33abd?t=126000)

### How does ActiveGraph's self-improvement 'regimes' loop allow agents to modify themselves safely, and did it actually work?

Yohei implemented a 'regimes' loop where the agent classifies failures, proposes a patch by forking itself, and gates the change behind sandbox tests. It only accepts the patch if accuracy rises on 50 held-out questions. Over 8 to 13 loops, it accepted 4 or 5 patches, yielding statistically significant improvement on long memory eval. Policies control which parts can be self-modified, ensuring controlled self-improvement.

[11:11](https://aiengineer.podhood.com/ce036ae5-b571-4cbf-8094-a9c5ebf33abd?t=671000)

### How did ActiveGraph recover from an API key failure during a long evaluation run, and why is that notable?

While running a 500-question long memory evaluation, Yohei's API key died at question 350. Instead of restarting the entire agent from scratch, ActiveGraph automatically rolled back one step and resumed from question 353 after he updated the key. This works because the immutable event log is the ground truth, enabling seamless recovery without losing progress—a benefit not typical in other agent frameworks.

[9:17](https://aiengineer.podhood.com/ce036ae5-b571-4cbf-8094-a9c5ebf33abd?t=557000)

## Key moments

- **[0:00] Intro**
  - [0:44] Yohei Nakajima's three-year research theme: "Let's build the simplest thing that can build itself."
- **[2:06] Log-centric**
  - [2:06] ActiveGraph flips agent architecture by building around an immutable event log instead of the LLM.
- **[3:01] Behaviors**
  - [4:11] Building agents on ActiveGraph's typed event log natively provides replays, rollbacks, and forks for free.
- **[6:17] Policies**
- **[6:53] Packs**
- **[8:19] Experiments**
  - [9:17] Yohei's API key died mid-eval, but ActiveGraph's log rolled back one step and resumed at question 353 instead of restarting.
- **[11:11] Self-improvement**
  - [11:11] ActiveGraph's regimes project forks the agent, proposes a patch, runs sandbox tests, and only accepts changes that increase accuracy.
  - [12:22] ActiveGraph Lab read Yohei's blog posts, ran experiments, found a bug in its own code, and opened a pull request.
- **[13:01] Pokemon test**
  - [13:01] Using ActiveGraph for a Pokemon card game competition, the agent ran 200 simulated games and only accepted changes that improved win rate.
- **[14:10] Surprises**
  - [14:41] AI appears better at architecting log-centric agents because decades of blackboard and Kafka patterns are in its training data.
- **[15:43] World model**
  - [15:43] Yohei Nakajima hypothesizes long-running agents need an experiential world model, similar to how the hippocampus replays experiences to update priors.

## Speakers

- **Yohei Nakajima** (guest)

## Topics

Agent Engineering

## Mentioned

Untapped Capital (company), ActiveGraph (product), BabyAGI (product), Claude Code (product), InstaGraph (product), Kaggle (product), LangSmith (product), MineGraph (product), Replit (product)

## Transcript

### Intro

**Yohei Nakajima** [0:13]
Hi, everybody. Thanks for coming. I'm excited to be here; AI Engineer World Fair has been so fun meeting everybody. Um, but I'm here to talk about ActiveGraph, 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 idea is more to give you, inspire you with some potentially new ideas. Um, agents are awesome, but long-running agents break. And if they're so awesome, why am I still building them? Why they should build themselves.

Let's build the simplest thing that can build itself has basically been kind of my research theme for the last 3 years, since I did BabyAGI back in March of 2023, so that's over 3 years ago. If you were there at the time, it was crazy.

It went wild, like, uh, it was covered by media. People thought it was going to work. It didn't work at all. Um, over the course of 3 years, I've done 9 iterations of BabyAGI, with less fanfare, but, you know, every time just experimenting on, like, how do we get autonomous agents to actually work, usually with the theme of self-improvement.

Uh, if you go to BabyAGI wiki, you can see earlier experiments. Um, in the in this process, I kept coming up to graph, uh, coming back to graphs, and I've had a couple of projects. Earlier I did, uh, one called InstaGraph and MineGraph that was, like, pre-graph rag-rag.

I did some code graphs, function graphs, log graphs, and since then it seems like a lot of people have started using graphs to build agents. Um, and so, in addition to that, I've actually gotten to invest in a in a good number of, you know, agentic companies, some of which you I'm sure you recognize through my fund, Untapped Capital, and I also have an agent fund.

Uh, but yeah, that's that's me. Yohei, VC by day, builder by night. You might recognize this face more than this face. Um, ActiveGraph is an event-sourced graph runtime for building auditable agents. Um, I have a paper—that was my first archive paper—called The Log is the Agent, but I'm here to explain it.

### Log-centric

**Yohei Nakajima** [2:06]
Um, so today most people build agents around the LLM. You start with the LLM, you add a response API, you give it tools, you add memory, and then you make sure you log everything correctly, which can give you, you know, all the benefits that ActiveGraph will give you.

But ActiveGraph asks, what if you built around the log? Now, what does that mean? Um, it means not everything the agent does, but more importantly, every change to the agent,right? Nobody here is using the same agent they were using a year ago, and the agent you're going to use a year from now is going to be different.

And a lot of people, what the agent does and how the agent changes are tracked in two different places. But I'm saying let's flatten that down into a single immutable event log, and this is the ground truth of the agent.

And this projects a sort of graph. This is the state of the agent. And what I mean by that is, for example, a prompt can be edited multiple times, but you might have, you know, a master prompt that gets used when you're, you know, when you query the graph.

And then on top of this, you attach something that I'm calling behaviors. Behaviors are, uh, reacts to graph changes, and then they emit events, which then in turn updates the state of the agent, which might trigger new behaviors.

### Behaviors

**Yohei Nakajima** [3:18]
Um, LLMs don't talk to each other in ActiveGraph. They all communicate through this shared state, and that's what makes it a little bit different. Behaviors can be deterministic, or they can include LLMs, which is which is how you build this agent.

And you get this beautiful typed event log. Uh, that's the source of truth about everything the agent did and everything every change that's happened, which means actually, whoa, shoot, I jumped ahead. So in addition to that, there's a concept called policies, which determine how the graph can be modified.

I'll come back to it. But for example, things like a source article that you found in research, you might be fine with adding, but if you're changing a prompt, maybe you want human in the loop. Or, uh, if you're changing a fact, you might want to make sure there's no contradicting fact.

So there's these things called policies, and again, it shows some code uh, code examples. But yeah, in the end, you get this beautiful typed event log, which gives you replays, it gives you rollbacks, and it gives you forks.

And this be comes natively when you start building agents with ActiveGraph. So this is the kind of LLM-centric versus log-centric way of building agents that I'm going to be talking about or showing you code for. And, and I'll, uh, I'll specify that this is not a harness.

It's, it's a runtime, and you can actually rebuild most of the common harnesses on top of it. You're just forcing every single communication to communicate through the shared state. So, uh, at the highest level,right, when you're building with agents, messages feels like the kind of core unit that you're seeing often, but we're going to replace that with logs.

Logs are going to be the core unit you're going to build around. That's what you're going to be reading. That's what you're going to be looking at. These are typed logs, again, immutable, clean. You can't edit the graph.

These are just kind of basic rules. Just emit events. You can have the add object, which is an event emitting. But yes, you can query over the graph. And again, I'm flying through some of this because I want to get to the fun parts, and all this is in the documentation.

Behaviors listen to graph changes and emit events. So this is a behavior, uh, called a planner that triggers on a goal created,right? And then it, uh, adds an object, adds two task objects and a relationship object, uh, research, write memo, um, two tasks.

And then actually behaviors can actually live on edges as something called a relation behavior. This one has an unblock relation, so basically when the research is done, you can write the memo,right? Um, and behavior subscriptions can be pretty complex.

They can be graph queries. So this one says, on object created, if the if the object type is a claim, uh, and this claim contradicts another claim, we're going to trigger the contradiction detector. And these can be more complex than this.

You can have, you know, uh, confidence percentages baked into it. Um, and, and then on top of that, there's another concept called views. Uh, context management can be done programmatically as basically a graph query. It's a it's you basically grab a subset of the graph, which makes it available to that behavior.

You can still do other types of context, uh, context management, but I felt like this kind of graph query as context management just felt really elegant. Candidly, I'm not the one writing the code, but AI seems to be pretty good at figuring out how to do it.

Um, and, you know, I earlier I talked about policies. So some graph changes require a proposed patch before approval. Again, this is how you these these policies kind of give it the control on what it's allowed to change by itself, what, uh, what kind of changes require certain tests.

### Policies

**Yohei Nakajima** [6:32]
Um, and I'll give a few examples in a bit. Um, or if you want human in the loop,right? And you have these kind of policies that, that determine or define, uh, what the, uh, what these rules are. And when you bring it all together, you got these kind of object schema schemas, tools, deterministic behavior, LLM behaviors can be assembled into something called a pack,right, with a pack policy.

### Packs

**Yohei Nakajima** [6:53]
And that's how you build a harness on top of ActiveGraph. And these and all this together is and I'll have a couple examples later. Um, are are modular and they can be combined. Uh, but you're not just adding skills.

It is much more complex to build. Actually pretty unintuitive. I would never write code myself with ActiveGraph, but again, AI seems really good at it. Um, and just on, like, event types are fixed. You can add custom events.

Objects are user-defined. I only added that because someone asked me that question when I was showing them these slides, but I think that makes sense. So the old way, you got the while not done if loop. The new way, or at least my new way, uh, you have a whole bunch of behaviors that don't talk to each other that just monitor the state.

So it's, it's, it's inspired by, uh, blackboard architecture from the '70s or '80s, or more recently Kafka, whole bunch of micro workers communicating through a shared state. One of the challenges, at least back when, uh, about blackboard was around, was that it was really unintuitive to write, and the workers were very slim and deterministic, but now AI writes the code, and the workers can be very powerful because they have reasoning capability.

This is a React agent on ActiveGraph. React agent was one of the earlier agent kind of architectures. As you can see, it's it look it actually works the same way, but on goal created, you add a thought. On thought created, you trigger the reason function.

So again, this is just to show that you can build any harness on top of ActiveGraph. It does look different, um, because they're not communicating with each other. And so to see if how well this can work, I've been running a lot of experiments.

Um, the first one I did was, can I use the log itself as memory? So this is not pure vector rag. It's actually leveraging the structured log so it knows which which message was before what, plus, uh, vec, uh, plus embedding the actual messages within the log.

### Experiments

**Yohei Nakajima** [8:32]
Uh, I did this on long mem eval. I embedded the query. There was no semantic, uh, ingestion, no fact extraction, no entity extraction, but I just embedded the query, looked for relevant messages, grabbed a couple messages before and after, made sure it fit into the context, and it actually did pretty well on long mem eval,right?

Like, a lot of the data in your memory is actually overlaps with the memory uh, the data in your log. Actually having them the same actually kind of makes sense and makes sure they don't separate. Um, I did try another couple other experiments on adding kind of semantic ingestion to improve the score.

I was able to do it, but candidly, um, I could put more effort into try to increase that, but I jumped onto the next experiment. Actually, but in that process, one of the biggest fun surprises was I don't know if you've run long mem eval, but you have to do like 500 questions.

And then one of the runs, uh, my API key ran out at like 350. I was like, "Oh, shoot." Okay. So I updated the API key. I said, "Okay, let's let's rerun it again." And it just, like, rolled back one and it was like, "Allright, we'll just start from, you know, question number 353."

And I don't know if you have, but, like, I've built a lot of agents that, like, where the API key did broke or something, and I had to rerun the long agent from the beginning, and that just has not been my experience since building with ActiveGraph, uh, which was a very fun surprise.

Uh, I built a couple reference agents, uh,right? Like, now I have this runtime. Let's see what I can build. I asked Replit to build a coding agent on top of ActiveGraph, and, and as a result, it came with, you know, event log graph.

And again, I'll say this. You can do this with, you know, things like Langsmith. The thing is, I don't I didn't have to think about it. I just had to ask my coding agent to use ActiveGraph, and this event log and graph came natively.

Same thing with research agent. I just said, just build a deep research agent on ActiveGraph, and it came with this beautiful, you know, had an event event log and a graph of, like, where the evidence came from, what contradicts each other.

And again, I didn't have to think about it. I just asked my agent to build a research agent on top of ActiveGraph, and this is what it ended up looking like. Um, and then I realized, okay, how do we get this closer to, like, an open claw or Hermes?

So I, I played around. I have this thing called, uh, ActiveGraph packs, which is a core pack, a tool pack, a secret pack, a memory pack, an identity pack, a communication pack, a chat pack. So now you get to kind of get the idea of how I'm trying to build agents on top of ActiveGraph.

And each of these packs have object types and behaviors. Again, feel probably feels very different from the way you're building agents, but I, I feel like it's actually pretty elegant. You can just take a memory pack and replace it with another another memory pack,right?

Um, uh, and, and it's not, like, skills, but, like, the objects and the rules and all of them are, uh, bundled as a pack, and you and you attach these packs together to create your agent.

### Self-improvement

**Yohei Nakajima** [11:11]
Um, and then I jumped into the, the what I really wanted to do was start playing with self-improvement loops. Um, I did the project called regimes. I did, uh, uh, that was in paper number two. Um, this one was a really controlled self-modification.

Uh, Claude code called it regime deceive, but basically we classified the type of failure, and then based on the failure it classified, it was allowed to edit a specific part of the agent. Again, I did this on long mem eval.

The loop was, I think, doing about 20 questions, looking at the answer in questions, seeing where it failed, trying to self-modify, trying that on 50 different questions, see if the accuracy actually went up, and only if it went up, it would accept it.

So that was kind of the proposal patch that started happening where it would do after it proposed, uh, change to itself,right? This is essentially the agent forking itself, proposing a change, doing a static gate check, a sandbox gate check, and then making sure it actually impacted the result and only then accepted a change.

And for these loops, it would loop like 8 or 13 times, but only accept four or five of those patches. And it actually did have, you know, modest, but, like, statistically significant improvement on long mem eval scores. Uh, and, and not only did it know what worked, but it also knew what didn't work.

Um, at this point, I was like, "Okay, can I can I get ActiveGraph to just research ActiveGraph for me?" So I built lab, uh, ActiveGraph lab, which is reading all the blog posts. So everything I've shared has a blog, a GitHub repo, and this lab is reading all of that to come up with new ideas, asking me if they can run it.

And if I say yes, it'll run the experiment, um, and then it'll write a blog post about it. It actually did find an error in its own code, asked me if he could if it could fix it. It wrote the PR, and then I just merged it.

Um, so it's, it's early, but it's starting to work. The lab is self-improving. Um, it also figured out that, um, it looked at ActiveGraph packs and was able to just install a pack into itself and then wrote a blog post saying, "Packs are modular between repos."

I was like, "I didn't know that. That's great." Um, and then I got distracted when I saw this Pokemon trading card game competition on Kaggle. As you can see, I'm all over the place. Um, but, uh, you have to submit this deck in a deterministic agent, not with a with an LLM, and they compete in this ELO style competition.

### Pokemon test

**Yohei Nakajima** [13:17]
So my decks are, you know, every hour they're battling a new competitor and their score goes up or down. Um, and I felt like this was a pretty good, uh, test for seeing if ActiveGraph could help me increase my score.

And I used, you know, Claude code and Replit, and we did about 80 different passes to, like, try different things and, and increase our score. You know, it might not make sense to you if you don't play Pokemon, but these things like, "Let's try adding a couple energy cards."

Seems like a very casual ask. Um, and my agent, probably because I think because I'm using ActiveGraph, would say, "Okay, sounds great. Let's run 200 simulated games against three reference agents, and then if the win rate increases by X% and there's a, you know, whatever Wilson score above 90 something, then we'll accept that as a change."

And I basically did this, like, 80 times, and each time they came with this, like, beautiful rapport of, like, why it worked, what it did, and what the verdict was. So out of those 80 passes, it probably ac uh, accepted about 20 to 30, and the score did slowly improve.

### Surprises

**Yohei Nakajima** [14:10]
I'm still at, like, 27%, so I don't know if I can get higher than that, but, um, what was most interesting is how mu how well the agent understood experiments we've tried before that didn't work. And that was a very different experience for me because I've done a lot of YOLO agents where you just, like, keep trying things and then it works.

You're like, "Yeah, but then I don't know the stuff that we tried that didn't work." But now when I'm building with ActiveGraph, it tracks all the things that didn't work because it's forced because I have this policy that says, "Here are the ch here here's what we have to do before we accept a change."

Um, so some of the pleasant surprises, most of which I mentioned, but AI does seem better at architecting this in LLM-based agents. It's just my personal experience and, you know, some some people you'll have to try it yourself to see.

But if you think about it, LLM-based agents are, like, three years old, but if you look at, again, Kafka, Blackboard, this, like, microworker communicating through a shared state, there's decades of conversations about how to make that work better.

And my hypothesis is that that's in the training data, and there's just much less training data around how to build LLM-based agents. Um, debugging shifted from session logs to ActiveGraph DB. Again, I didn't know it would, but when I, you know, when my coding agent was debugging, it just started querying the DB instead of the session logs because everything is already logged very cleanly and typed, and it knows exactly how it's logged.

Packs can be loaded easily from other repos was a surprise. I thought I had to do extra work to make that happen, but just worked. Um, no more starting long runs over from the beginning, and I know what didn't work, which are some of the things I shared.

### World model

**Yohei Nakajima** [15:43]
Um, here's where I might lose some serious researchers, at least in the language I use. I don't actually know how to train models or anything, so I'll caveat that. But I'm building this. I'm starting to really think that long running agents need not just a world a world model, like a predictive world model, but what I might call an experiential world model,right?

The predictive world model feels more like the priors,right? And then if you think about the hippocampus, actually, it also does work like an immuta like an immutable state, uh, event log that projects a state, and then it feeds some of that state back into your priors through replays, dreaming, and sleep.

And so, you know, I feel like some some discussions kind of suggest that as models get better, like, the harness disappears, but I'm starting to think that's not true. I think we need both, um, is is kind of the new hypothesis that's growing as I as I've been playing with ActiveGraph.

And if you think about, like, you or me, like, you or me, like, we're not our reasoning capability,right? We are we're closer to our our our beliefs, our knowledge, and behaviors that are derived from our actual life experience.

And if that's the case, and we're going to, you know, build agents inspired by ourselves, then then maybe our agents should be treated that way too. Maybe the identity of the agent is is derived from its own log.

Um, I would love for you to try it. You can just go just say, "Look up ActiveGraph and build me something I would like to your favorite agent who knows you better than I do," uh, and have it explain if it's, uh, uh, if it was helpful or not.

Um,

let me know if you try it or hate it or are building something relevant. Thanks for listening.

---

This library is powered by PodHood (https://podhood.com), the podcast website platform.
