Coding agents lose context when they cross repository boundaries. You ask Claude or Cursor to update a shared library and propagate the change downstream. The agent sees one repo at a time, forgets what it did in the previous session, and you re-explain the dependency chain every time.
Polygraph positions itself as a meta-harness that solves two problems: cross-repo visibility and session persistence. It indexes every repository you have access to, builds a dependency graph, and stores session state so agents can resume work without starting from scratch.
Architecture: Dependency Graph and Session State
Polygraph operates as a layer between your agent and your repositories. It does not replace the agent. Instead, it provides context the agent cannot maintain on its own.
The core components:
- Repository indexer: Scans every repo you have access to (private and public) and extracts package dependencies, API contracts, and import relationships.
- Dependency graph: Builds a directed graph showing how repos relate. When an agent modifies a shared library, Polygraph knows which downstream repos consume it.
- Session store: Persists conversation history, branch names, PR links, and execution traces. Sessions can be handed off between agents or resumed later.
- Unified PR orchestration: Opens pull requests across multiple repos in a single operation, respecting existing permissions and CI pipelines.
The indexer runs continuously in the background. When you prompt an agent through Polygraph, it queries the graph to determine which repos are in scope, then injects that context into the agent’s prompt.
How Cross-Repo Context Works
Traditional coding agents operate on a single repository. They see the files you explicitly open or the repo you point them at. If you need to update a shared library and its consumers, you run the agent multiple times and manually track the changes.
Polygraph changes the scope. When you prompt “update the authentication library and propagate the breaking change,” the system:
- Identifies the authentication library repo from the dependency graph.
- Finds all downstream repos that import it.
- Generates a plan that spans multiple repositories.
- Opens branches and PRs in each repo as a coordinated unit.
The agent sees a unified view across repositories. The actual repositories remain separate, but the context window includes cross-repo relationships.
This works because the indexer pre-computes the dependency graph. The agent does not need to scan every repo on every query. It queries the graph, retrieves the relevant subset, and operates on that.
Session Persistence and Handoff
Sessions are first-class objects. Each session includes:
- Conversation history (prompts and agent responses).
- Repository branches created during the session.
- Pull requests opened.
- CI logs and test results.
- Execution traces (which tools the agent called, in what order).
When you hand off a session to another agent, Polygraph serializes this state and injects it into the new agent’s context. The second agent does not need to re-discover the work. It sees the branches, PRs, and history as if it had been there from the start.
This eliminates context re-establishment when you switch from Claude to Cursor mid-task, or when you resume work after a week. The session state removes the need to re-explain the task.
Token Budget and Context Limits
Cross-repo context can exceed token limits quickly. If you have 50 downstream repos, you cannot inject all of them into a single prompt.
Polygraph’s documented approach includes automatic repo discovery and a graph-based understanding of package and API relationships. The system builds what it calls a “synthetic monorepo” view, filtering the full graph down to relevant subsets based on the task at hand.
The agent sees a focused view, not the entire graph. The system must manage context window boundaries as session history grows, though the specific pruning or summarization strategy is not detailed in the available documentation.
Authentication and Access Control
Polygraph indexes private repositories. This means it needs OAuth tokens or SSH keys for every repo you want to include.
The system respects existing permissions. The documentation explicitly states “existing permissions respected,” which means if you do not have write access to a downstream repo, Polygraph will not open a PR there.
The authentication flow:
- You connect your GitHub or GitLab account via OAuth.
- Polygraph requests read access to all repos you can see.
- It indexes those repos and builds the graph.
- When the agent tries to modify a repo, Polygraph checks your write permissions before opening a branch.
The session state must not leak credentials. If you hand off a session to another user, they should see the work (branches, PRs, logs) but not your access tokens. This requires careful scoping of what gets serialized.
Deployment Shape
Polygraph runs as a hosted service. You do not self-host the indexer or session store. This makes sense because:
- The indexer needs to run continuously to stay current.
- The dependency graph is expensive to compute and store.
- Session handoff requires a shared state layer.
The agent itself (Claude, Cursor, etc.) runs locally or in its own cloud. Polygraph sits between the agent and your repositories, injecting context and managing state.
Integration occurs through standard agent tool-calling patterns, where the agent invokes Polygraph capabilities as part of its execution loop.
When to Use Polygraph
This tool makes sense when:
- You maintain a shared authentication library consumed by 5+ services, each in its own repository.
- Your team extracts packages from a monorepo into separate repos but needs to coordinate updates across them.
- You propagate API contract changes across microservices with shared SDKs at least monthly.
- Multiple developers or agents hand off tasks mid-stream and need full context without Slack threads or wiki pages.
It does not make sense when you work in a monorepo or your repos are independent and never share code. It also may not fit if you need full control over every step of the agent’s execution, since Polygraph abstracts the cross-repo logic.
If you touch shared libraries infrequently (less than once per sprint), the cost of indexing and session management may exceed the value. The tool pays off when cross-repo changes are a regular part of your workflow.
Technical Verdict
Polygraph solves a real problem: coding agents are stateless and repo-scoped by default. Cross-repo work requires manual orchestration or multiple agent invocations with repeated context.
The architecture is sound. A pre-computed dependency graph plus persistent session state is the right approach. The main risks are token budget overflow and partial commit failures when downstream CI breaks mid-execution. Both are addressable with selective retrieval and rollback mechanisms, though the specific implementations are not documented.
Use this if you maintain a polyrepo architecture with interdependent services and want agents to handle cross-repo tasks autonomously. Avoid it if you work in a monorepo or your repos are independent. The session handoff feature is useful for teams, but less critical for solo developers.
The tool is currently free during early access, with a 30-day notice promised before any pricing changes. Recommended for teams managing 3+ interdependent repos with monthly cross-repo changes. Not suitable for monorepos or independent repo clusters.