The agent that wrote the code is a bad reviewer of it. Better to launch a dedicated agent with minimal context and a different harness. In a single repo: easy. If multiple repos are involved: still easy 👇

Starting a session off of a problem someone in the org already hit. search_sessions turns up 13 past sessions and the closest one gets pulled in as context. Its PR was closed unmerged, so what the agent inherits is why that approach was rejected.

Git gives you the WHAT. Your session can now give you the WHY.

- you make a change to a design system component in its repo - you ask Polygraph to open a PR on the target repo with the change - Polygraph packages the changes into a tarball & pushes a PR with it - the target repo runs all CI tests against it 👇

What if you don't use "polygraph session start" but you just use your agent and push a PR. Background session capture can now also record those runs and attach the session once a PR is created, effectively connecting the two.

Imagine you upgrade some external OSS dependency and you could just pull in the repo automatically so the agent has full context of how to upgrade it properly.

Work isn’t always limited to a single repository. Polygraph understands how repos connect to each other and can inject that knowledge into your favorite agent harness. One agent session involving multiple repos: query them, modify them, and open PRs.

Sessions should be portable beyond a single machine, agent harness or user. `polygraph session start` wraps the agent you already run tracing the session so it can be resumed at any point, from any machine by any user in your team.

Connect a GitHub org and Polygraph indexes every repo within it, distilling What would you have your agent do if it could work across a single repo?

the list of things i had planned waiting for Fable 5 to come back online

Hello, world 👋