My coding agents can't see my whole product
Here's a thing that happened to me recently, and it's so dumb that I need to write it down.
I have a product with a frontend repo and a backend repo. Two separate repos, one product. This is not exotic. This is probably the single most common setup in the world. And I wanted to do the most normal thing imaginable: open one agent session that can see both, so when I say "add this feature," the agent can touch the API endpoint on one side and the UI that calls it on the other side, in one go, with full context of both.
I could not do it. Not in Superset, not really in any of the agent orchestrators I've tried. These tools are built around one assumption baked so deep they can't see past it: one task lives in one repo. If your change crosses a repo boundary, that's your problem. The suggested fix, and I'm not making this up, is to create a parent folder, turn it into yet another git repo, and put your two real repos inside it just so the tool has something it recognizes. I have to create a fake repository to trick my tooling into looking at my actual product. That's when I knew I had to write this.
The assumption underneath everything
Every orchestrator in this new wave, and I mean the whole category, is built on the same primitive: the git worktree. You give it a repo, it creates an isolated worktree per task, an agent runs inside that worktree, you review the diff, you merge. One task, one worktree, one branch, one repo. It's a clean model and I understand why everyone converged on it. Worktrees give you isolation for free. Two agents can work in parallel without stepping on each other, because git already solved that problem years ago.
But notice what quietly happened there. The tool didn't ask what shape your product is. It asked what shape git repos are, and then it decided your work must fit that shape. The unit of isolation became the unit of thinking. And those are not the same thing at all.
What a real product actually looks like
My product is at minimum two repos. Plenty of teams are way past that. There's a frontend, a backend, maybe a shared types package, maybe an infra repo with the Terraform, maybe a docs repo. The product is the whole constellation. No user has ever cared which repo a feature lives in. Features don't respect repo boundaries, because repo boundaries were drawn for deployment and ownership reasons, not because the work naturally splits there.
Think about what an ordinary feature actually is. "Let users export their data as CSV" means a new endpoint in the backend, a new button and download flow in the frontend, and probably a shared type for the export format. That is one task. One coherent thought. Any human engineer picking it up would open both repos side by side without even thinking about it, because obviously you need to see the endpoint to write the code that calls it.
The agent doesn't get to do that. The agent gets a worktree of one repo and a blindfold for everything else.
What it costs you in practice
So what do you actually do? You run two sessions, one per repo, and you become the message bus between them. The backend agent designs an endpoint, and then you copy the response shape into the frontend agent's context by hand. The frontend agent guesses a field name slightly wrong, and neither agent can catch it, because neither one can see the other's code. You catch it at runtime, like an animal.
I want to be really clear about how backwards this is. The entire pitch of these tools is that agents handle the mechanical work so you can think about the product. And here I am doing the most mechanical job in the entire building: carrying JSON shapes between two windows. The agents are doing the thinking and I'm doing the copy-pasting. We built the future and it made me the intern.
The workarounds are all bad, and I've tried them
The parent-folder trick I mentioned is the popular one. Make a directory, drop both repos in it, git init the wrapper, point the tool at that. Now the tool is happy and everything else is broken. Worktrees get weird because you have nested repos. The wrapper repo is a lie with no real history. Your CI doesn't know it exists. And you've added a permanent piece of scaffolding to your life whose only job is to satisfy a tool's data model.
The next suggestion people reach for is "just use a monorepo." And look, monorepos are a legitimate choice, some of the best engineering orgs on earth run one. But migrating your product's entire repo structure because your agent tool has a rigid data model is the tail wagging the dog so hard the dog is airborne. Repo structure should be decided by deployment, ownership, and CI concerns. "My orchestrator can only look at one repo at a time" should not even be on the list of inputs to that decision.
And git submodules. I'm not going to spend a paragraph on submodules. If you've used them you already understand, and if you haven't, protect that innocence.
The tool isn't wrong, the primitive is
I want to be fair here, because this isn't a takedown. Worktree isolation is genuinely the right call for parallel agents, and the teams building these tools made a smart engineering tradeoff to ship fast. Treat every agent as a thing that runs in a terminal, wrap it in a worktree, put a diff viewer on top. It works, and it got the whole category off the ground.
The mistake is one level up. The workspace became the product's main character. In most of these tools, the thing you create, name, click on, and think about is the workspace, and a workspace is defined as a checkout of one repo. The task, the actual unit of human intent, got demoted to a description you type into the workspace. It should be exactly the other way around. I have a task: ship CSV export. The task should be the object. The tool's job is to figure out that this task needs a worktree in the frontend repo and a worktree in the backend repo, give one agent (or a pair of coordinated agents) visibility into both, and hand me back one review that shows the whole change together. Which repos got touched is plumbing. I should find out in the diff, not decide it upfront.
One review, not two
That last part matters more than it sounds. Even if you suffer through the two-session dance, you end up with two PRs in two repos for one logical change. They have to be reviewed together to make any sense, merged in the right order, and rolled back together if things go wrong. Every team with a multi-repo product already has scar tissue from cross-repo changes done by humans. Agents make it worse, because agents produce more changes per day, which means more cross-repo pairs floating around half-merged. The review layer needs to understand that these two diffs are one decision. Today it doesn't even know they're related.
This gets more wrong every month, not less
Here's why I think this is the assumption to attack, and not just a papercut. Agents are getting better at exactly the kind of work that crosses boundaries. Refactor this API and update every caller. Rename this concept across the product. Keep the mobile app and the web app in sync. The more capable the agent, the more its natural task size grows past a single repo. So the tools are optimizing the primitive that matters less every month, while the thing that matters more every month, cross-repo context, isn't even on the roadmap. The ceiling on how useful your agents can be is currently set by a decision git made about directory layout.
A session should be scoped to a set of repos, and honestly, done right, this can be lighter than what exists now, not heavier. You don't need a fake wrapper repo, you don't need a monorepo migration, you don't need the tool to own your directory layout. You need the orchestrator to hold a list of repo paths and give the agent read access across them. That's it. That's the whole feature. The fact that it doesn't exist tells you how deep the one-repo assumption goes.
Where I've landed
The test I keep coming back to is simple: would a human engineer be allowed to work this way? If I told a new hire "you may look at the frontend repo, but the backend repo is off limits, guess the API shapes," I'd be fired, and rightly so. Every rule we'd call insane for a human engineer is somehow the default architecture for agents, and everyone's just accepted it because the demos look cool.
My product is not one repo. Yours probably isn't either. The first tool that treats the task as the real object, and the repos as plumbing underneath it, is going to feel so obviously right that we'll all wonder why we spent years making fake parent repos. I've got more to say about what else is broken in this category, starting with what happens to your agents when you close your laptop. Spoiler: they die.