Nx Polygraph and the Synthetic Monorepo: Two Problems, One Name

On 26 June 2026, Nx published a post called Announcing Polygraph: A Meta-Harness for Maximum Agent Autonomy. I read it the week it landed and had the slightly uncomfortable experience of watching a much larger company name the thing I have been arguing for since I started building Riftmap.

The phrase is synthetic monorepo, and it lives a few clicks from that announcement, on Nx’s own monorepo.tools, which defines it in one sentence: “A synthetic monorepo connects separate repositories into a unified dependency graph without moving any code.” That is a good sentence, and it is very close to the bet I have been making in public for a year. The repo layout was never the variable that mattered. You should not have to restructure an estate to see how it hangs together.

Engineers have been hand-rolling this for a couple of years. A folder of clones. A script that pulls each default branch every morning. A markdown file at the top telling the agent, or the new starter, what talks to what. It genuinely works up to a few dozen repositories, and then it fails in one specific way. The clones stay current because a machine refreshes them. The map does not, because a human does, so the folder is fresh, the map is a year old, and the map was the part you were relying on. That is Nx’s case for productising this, and it is mine.

So this is not a post arguing that Nx is wrong. Polygraph is a good product and the vocabulary is a gift. It is a post arguing that the phrase quietly names two different problems, and that only one of them is on the table today.

Here is the claim, stated plainly. A synthetic monorepo makes many repositories legible as one workspace, which is not the same job as knowing what an infrastructure change breaks: those edges are declared in Terraform source blocks, Dockerfile FROM lines and Chart.yaml dependency entries, and Nx Polygraph does not parse any of them today.

What Polygraph actually is

Polygraph is an agent-agnostic meta-harness: it indexes the repositories you have access to, builds a cross-repo dependency graph of how they relate through packages and APIs, and runs coding agents against that graph so they can plan work spanning more than one repo. Its product page names Codex, Claude Code, GitHub, and Open Code among its integrations, and it adds session state on top, so an agent can hand off and resume rather than rediscovering the estate every morning.

Two properties are worth stating clearly, because they are the ones people get wrong when they summarise it. It works on repositories that have never heard of Nx, and it requires no changes to those repositories. Nx says both plainly: the enterprise docs promise “Zero-friction adoption for existing repositories without requiring teams to adopt Nx or modify their workflows”, and the launch post says “It connects all your repos, private and public, into one dependency graph without moving any code.” Cross-repo with zero restructuring is the entire premise, not a caveat.

“Polygraph is free” is the line you will read on aggregator sites, and it is true of one of the two things that ship under the name.

Nx has used the name twice, a year apart. In June 2025 it put an Nx Cloud Enterprise feature set under the Polygraph brand, the workspace graph and the conformance dashboard among them. Workspace Graph, Conformance and Custom Workflows are still bundled in the custom-priced Enterprise tier on nx.dev/pricing today, and the enterprise docs put it flatly: “Polygraph features require an Nx Enterprise license.” The licence is the gate, not a second bill for teams already through it. The same page adds: “Existing Nx Cloud Enterprise workspaces include Polygraph at no extra cost.” Beneath that, it meters. Additional fees apply only to metadata-only workspaces, the mechanism by which non-Nx repositories join the Workspace Graph, and to consumed compute credits. An independent technical walkthrough of the Conformance rules, published in August 2025, describes that feature set and no agent orchestration at all, because the agent orchestration did not exist yet.

The June 2026 relaunch is the agent meta-harness, and that part is currently free. The product page says: “Full product, zero cost. 30 day notice before any pricing changes.” The phrase “synthetic monorepo” appears to belong to the 2026 relaunch, so the vocabulary is new even though the brand is not.

The overlap, said out loud

Polygraph’s graph and Riftmap’s graph overlap, and I would rather say so than have you notice it yourself halfway down.

Polygraph builds a real cross-repo dependency graph, parsed from source and manifests, not guessed. Nothing Nx has published about that graph names an ecosystem outside npm, though base Nx has polyglot plugins and I would not bet on that staying the boundary. Riftmap parses package.json and go.mod too. That is the same ground, and on npm specifically Riftmap is the narrower tool: it parses dependencies, devDependencies, peerDependencies and optionalDependencies from package.json manifests only, with no lockfile parsing anywhere in the codebase, so transitive dependencies are not in the graph at all. Resolution is producer-side and walled to a single connected organisation by construction. An @scope/package reference only becomes an edge if a repo inside that same organisation is detected as publishing it.

So I am not going to pick a fight with Polygraph over package graphs. That is their ground and they are on it properly, and it is why the disagreement worth writing down is a narrow one.

