Imagine you find a magic lamp in an antique store. You rub it, a genie appears, and asks how it can help. You burn it in the outline, 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 eight 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 1/1000 of it. And he remembers nothing he did before. Every conversation starts fresh. So, 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 the 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. Note that that's often a different person, right? Every box in this diagram can be done by a different person. And then we discover that the published UI library doesn't work with module one. 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 and again we explain the new change in the context of module one, same module. I mean, do the same for module two again. And then we go to the platform repo and we explain 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 seven explanations for what essentially is one change. And also it may not be one person making all these seven 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 two categories. The first one is that an agent essentially is repo bound. 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. Agent forget the work. Every session start 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. Worse than 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 20 repos means re-explaining things 20 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'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 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. 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's what it actually sees. There is one session, one small fraction of the 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 hand, at least in the domain they know. Agent generically 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 constraint again both in space, what 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'll show you how we solved it. Other organizations I talked 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 kind of on a 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 want to 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 API they produce and consume, and lots of other stuff, right? And this 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 GUI 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 pull information in. Pulling information in is only one part of the story, all 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, all right? You need to run CI. You need to coordinate all of it, right? You need to do all this stuff, all right? What if one of them fails, right? Polygraph treats all the CI as one vector. Like if you look at the 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 needed a patch or the UI component itself is broken 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 we your intent, the repository is 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 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 it's a demo. I pick back end 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 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 UI as well. Eventually, [snorts] 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 uh exactly 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 where those pull requests are. All right? If I look at the session, I will see I have a description uh that uh description of the session describes the work conceptually uh kind of bypassing the repo boundary, saying we have to change stuff in this repo, 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 back end 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 back end change. Perhaps they own the back end repo. I send them the session. They resume it on their machine, all right? So this I'm sending them the session. They could run the command. Uh different machine, different everything. They use different terminal, all right? Uh they would reconstruct it on their machine. They don't have the session, right? They have never worked on it. They they can pick an agent. Uh the agent they pick could be a different agent, right? I used Cloud in the original session, but let's say they're using a different one, Cortex. The same setup happens to their machine, same repos, same SHAs, everything set up correctly. Agent starts in a triple like in mine, all right? They're all connected again, so they work together. They're all primed with a trace captured from my machine, so the back end of the repo agent on their machine has the same shine 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 coded, but they share memory. And they could actually actually make changes in here as shown in a small video. Um but I think what the memory sharing part is key, all right? Uh I can work, they can work, and we can share our memories as though we used to different agents in different machine. The full state of my session can I get materialized on their machine. It kind of less memory and more about the state, right? The state of the world that's attached to the session, uh you know, is what enables them to continue my session even though they had didn't do anything with it originally. It's close to the transporter in Star Trek. Like a whole copy of my session is all of its state materialized 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 the exact state, fully functional, zero setup, and then I just talk to my agent about the decisions we made, right? [snorts] Because all these decisions are in the traces captured. So, my agent knows exactly what the other person talked to their agent. Right? So, a 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 landed in production. Here, I'm going to reference the 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 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. He actually 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, all 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? [snorts] I mean, 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 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 vector index 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. [snorts] And I can load one of them or both of them, right? Um it's useful for many reasons. Uh let's 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 the session by an engineer I respect. Now, our code cross 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 the 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's a lot of interesting intelligence that make it a lot more useful that appear at first glance, okay? Lastly, uh everything so far I I used uh everything I shown uh used the Polygraph CLI, the current meta harness CLI, to start it, and then you can start Cloat or Cortex or whatever from within it. But, you don't have to use it this way. So, in this case, I'm already in a Cloat 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 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, we'll engage Polygraph, and it'll set it up, you know, configure everything, and we'll bring the Vitest library, which is a 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 are discovered all this way. All right. 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? Uh and both limits could be lifted. Polygraph uh gives agents access to the entire code your organization can reach, the one you own and open source. So, it's no longer constrained in space. Any agent can bring all of it. Right? And it gives you 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 all accessible to to each of them. Almost like sort of the Borg. Every agent can run by every developer contributes to kind of 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 try.poligraph.com and see if it works for you. Thank you.