A Genius With Amnesia - Victor Savkin, Nx

Imagine you find a magic lamp in an antique store. You grab it, a genie appears, and asks how it can help. You bury it in the end line, so you say, "I need the best engineer to help with an impossible project at work."

And the genie grants your wish. For me, the best engineer is probably John Carmack from his it days, so you get Carmack. But the genie had a sense of humor and imposes restrictions, maybe for safety. Carmack can only see one small part of your codebase, maybe one thousandth of it, and he remembers nothing he did before.

Every conversation starts fresh. That would be maddening,right? You would know there is a standard way to do stuff, and Carmack wouldn't. You would have to explain the same thing over and over and over again. You would have a genius on one side and something deeply deficient on the other.

And that's what agents are. Let me walk you through an example of how many times we re-explain things in a simple interaction. We have 4 repos: UI, module 1, module 2, and platform. I want to change the UI and propagate the change through the system, okay?

First we change the UI library. Say we change the button or whatever. That's the first explanation. Unavoidable. We have to express the intent, okay? Then we publish it. We go to module 1, and we have to re-explain what just has happened in the UI library so it can consume the package here.

Note that that's often a different person,right? Every box in this diagram can be done by a different person. Then we discover that the published UI library doesn't work with module 1. So we go back to UI, and we have to re-explain the original change and the issue,right?

Because it's a new agent, it doesn't know the original change, it obviously doesn't know about the issue. Let's say we fix it,right, and publish it again. We go in again, we explain the new change in the context of module 1, same ordeal, and we do the same for module 2 again.

Then we go to the platform repo and we explain how everything fits together, and we implement the change there. Let's imagine a week after release, a bug appears in the UI component, and we have to fix it. So we start an agent in the UI repo, and we have to explain, again, the original change from a week ago and this production issue we're seeing.

So we have 7 explanations for what essentially is one change. And also, it may not be one person making all these 7 explanations, but they still occurred,right? So that's very, very typical with agents. So how do we solve it?

Well, there are many problems in here that contribute to this experience, but they roughly fall into 2 categories. The first one is that an agent essentially is repo-bound. The agent sees and changes generally one repo at a time.

It never sees the whole system, which can be hundreds or thousands of repos. So that's kind of the space component of the problem. Second is amnesia. The agent forgets the work. Every session starts with a blank slate. The human becomes the memory in this case.

That's the time component of the problem. Look at the two closer. Take the repo boundary first. Without a model of how repos fit together, the agent leans on the human to do the research. It can't align the code with the rest of the system.

It couldn't align the UI change with module 1. The human didn't explain it, so a bad version shipped. It can't reliably reference best practices and standards either, because those often live in other repos. Writing is even worse. The agent writes to one repo at a time.

It means it can't validate changes downstream. Module 1 CI should have failed on the UI change, but it didn't. The agent can't update consumers at the same time, even though, you know, while making the UI change, it has perfect information to do so.

It knows exactly what it's doing. So the user has to re-explain stuff imperfectly to each consumer. Changing something across 20 repos means re-explaining things 20 times. A lot of developer time spent, but also a lot of token burned.

The second category is that the agent forgets. The agent has no episodic memory. Every session is a blank slate, and the human in this case becomes the memory.

Here's what the graph of your work actually looks like. At the bottom, there is a repository graph, the artifacts your organization produces, plus every open source repo you depend on. Maybe 1,000 repos you own, and tens of thousands of open source repos.

At the top, there are all agentic sessions that create and modify that code. Sessions relate to each other. Repos relate to each other. So this graph is a faithful picture of the work in your organization. It describes what's there, at the bottom, and how it came to be at the top.

That's what you want your agent to see. Here, what it actually sees is one session, one small fraction of your codebase, no memory, okay? Because it sees so little, it leans on the one who understands the system, the developer.

Every developer has a part of that graph,right, in their head, at least in the domain they know. The agent, generally speaking, doesn't. If this doesn't sound crazy,right, imagine an agent that could see one file at a time maximum and can only look 5 messages back.

Sort of constraint again, both in space, what it can see, and time, how far in the past it could see. You would say that's impossible to work in. What we have now is similar to that crazy picture. And the more complex the organization is, the more apparent it becomes.

I will show you how we solved it. Other organizations I talked to have similar solutions, so look at the problem and the solution conceptually, not the specific tool, although the tool is pretty cool.