Two problems wearing one name

Both graphs are read deterministically out of manifests, and neither is guessing from embeddings. What a package-and-API graph does not contain is a resolver from a registry coordinate to the repository that produces it.

That is the load-bearing sentence in this post. A package graph is built to answer what a package exports and who imports it. To answer which repositories break when you cut a new version of a shared Terraform module, something has to have separately worked out that the coordinate cloudposse/label/null is produced by the repository cloudposse/terraform-null-label, and then matched every consumer in the estate against it. Knowing what a repository publishes, not only what it declares. That is a different piece of machinery from an import graph, and it is not what an import graph is for, which is why nobody shipping a synthetic monorepo has built it.

The obvious rebuttal is that Nx already sells to exactly the person I am describing, and it is a good one. Workspace Graph and Conformance were not built for a coding session. Nx’s enterprise docs describe the Workspace Graph as visualising “dependencies between all repositories in your organization”. That is platform-team framing, sold to platform teams, a year before the agent harness existed, and Conformance goes further than visualising by enforcing policy across those repos. If my argument were “their graph is for agents and ours is for estate owners”, one sentence would knock it over.

So that is not the argument. The argument is that both halves of Polygraph run on the same edge set. The independent walkthrough of Conformance works entirely in npm package dependencies, and nothing Nx publishes about either half names a manifest outside that world. The estate question needs a different edge set, not a different audience.

The words on that page have got further than the edge set has. Nx’s enterprise docs promise “Impact analysis before breaking changes: See the blast radius of changes across your entire tech stack”. That is this blog’s phrase, in this blog’s sense, about the feature under discussion. Read on 28 July 2026, nothing that page documents names Terraform, a Dockerfile, a Chart.yaml, a Kubernetes manifest, or a CI config. Entire tech stack is a wide claim to hold up against a graph of packages and APIs.

Purpose is the explanation for why that gap persists even though nothing stops Nx closing it. Polygraph’s graph exists so an agent has enough context to plan a code change, and the measure of success is whether the agent opened the right four repositories and did not break the caller it never read. The graph serves the work. Somebody owns the estate, carries the pager, and has to decide on a Thursday whether cutting 0.26.0 of a shared module is a ten-minute job or a week. A graph built for the first job has no reason to grow a producer-side resolver, so it has not grown one.

That is also the honest difference between a symbol graph and an artifact graph, and it is why the three ways a tool can come to know an edge exists do not separate these two. Both graphs are in the good regime. The edges are declared, written into a manifest something already executes, and read straight back out. The disagreement is about which manifests you bother to read, and what you do with the reference once you have read it.

A real monorepo never solved this either

For one specific class of dependency, the registry-resolved kind, moving every repository into a single tree would not have helped you either.

I want to state the narrow version, because the flat version is wrong and anyone running a real monorepo knows it instantly. If your Terraform, your Helm charts, and your Dockerfiles live in-tree next to the application code, a monorepo sees those edges perfectly well. A relative source path is an ordinary file reference. git grep finds it. A build graph can be taught to follow it. Nothing about infrastructure-as-code is inherently invisible to a monorepo.

The edges that escape resolve through a registry: by name, outside any tree, through a convention the filesystem knows nothing about. And the repositories consuming the image or the module you publish are frequently not coming into your tree at all, which is the case a migration cannot reach even in principle. Connecting N repositories into one synthetic monorepo does not change that either. The coordinate still resolves by name, and the machinery that maps it back to a producing repository has to exist separately. Nx has built the connecting. Not, so far, the resolving.

Where the artifact edges actually live

The edges that decide what an infrastructure change breaks are declared in four fairly boring places: Terraform source blocks, Dockerfile FROM lines, Chart.yaml chart dependencies, and CI include directives. They are already in your repositories, in plain text, and something in your pipeline already executes them.

