# A Genius With Amnesia Victor Savkin, Nx | AI Engineer World's Fair 2026 | 20:00 Source: https://www.youtube.com/watch?v=jVjt-2g8NMY Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/a-genius-with-amnesia Published: 2026-06-26 Tags: agents, coding-agents, context-engineering, memory ## TL;DR - Coding agents lose much of their value because they see one repository at a time and forget previous sessions. - Polygraph builds a dependency graph across repositories and gives an agent a coordinated view of multi-repository work. - Capturing repository state, pull requests, CI, and agent traces lets people resume, share, and search past work across machines. ## Summary Victor Savkin compares current coding agents with a brilliant engineer who can see only a tiny part of the codebase and forgets every conversation. In a multi-repository change, people repeatedly explain the same intent to agents working in different repositories. This causes missed dependencies, downstream failures, and wasted developer time and tokens. Savkin describes two limits: agents are constrained in space because they are repository-bound, and in time because they have no episodic memory. Nx built Polygraph, an agent-agnostic meta harness, to address both. It analyzes accessible repositories and creates a unified dependency graph, then coordinates repository-specific agents, pull requests, CI, and session state. Polygraph also records agent traces and work relationships, so a session can be reconstructed on another machine, handed to a coworker, resumed after a production bug, or searched for a previous implementation. The result is an agent that can use context from across an organization rather than relying on one developer to supply it. ## Key ideas ### Repository boundaries force repeated explanations for one change [00:04](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=4s) Savkin describes a change that starts in a UI repository and moves through module one, module two, and a platform repository. The intent is explained once in the UI repo, then explained again when module one consumes the package. When the published package fails, the original change and the problem must be explained back in the UI repo, then explained again in module one. The same process happens for the other modules and the platform. A production bug a week later requires another explanation of the original change. Savkin counts seven explanations for what is essentially one change. ### Agents have limits in both space and time [02:52](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=172s) Savkin groups the problem into two categories. Agents are generally bound to one repository, so they cannot see how code fits across hundreds or thousands of repositories. They also forget their work because every session starts with a blank slate. He calls the first limit the space component and the second the time component. The developer becomes the system's memory and must carry information between agents. Savkin compares the current experience to an agent that could see one file at a time and look back only five messages. ### A unified repository graph gives agents system-wide context [05:46](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=346s) Polygraph analyzes repositories a GitHub user can access and extracts metadata without changing the source code. It computes what projects produce and consume, including packages and APIs, then connects those relationships into one graph. Savkin says the graph can include repositories owned by an organization as well as open-source dependencies. The meta harness uses this graph to create the working illusion of one large codebase. An agent can bring in relevant repositories and work across them instead of asking a human to describe every dependency. ### Polygraph coordinates changes and CI across repositories [08:56](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=536s) Bringing repositories into a session is only the easier part. A session involving ten repositories can produce ten pull requests, so the system also has to coordinate setup, changes, and CI. Polygraph treats the CI results as one vector. If module one fails after a UI change, it can determine whether module one needs a patch or whether the UI component is incompatible and all consumers need updates. Savkin's intended experience is a multi-repository change handled like a single-repository change, while the individual pull requests and repository checks remain visible. ### Captured traces turn a session into shareable state [09:32](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=572s) Polygraph records the intent, repositories, pull requests, and agent traces involved in a session. Those records connect work across repositories and let a session be restored on another machine. Savkin demonstrates sending a session to a coworker, who reconstructs the same repositories, commit states, setup, and agent history. The coworker can use a different agent and still continue from the original state. Savkin also describes resuming another engineer's session to review a pull request, inspect the decisions in the traces, and talk to the agent without asking the engineer to recreate the context. ### Past sessions can diagnose later bugs with little new input [14:53](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=893s) For a production bug that appears after an earlier change, Savkin references the old session and tells the agent that the change is broken. Polygraph retrieves the needed repositories, revisions, and agent logs from that original work. The agent reconstructs enough state to investigate and provide a fix. Savkin says the only additional information he supplied was that the bug had happened. The system is intended to preserve the decisions and context that would otherwise disappear when the original interaction ends. ### The graph can select repositories and find relevant prior work [16:01](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=961s) Repository selection does not have to be manual. Savkin gives the example of asking the agent to find every repository that depends on a particular library version and update it. The graph supplies the relationships needed to identify the repositories. It can also find sessions related to a proposed task, such as adding a vector index to a pull request collection. An engineer can load a previous session and reuse its approach. Savkin says this can make implementations more consistent across repositories and let an engineer follow an approach used by someone they respect. ### Polygraph can add source repositories from inside an agent session [17:59](https://www.youtube.com/watch?v=jVjt-2g8NMY&t=1079s) Savkin shows Polygraph being used from within an existing agent session rather than only from its own CLI. While working on a Vitest plugin in an Nx repository, he asks to add the Vitest repository to the session. Polygraph configures the repository and makes its source available to the agent. The agent can then inspect the real implementation and use it to investigate an issue. Savkin prefers this to relying on a small external context source because access to the actual code lets the agent explore the problem more deeply. ## Notable quotes - "And that's what agents are." (00:44) - "The human becomes the memory in this case." (03:18) - "Polygraph lets you treat complex multi-repo change as if it was a single repo change." (09:04) - "The full state of my session can get materialized on their machine." (14:16) - "Every session, every decision made is within reach." (19:23) ## Tools & references mentioned - John Carmack - Nx - Polygraph - Claude - Cortex - Codex - Vitest - GitHub - Context7 - Star Trek ## Who should watch - You maintain several repositories and routinely explain the same change to separate coding-agent sessions. - Your team needs agents to update consumers, coordinate CI, or hand unfinished work between developers. - You want to preserve agent decisions and reconstruct a past coding session when a later bug or review requires its context.