We built an agent-agnostic meta-harness called Polygraph. Okay, let me show you what it does and how it fixes the issues we just discussed. The first idea that we arrived at is that if a GitHub user, any user, has access to thousands of repos, some of them they own, many of them are open source, we can analyze them and extract a lot of metadata out of them to build unified dependency graph.

No line of code changes in those repos. That all happens kind of on the side,right? And then we can get this metadata and feed it to the meta-harness and create an illusion of one big codebase the agent can read and write anywhere.

This is my personal graph. I only have about 300 repos I own,right, and thousands of open source repos my projects depend on. Polygraph computes what each one produces, each repo, each project in each repo, what each project in each repo consumes, package-wise, what APIs they produce and consume, and lots of other stuff,right?

And it stitches this together

into this, like, one big body of code that your agent can work with. So let's see what it does,right? The first thing it does is it lets you start a session to print the relevant repositories in,right? So what it needs to do, it needs to set up the source code, install dependencies, set up an agent for each repo, wire them up so they can work together, and provide a clean, beautiful UI to make non-trivial changes without getting lost.

I will show you how it all works in a second,right? So that's kind of pulling information in. Pulling information in is only one part of the story,right? Honestly, it's an easy part. Making changes is harder. If you have 10 repos in one session, it means you can have 10 pull requests,right?

You need to run CI. You need to coordinate all of it,right?

You need to do all this stuff,right? What if one of them fails,right? Polygraph treats all the CI as one vector. Like, if we look at the early example, when we run CI for UI module 1 and module 2, if module 1 fails within a Polygraph session, it will figure out who fixes it.

Whether module 1 needs a patch or the UI component itself is wrong and incompatible with module 1, at which point everyone will need a patch,right? Polygraph lets you treat complex multi-repo change as if it was a single-repo change.

The same machinery, by the way, fixes episodic memory. Because we capture your work, no matter how many repos are involved, we know your intent, the repositories involved, PRs. We also capture all agent traces. Because we capture all of this stuff, we can relate it.

So now we can say, "Your work in one repo connects to another work in another repo,"right? And all of that lets us restore any session, any piece of work on any machine, or reference it from anywhere. And I will show you again how it works in a second.

What you get is an agent with identical photographic memory of your entire organization. It understands how repos are written, how they relate, how they're put together, and remembers every session from every repo by basically every developer,right? And that creates a completely different development experience.

Let me show you. First, let's look at how we create a session. Something simple. You run a command, and you pick some repositories from a list. Here's a tiny GitHub org with only 3 repos because it's a demo.

I pick a backend and a frontend. Let's say I need to make a change that, you know, changes the API and has to update both the API and how stuff is being displayed. I need to give my session a name.

I need to pick an agent from the ones I have installed. I picked Claude, but any installed agent works the same way. Remember, Polygraph isn't an agent. It's a meta-harness around an agent that makes them more capable.

And

in a second, the agent boots. And here I could interact with it as if I was in a single repo, even though multiple repos are involved,right? I could give it instructions. It's going to plan out a change.

There are some cool animations in the UI as well.

Eventually, it figures out how the two repos relate and what the change is. I can ask it to implement a change. My interaction with this is exactly the same as if I was working on a single repo. The fact that there are multiple repos involved is not really important,right?

The only part where it becomes important is that I have multiple pull requests,right? But I also get a Polygraph session of what those pull requests are,right? If I look at the session, I will see I have a description, that description of the session.

It describes the work conceptually, kind of bypassing the repo boundary, saying we have to change stuff in this repo and change stuff in that repo. It gives me a good view of which repos are involved, pull requests involved, CI in those repos, everything I need to know.

A lot of this stuff is basically what I would have in a single repo, but many,right? And I also have all the agent logs captured as well, which is important for resuming, which I'm going to show you in a second.

Now it gets interesting. I already saved one re-explanation. I didn't re-explain the backend change in the frontend repo,right? I explained the change once, and I got it implemented in both repos, and it's all in agreement. Now let's resume a session.

Say I want a coworker to finish the backend change. Perhaps they own the backend repo. I send them the session. They resume it on their machine,right? So this is how I'm sending them the session. They could run the command.

Different machine, different everything. They use a different terminal,right? They would reconstruct it on their machine. They don't have this session,right? They've never worked on it. They can pick an agent. The agent they pick could be a different agent,right?

I use Claude in an original session. Let's say they're using a different one, Codex. The same setup happens on their machine. Same repos, same shards, everything set up correctly. Agent starts in each repo, like in mine,right? They all connect it again so they work together.