Here is what that looks like at a size that matters. On 27 July 2026 I ran a Riftmap scan across the public cloudposse GitHub organisation. 244 repositories scanned. 149 of them declare a Terraform source dependency on a single module, cloudposse/terraform-null-label, written as the registry shorthand source = "cloudposse/label/null" inside a module block. Those references are spread across seven distinct source filenames, mostly context.tf. 141 of the 149 pin 0.25.0. The other eight sit on tags/* refs, lagging, with nothing anywhere recording that they lag.

If that number looks slightly familiar, it should. I published a full write-up of this organisation on 5 July and it says 147 of 242. Three weeks later the same scan says 149 of 244. The organisation is two repositories bigger. Separately, and not necessarily in the same repositories, the module is two consumers wider. Nobody edited a catalog entry anywhere to record either move.

That is usually where I make the parsed-versus-catalogued argument, and on this axis Nx is standing next to me. Its docs for the term describe the graph in a line I could have written: “Always up to date, discovered from actual code — not a manually maintained spreadsheet or catalog.” I agree with all of it. So the argument in this post is not about maintained catalogs. Both graphs move when the estate moves. Only one of them was reading a .tf file when it did.

Now the objection, before you raise it. That number is as large as it is because Cloud Posse made it that way. They ship context.tf as copy-this-file boilerplate, with instructions in the source telling you to copy it into your own module, so the whole organisation converged on one label module by design. The second most consumed Terraform module in the same organisation has 15 consumers. Cloud Posse is an infrastructure estate and it looks like one. So this is one real, scanned organisation, not the average Terraform estate, and the honest reading of 149 is not “your org looks like this”. It is that when an organisation does have a module like this, the edge is sitting in plain text in 149 repositories and nobody has the list.

Which raises grep. gh search code --owner cloudposse "cloudposse/label/null" will surface most of those 149, because for this particular construct the string genuinely is the receipt. I conceded that in print three weeks ago and I am not going to un-concede it now. What grep cannot do is tell you which string to search for. The whole problem is the module you have forgotten is load-bearing. You cannot grep for the dependency that lived only in one engineer’s head, because you do not know its name to type it.

The more useful half of that scan is the part that compares layers. The same run over the same 244 repositories ranked every artifact type in the organisation by fan-in. The best-consumed Go module in cloudposse has one consumer. The best-consumed Docker image has two. The best-consumed Helm chart has none at all. One Terraform module has 149. Same org, same scan, both layers. Every count in that sweep is intra-organisation by construction. Resolution is walled to the connected org before any resolver runs, so a FROM golang:1.22 off Docker Hub is not an edge here. The 149 is walled identically. Same rule on every layer, which is what makes it like-for-like rather than a generous count set against a stingy one. The rule bites unevenly, and that is the point rather than a flaw in it. Cloud Posse publishes most of its own Terraform modules, so the wall catches nearly all of them. Base images come mostly from public registries, so it catches almost none. That asymmetry is the correct scope for the question rather than a limit on it. You cannot break a base image you do not publish. For an infrastructure estate, the layer a package-and-API graph reads can be very nearly empty while a single artifact type carries hundreds of edges, and no amount of graph quality on the first layer surfaces the second.

It is not only Terraform and it is not only cloudposse. In the same run, 22 of 289 scanned repositories in a second public GitHub organisation declare a Helm chart dependency on one chart published inside that same organisation, each one a dependencies: entry in a Chart.yaml pinned to a version, several of them behind the chart version currently published. Same shape of edge, different manifest, different org. Rank that organisation’s layers the same way and the order changes without the shape changing. Best Go module: one consumer. Best Docker image: one. Against 22 for that chart and 13 for the org’s most consumed Terraform module. Two orgs is two orgs, not a survey. But the near-empty Go layer in cloudposse is not simply what a Terraform shop looks like.

Nothing in Nx’s architecture prevents Polygraph from reading them. Nx’s plugin model already treats “parse a manifest, add an edge” as its core technique, and the community-maintained nx-go plugin extends the graph to Go modules today. There is no architectural wall between Nx and a Chart.yaml, and if I claimed there was, any Nx user would put this post down at that sentence and be right to.

Does Nx Polygraph support Terraform, Helm, or Dockerfiles today? What I can say precisely is what I looked for and did not find. On 27 and 28 July 2026 I went hunting for Terraform, Dockerfile, Helm, Kubernetes, or CI-config coverage, current or roadmapped, across eight sources: the launch post, trypolygraph.com, the enterprise docs, Nx’s own concepts page for the term, the pricing page, The New Stack’s coverage of the launch, the independent Conformance walkthrough, and the synthetic monorepos page on Nx’s monorepo.tools. Not one of them documents any of it, as a shipped feature or as a stated roadmap item. The enterprise docs come closest to an authoritative account, and they describe what the Workspace Graph shows rather than which manifests it reads. Everything Nx has published about the agent harness describes its graph as packages and APIs.

Negative findings age. If Nx ships a Terraform plugin next quarter, the sentence that needs changing is that one, not the argument underneath it, because the argument was never about capability. This is the class of edge Polygraph does not map today. Not because it could not. Because a graph built to answer “what does this package export, and who imports it” has no reason to resolve a Terraform registry coordinate to a repository, and Nx has not yet given it one.

So which one do you need?

These three things stack rather than compete.

An agent planning work across repositories: Polygraph

If your problem is that Claude Code or Codex can only see the repository it is sitting in, and you want it to plan a change that spans four, Polygraph is the most interesting thing I have seen ship in that lane this year. It works on repos that have never used Nx, it costs nothing to try during Early Access, and the graph is parsed rather than hand-written. One thing to know going in: indexing runs in Polygraph’s cloud, so a resumed session reflects the last indexed state rather than your uncommitted working tree, which is worth knowing rather than a knock.

One build graph and atomic commits: a real monorepo

If what you want is a single build graph, one commit that changes an API and every caller together, and CI that understands the whole tree, a synthetic monorepo is not a substitute for the real thing. Move the code. That is what a monorepo is for, and I have written before about why the monorepo-versus-polyrepo debate is measuring the wrong thing.

What an infra change breaks across a mixed estate: an artifact graph

If the question that keeps you up before a base-image bump is which repositories break, none of the above answers it. What you want is cross-repo dependency mapping at the artifact layer: a graph that parses those manifests and resolves each declared reference to the repository that produces the artifact.

That is the layer Riftmap parses. Fifteen parsers across an organisation, Terraform source blocks and Dockerfile FROM lines and Chart.yaml chart dependencies among them, each declared reference resolved back to the repository that produces it. One token, installed once at the organisation level, no per-repo YAML, and nothing in the scanned repos changes, because Riftmap only ever reads what is already on the default branch. There is a live graph of a real public organisation, no sign-in required, at riftmap.dev/showcase.

A synthetic monorepo is a workspace, not an estate

Nx is right about the part that matters most, and it is the part I would defend against anyone: the repo layout was never the variable, and you should not have to restructure an organisation to see how it hangs together. The migration was always the wrong price to pay for the visibility.

Where I would push is on the word legible. Legible to an agent about to write code means: which packages exist, what they export, who imports them. Legible to the person who owns the estate means something narrower and heavier. It means that when you bump the base image on a Friday afternoon, the blast radius is a list, and not a memory belonging to somebody who left in March.

Same technique. Different product. Nx built the first one and named it well enough that the second one now has a name too. That second graph is still sitting unread in your .tf files.

A few questions, answered directly

What is a synthetic monorepo? A synthetic monorepo is a cross-repo dependency graph assembled without moving any code: a tool indexes the repositories you can access and builds one graph across them, so an agent or a human can plan work spanning several repos with no migration and no hand-maintained system map. Nx’s own definition on monorepo.tools says the same: “A synthetic monorepo connects separate repositories into a unified dependency graph without moving any code.” Nx Polygraph is the productised version, announced in a post Nx published on 26 June 2026. The term describes the graph’s reach across repositories, not its depth across ecosystems: the ones shipping under the name today cover packages and APIs, not Terraform, Docker, or Helm edges.

What is Nx Polygraph? Nx Polygraph is an agent-agnostic meta-harness that indexes the repositories you can access, builds a cross-repo dependency graph of packages and APIs, and runs coding agents such as Claude Code and Codex against it, with session state so an agent can hand off and resume. It works on repositories that do not use Nx and requires no changes to them. Two things share the name: the agent meta-harness Nx announced in a post published on 26 June 2026, free during Early Access, and an Nx Cloud Enterprise feature set first shown under the brand in June 2025, whose Workspace Graph, Conformance and Custom Workflows still require an Nx Enterprise licence.

Do I need a monorepo to give my AI agent cross-repo context? No. You can do it by hand, cloning the repos into one workspace folder and writing a system map, or you can point a tool like Nx Polygraph at your organisation and let it build the graph. The tooled version wins for a boring reason: a hand-written map is maintained by a human and drifts, and a parsed graph does not. What neither gives you by default is the infrastructure layer, so if the real question is which repositories a base-image or Terraform-module change breaks, you need a graph that parses those manifests specifically.

Does a synthetic monorepo show infrastructure blast radius? Not today. As of July 2026, Nx Polygraph does not support Terraform, Dockerfile, or Helm edges, and the synthetic monorepos shipping under the name build their graph from packages and APIs instead. Nothing in Nx’s plugin architecture prevents it going further, so this is a gap in what has been built rather than a wall. As it stands, a synthetic monorepo will not tell you that 149 of 244 scanned repositories in one organisation consume the same Terraform module, while the best-consumed Go module in that same organisation has one consumer and the best-consumed Helm chart has none, and answering that needs a tool that parses Terraform source blocks, Dockerfile FROM lines, and Chart.yaml chart dependencies and resolves each one to the repository that produces the artifact.

About Riftmap

Riftmap maps cross-repo dependencies across your entire GitLab or GitHub organisation — Terraform, Docker, CI templates, Helm, and more. One read-only token. No YAML to maintain.