A Genius With Amnesia

Imagine you find a magic lamp in an antique store. You rub it, a genie appears, and asks how it can help. You buried in the airlines, 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 id 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 code base, 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 four repos: UI, module one, module two, and platform. I want to change the UI and propagate the change through the system.

Okay? First, we change the UI library, say we, I don't know, change a button or whatever. That's the first explanation. Unavoidable. We have to express intent. Okay? Then we publish it.

We go to module one, and we have to re-explain what just has happened in the UI library, so it can consume the package here. Know that that's often a different person, right?

Every box in this diagram can be, uh, done by a different person. And then we discover that the published UI library doesn't work with module one. So we go back, uh, to UI,

and we have to re-explain the original change and the issue, right? Because that's a new agent, it doesn't know the original change and obviously doesn't know about the issue.

Let's say we fix it, right, and, uh, publish it again. We go and again, we explain the new change in the context of module one, same ordeal, um, and do the same for module two again.

And 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, uh, a bug appears in the UI component, and, uh, we have to fix it.

So we start an agent to 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 seven explanations for what essentially is one change.

And also it may not be one person making all these seven explanations, uh, but they still occurred, right? So that's very, very typical, uh, with agents. So how do we solve it?

Well, uh, there are many problems in here that contribute to this experience, but they roughly fall into two categories. The first one is, uh, 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 kinda the space component of the problem.

Second is amnesia. The agents forget 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 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 one. 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.

Modules one 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 twenty repos means re-explaining things twenty times. A lot of developer time spent, but also a lot of tokens 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 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 a thousand 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. Session relates 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. It is one session, one small fraction of your code base, 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 five messages back, sort of constrained 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 talk to have similar solutions, so, uh, 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, uh, 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.

Uh, no line of code changes in those repos. That all happens kinda 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 code base the agent can read and write anywhere.

This is my personal graph. I only have about three hundred 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 API they produce and consume, and lots of other stuff, right?

And it stitches this together, uh, 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, it does is, uh, it lets you start a session to bring the relevant repositories in, right? So what it needs to do, it needs to, uh, 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 TUI, uh, to make non-trivial changes without getting lost. I will show you how it all works in a second, right? So that's kinda pull information in.

Pull information in is only one part of the story, right? Honestly, it's an easy part. Making changes is harder. If you have ten repos in one session, it means you can have ten 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 you look at earlier example, uh, when we run CI for UI module one and module two, if module one fails within a Polygraph session, it will figure out who fixes it, whether module one need the patch or the UI component itself is wrong and incompatible with module one, 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 eidetic or 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 work with only three repos because a demo. I pick backend and a front end. 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, uh, more capable.

And in a second, uh, 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, uh, plan out the change.

There is some cool animations in the TUI as well.

Eventually, it figures out how the two repos relate and what the change is. I can ask it to implement the change. My interaction with this are exactly the same as if it-- I was working in a single repo.

The fact that there are multiple repos involved is not really important, right? Uh, the only, uh, part where it becomes important that I have multiple pull requests, right? Uh, but I also get a Polygraph session what those pull requests are, right?

If I look at the session, I will see I have a description

Uh, that, uh, description of the session, it describes the work conceptually, uh, kinda bypassing the repo boundary, saying we have to change stuff on this repo and change stuff on 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, 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, uh, in the, in the front-end 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, I'm sending them a session. They could run the command. Different machine, different everything. They use different terminal, right? Uh, they would reconstruct it on their machine. They don't have this session, right?

They've never worked on it. They, they can pick an agent. Uh, the agent they pick could be a different agent, right? I used Claude in the 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're all primed with the trace captured from my machine, so the backend, the repo agent on their machine has the same shard and the same history. The front-end repo situation is the same.

It's, it's checked out at the same, at the correct shard, has the agent running with the correct history. So my agent was Claude, they're Codex, but they share memory, and they could actu-actually make changes in here as shown in, uh, the small video.

Um, but input, the memory sharing part is key, right? Uh, I can work, they can work, and we can share our memories as though we use two different agents or different machine.

The full state of my session kinda get materialized on their machine. It kinda less memory more about the state, right? The state of the world as attached to the session, uh, you know, i-is what enables them to continue my session, even though they had d-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 the decisions are in the traces captured. So my agent knows exactly what the other person talked to their agent, right? S-side note, this is also useful when I wanna switch from, say, Claude to Codex mid-session when something goes down, okay?

Okay. Take the earlier case I talked about where a bug landed in production. Here, I'm going to reference this session and say, "It's basically broken. Uh, 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 description, it's 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 the fix, right?

I only had to say, "This happened. There is a bug." That's it. No extra information was required for 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, 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, uh,

what if I, I want to write a blog post, right, or an article? I could describe it, and it'll 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 vector indexing to 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 will see that it will find several sessions that appear to be relevant,

and I can load one of them or both of them, right? Um, it's useful for m-many reasons. Uh, 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, that make it a lot more useful that appear at, at first glance, okay?

Lastly, uh, everything so far I, I used, uh, uh, everything I've shown, uh, I used the Polygraph CLI, the kinda 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 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 Vitest plugin in this Nx repo, and I could say, "Can you add the Vitest, uh, repository to this session so I know what's going on?"

In this case, it will engage Polygraph, and it will set it up, you know, configure everything, and will bring the Vitest library, which is, uh, the Vitest repo, the open source repo, to my session.

So now, uh, my agent can, you know,

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

So the deep problems I discover about this way.

All right. So agents are constrained in space and time. They only see a small fraction of the code base, and they don't know the past, okay? Uh, and both limits could be lifted.

Polygraph, uh, 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, to each of them.

Almost like sort of the Borg. Every agent can run, but every de-developer contributes to kinda one big, this hive mind, right? So, uh, 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.