How to Give Coding Agents Cross-Repo Memory

TL;DR

Coding agents become more effective when they can operate across related repositories and retain the history of prior work. Polygraph addresses these spatial and temporal limitations by building a unified dependency graph, coordinating agents and CI across repositories, capturing pull requests and traces, and allowing complex sessions to be restored or referenced later.

Transcript

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 g... Read More

Key Insights

• Coding agents are constrained by both space and time: they usually see one repository at a time and start each session without memory of previous work, leaving developers responsible for supplying system context and reconstructing history.
• Repeated explanations are a predictable consequence of repository boundaries. The UI example requires seven explanations for one change as work moves through publishing, consumer updates, compatibility repairs, platform integration, and a production bug discovered after release.
• Repository isolation prevents reliable downstream validation. An agent changing a shared UI package cannot automatically test dependent modules, determine whether consumers need patches, or update those consumers while it still has precise knowledge of the original implementation.
• Organizational work forms two connected structures: a graph of owned and open source repositories, and a graph of agent sessions that create or modify code. Together, these graphs describe both what exists and how it came to exist.
• Polygraph builds a unified dependency graph by analyzing repositories a GitHub user can access. Its metadata covers what projects produce and consume, including packages and APIs, creating the practical illusion of one large codebase for agents.
• A multi-repository session requires more than retrieving source code. Polygraph sets up repositories, installs dependencies, assigns an agent to each repository, connects their work, and presents the coordinated change through a single interface.
• Polygraph treats CI results across repositories as one vector. When a consumer fails, the system can determine whether that repository needs a patch or whether the upstream component introduced an incompatibility requiring broader corrections.
• Episodic memory comes from capturing intent, involved repositories, pull requests, and agent traces. Relating these records allows prior sessions to be restored on another machine or referenced from later work without repeating the complete explanation.

Questions & Answers

Q: Why do coding agents require repeated explanations?

Coding agents require repeated explanations because they are generally bound to one repository and begin new sessions without episodic memory. They cannot automatically see how a current repository relates to other components or recall the intent and decisions behind earlier work. The developer therefore becomes the source of both system knowledge and historical context during every separate interaction.

Q: What are the spatial and temporal limits of coding agents?

The spatial limit is that an agent generally sees and changes only one repository at a time, even when the complete system spans hundreds or thousands of repositories. The temporal limit is amnesia between sessions. Each session starts with a blank slate, so previous intent, implementation details, issues, and decisions must be supplied again by a human developer.

Q: How do repository boundaries affect multi-repository changes?

Repository boundaries prevent an agent from seeing the complete dependency structure, aligning changes with downstream consumers, and referencing standards stored elsewhere. An agent may publish a shared component without validating dependent modules or updating them simultaneously. Developers must then visit each consumer separately, explain the same change again, run its checks, and repair incompatibilities after they appear.

Q: What information does a unified repository graph contain?

The unified graph represents repositories the user owns or can access, along with open source repositories those projects depend on. Polygraph computes metadata about what each repository and project produces, what packages it consumes, and what APIs it produces or consumes. These relationships stitch separate codebases into a connected model that agents can use during coordinated work.

Q: How does Polygraph coordinate work across repositories?

Polygraph creates a session containing the relevant repositories, prepares their source code, installs dependencies, configures an agent for each repository, and wires those agents together. A developer can describe the intended change once and interact with the session much like a single repository, while the system tracks the separate repositories, pull requests, and checks involved in implementation.

Q: How does Polygraph handle CI failures across repositories?

Polygraph treats the CI results from all repositories in a session as one vector instead of isolated outcomes. If a consumer fails after an upstream change, it can determine whether the consumer needs its own patch or whether the upstream component is incompatible and requires correction. This supports coordinated validation and repair across every repository affected by the change.

Q: How does Polygraph provide memory for coding agents?

Polygraph captures the developer's intent, the repositories included in the work, the resulting pull requests, and the complete agent traces. It then relates work performed in one repository to connected work elsewhere. Because this information is preserved, a session or specific piece of work can be restored on another machine or referenced during a later task.

Q: Is Polygraph a coding agent or a meta-harness?

Polygraph is an agent-agnostic meta-harness, not a coding agent. The developer selects an installed agent, such as the agent used in the demonstration, and Polygraph surrounds it with cross-repository context, coordination, CI management, session records, and a graphical interface. Its role is to make existing agents more capable across repository and session boundaries.

Summary & Key Takeaways

• Current coding agents combine strong reasoning with severe contextual limitations. They generally operate inside one repository and begin each session without episodic memory. Developers therefore must repeatedly explain system relationships, prior changes, production issues, organizational conventions, and downstream effects that the agent cannot independently see or remember across separate interactions.

• A single UI change can require repeated explanations while moving through a UI library, consumer modules, a platform repository, and a later production fix. Repository boundaries prevent agents from validating downstream compatibility or updating consumers while the original context is fresh, increasing developer effort, token usage, and the risk of inconsistent implementations.

• Polygraph is an agent-agnostic meta-harness that analyzes accessible repositories and constructs a unified dependency graph without modifying their source code. It coordinates repositories, agents, pull requests, and CI within one session while capturing intent and agent traces, enabling developers to resume earlier work and treat multi-repository changes like single-repository changes.