They all primed with a trace captured from my machine. So the backend repo agent on their machine has the same shard and the same history. The frontend repo situation is the same. It's checked out at the same, at the correct shard, has the agent running with the correct history.

So my agent was Claude. Their Codex, but they share memory. And they could actually make changes in here, as shown in a small video. But the important thing, the memory sharing part is key,right? I can work, they can work, and we can share our memories although we use two different agents on different machines.

The full state of my session kind of gets materialized on their machine. It kind of lets memory know about the state,right? The state of the world that's attached to the session, you know, is what enables them to continue my session even though they didn't do anything with it originally.

It's close to the transport in Star Trek. Like, a whole copy of my session with all of its state materializes on their machine so they can continue. And that's how I often work. When there is a pull request for me to review and I have questions, I usually don't ask the person.

I resume their session on my machine. I get their exact state, fully functional, zero setup, and then I just talk to my agent about the decisions we made,right? Because all those decisions are in the traces captured. So my agent knows exactly what the other person talked to their agent,right?

Side note, this is also useful when I want to switch from, say, Claude to Codex mid-session when something goes down, okay? Okay, take the earlier case I talked about where a bug lands in production. Here, I'm going to reference this session and say it's basically broken, and, you know, can you figure out what's wrong and fix it.

The agent will look it up, will download what it needs. If the description is, like, high-level information is enough, that's great. If not, it's going to pull relevant repos, relevant shards, agent logs,right? It's going to get all this information from the original session to reconstruct that state such that it can do the necessary fixes, as shown here.

Here actually it provided a fix,right? I only had to say, "This happened. There is a bug." That's it. No extra information was required from me to provide.

Okay, so far we have manually selected repos and sessions, but we don't have to,right? Instead of selecting repos by hand, I can also tell the agent what I want. Remember, that graph has all this intelligence,right, about how repos relate.

I could tell my agent, "Find every repo that depends on a particular version of a library and update it,"right?

And it knows,right? I didn't have to select them. It knows a lot of metadata about what's going on. I can also ask loose questions, things like, you know,

"What if I want to write a blog post,right, or an article?" I could describe it and it will figure out which repo is the most relevant based on relationships between repos and what's in them. Another example. Let's say I want to add VectorIndex into the PR collection.

And I want to know if anyone at any point did something relevant in any repo that I can draw from. So in this case, if I do it, I'll see that it will find several sessions that appear to be relevant.

And I can load one of them or both of them,right? It's useful for many reasons. Just one small example. It helps with best practices and consistency. Instead of doing stuff from scratch where, you know, every single implementation is bespoke, I can make it replicate the approach used in a session by an engineer I respect.

Now our code across repos is consistent. That's a big deal. There is a lot more to it, of course. If you are in a repo, I can ask, you know, for sessions. It will prioritize sessions that's relevant to that repo and vice versa.

If I'm asking for repos, it will look at my session and see what similar sessions tend to bring in,right? There is a lot of interesting intelligence that makes it a lot more useful than it appears at first glance, okay?

Lastly, everything so far I used, everything I've shown, used the Polygraph CLI, the kind of meta-harness CLI, to start it, and then you can start Claude or Codex or whatever from within it. But you don't have to use it this way.

So in this case, I'm already in a Claude session, but it works with anything. And I could just say, "Hey, you know, I actually think a separate repo would be useful." Like, maybe I'm working on a VTest plugin in this Nx repo, and I could say, "Can you add the VTest repository to this session so I know what's going on?"

In this case, it will engage Polygraph and will set it up, you know, configure everything, and will bring the VTest library, which is the VTest repo, the open-source repo, to my session. So now my agent can, you know, explore it.

It could, you know, figure out how it works and maybe resolve an issue I have in my repo. I much prefer this to, say, Context 7 because if I have the real code, the agent can go really deep.

So the deep problems I discover about this way.

Allright, so agents are constrained in space and time. They only see a small fraction of the code base as they don't know the past, okay? And both limits could be lifted. Polygraph gives agents access to the entire code your organization can reach, the one you own in open source.

So it's no longer constrained in space. Any agent can bring all of it,right? And it gives your agent a perfect memory of what happened. Every session, every decision made is within reach. Because it crosses developer boundaries, not per developer, the agent can have more context than any single developer.

Like, a thousand engineers have an organization, create all these sessions, they're all accessible to each of them. Almost like sort of the Borg. Every agent can run, but every developer contributes to kind of one big hive mind,right? So if it's interesting, my name is Victor.

You can follow me on Twitter. If you want to check it out, go to trypolygraph.com and see if it works for you. Thank you.