Submodules are where agents go to die.

The tax, counted.

To understand one submodule an agent typically runs git status, git diff --stat, a check of the tracking branch, and a scan for unpushed commits. Call it four to eight commands. In a monorepo with thirty vendored dependencies that is well over two hundred commands before the agent has written a single line of code. Each one round-trips through the model's context window as human-shaped text it has to parse.

The result is familiar to anyone who has supervised an agent on a platform team's repository: the session burns most of its budget on orientation, the agent starts summarizing instead of reading, and the first real edit lands on stale assumptions. The submodule did not kill the agent. The cost of looking at it did.

One call per question, not one per directory.

FluxGit's answer is two read-only MCP tools that aggregate instead of enumerate. repo.brief, which shipped 2026-06-10, returns the whole repository's situation in a single structured payload: HEAD and branch state, any in-progress merge or rebase, working-tree summary, stashes, recent commits, and the part that matters here, recursive submodule drift rolled up into one section. Its output is capped by a regression test in CI so it cannot quietly bloat; on FluxGit's own repository it comes back under 1,500 characters.

repo.scope answers the other question agents actually ask: not "what is the state of everything" but "what is relevant to packages/api, where I am working." One call returns the working-tree changes under that path, the recent commits that touched it, churn over a window (commits and distinct authors), and the owners from CODEOWNERS when the file exists. When there is no CODEOWNERS, the field is null and says so, because a tool that invents answers teaches the agent to distrust all of them.

A realistic session becomes two calls: repo.brief for the shape, repo.scope for the subtree. Compare that with the two hundred commands above. The agent spends its context window on your code instead of on git's output formatting.

The same idea, one level up.

The pattern generalizes. fleet.radar applies it across repositories instead of across submodules: one call summarizes many local checkouts into an attention stack, without fetching, so an agent (or you) can see which of two hundred repos actually needs a look. Aggregation is the whole trick. Agents do not need more tools; they need fewer, denser answers.

One thing I have not built yet: the explicit "which submodule blocks which" dependency relation inside the brief. Today you get the drift per submodule and the rollup; the blocking graph is still on the roadmap, and I am not yet sure whether agents need it often enough to pay its output cost on every call.