The Code Was Never the Hard Part of a Cross-Repo Change

The hard part of a cross-repo change was never writing the code. Ask an agent to change a shared response shape and it writes correct, tested code in the API repo in minutes. The hard part starts after that: branching the other repos, ordering the changes so a consumer doesn't build against a contract that doesn't exist yet, opening a pull request per repo, then cross-linking them so a reviewer can find the whole change instead of three unrelated diffs. That work is invisible in every demo of an agent writing code, and until recently it was entirely mine.

I wrote about the diagnosis in an earlier post: an agent that works one repo at a time misses the contracts, the ordering, and the conventions that span several. That post ended on a workspace config, a map that told the agent the repos existed and how they connected. It was honest that a map isn't a cure. Knowing the frontend consumes the backend doesn't branch the frontend, doesn't sequence the two changes correctly, and doesn't open the pull request. This is the part that shipped since then.

The Bookkeeping Was the Job

Say a shared error envelope changes. The API repo gets a new field, the frontend client needs to read it, a background worker needs to stop choking on the old shape. The code side of that is three small, mechanical edits, and an agent handles each one well inside its own repo. What isn't mechanical is everything that used to be mine afterward: check out each repo, cut a branch, land the changes in the order that keeps the worker from consuming a field the API hasn't shipped yet, open a pull request per repo, then go add the links between them. One unit of intent turned into four units of coordination, and the coordination happened by hand, after the agent's part was already finished.

One Backlog, Five Repos

Cross-repo engage turns that ordering problem into a declaration instead of a memory exercise. A backlog can name a target repo once at the top, for the common case where every task lands in the same place, or per task, for the case where it doesn't:

### Add error envelope field to response schema
Target repo: core-api

### Read the new field in the client
Target repo: web-frontend
Depends on: Add error envelope field to response schema

### Stop choking on the old shape
Target repo: job-worker
Depends on: Add error envelope field to response schema

The run reads that once and does the part that used to be mine: it checks out each declared repo, opens a branch there, commits the task's diff, runs that repo's own security and review gates, and opens a pull request scoped to that repo once every task targeting it is done. The client task waits on the schema task because the backlog says so, not because I remembered to run them in order. The repo the sprint started in keeps the sprint's own bookkeeping. Every other repo gets exactly what its reviewer needs to see, nothing else.

arch headroom runs automatically before that dispatch begins, and it answers a narrower question well: which files, anywhere the sprint is about to touch, are approaching their size and complexity caps. It's a plan-time report, not a task, so nothing happens automatically because of it. What changes is when you find out. Before, you'd learn a file was over budget when a task got blocked mid-sprint and had to stop to split it, which meant re-planning around work already in flight. Now the extraction is a task you scope on purpose before the sprint starts, not a detour a gate forces on you in the middle of one.

What Declaring Targets Costs

None of this is free. A backlog that names target repos per task is a real artifact: something you write, review, and keep, not a sentence you say out loud while pointing at a terminal. You have to know which repos a change touches before you start, the same dependency knowledge the workspace map from the earlier post exists to surface. Cross-repo engage doesn't do that reasoning for you; it doesn't decide that the worker depends on the API, you still declare that. What it does is take a backlog that already says so and stop losing the follow-through between the agent finishing and four repos having working branches, in the right order, with pull requests a reviewer can actually navigate.

Write the target repo into the backlog itself, next to the task it belongs to, not into your head and not into a chat message you'll scroll past later. The few minutes that costs up front is the same time that used to become branching and cross-linking after the fact, and it's the difference between a sprint you can hand off and one only you can finish.

Check headroom before you plan, not after a task trips over it. A file that's already close to its limit doesn't get more room because you're in a hurry.

And keep the map. The workspace config that told the agent these repos exist is still doing that job. Declaring targets tells engage where to act on what the map already knows. Neither one replaces the other.