The repo pendulum — and why agents made it swing back

At some point in the last decade, engineers collectively decided that many small repositories was a problem worth solving. So we solved it. We built monorepos, wrote tooling around them, gave talks about them, and nodded at each other in conference rooms.

It helped. One tree, one search, one place to grep. Cross-repo inconsistency stopped being a daily tax.

Then AI coding assistants showed up. And we secretly started splitting repos again.

Here’s the thing: agents pay in tokens and attention. A monorepo isn’t just more code — it’s more irrelevant surface area. Context windows fill up before the actual work starts. The agent reads directory structure, skims a few folders, gets confidently “helpful”… and you’ve burned budget without progress. Monorepos weren’t designed for collaborators that think in tokens.

So, back to multi-repo, all 2015 again. Except now the agent is scoped to one workspace, and anything outside that boundary might as well not exist. You’re the human router again: open repo B, search, copy, relay, paste, repeat. The problem never left — it just waited for the architecture to circle back.

That’s the cycle. And once you see yourself doing the relay work often enough, you stop accepting it as normal.

What I actually wanted

A boring, local, read-only way to cross the boundary: from repo A, ask repo B a precise question, get back the specific context needed — without turning my workspace into a monorepo cosplay.

Not a portal. Not a search product. Not another web UI. Just context gathering with boundaries.

Now it’s globally known, the one thing engineers love doing is automating themselves out of work. So I started building. The idea: each workspace registers itself once, and any agent from any other workspace can query it directly. The agent stays in context. The answer comes from real source. No human relay. Hello, Recon.

The thing that made it small

The core is a local server that routes questions to the right workspace and spins up an agent session there. What made it actually buildable instead of a months-long side project is the GitHub Copilot SDK. It lets you start a headless agent session pointed at a specific working directory, with tool permissions scoped to what you allow, and get back a grounded answer.

const session = await client.createSession({
  model,
  workingDirectory: meta.path,
  onPermissionRequest: async (req) => {
    const allowed = authorizer(req.kind);
    return { kind: allowed ? 'approved' : 'denied-by-rules' };
  },
});

const result = await session.sendAndWait({ prompt }, timeoutMs);

That’s the executor. The agent reads the target repo’s actual source, follows references across files, and returns a grounded answer. workingDirectory is what makes this cross-repo — the session runs in the context of a completely different workspace than where the question was asked.

The router follows the same pattern: a lightweight session that reads the workspace registry, matches the question to the right target, and either returns a name or asks for clarification. It doesn’t guess.

Provider flexibility

Copilot SDK is the default — it’s what I use, and it’s the natural fit if you’re already in that ecosystem. But lock-in is annoying.

The Vercel AI SDK covers everything else. Same provider abstraction, same tool interface, different backend:

{
  "routerModel": "anthropic/claude-sonnet-4-20250514",
  "executorModel": "openai/gpt-4o"
}

Configure it in ~/.recon/config.json and the abstraction holds regardless of which model you prefer.

Usage

For Copilot users:

recon skill install

That drops a skill into ~/.copilot/skills/recon/. Your agent now knows about Recon and calls it autonomously when a question needs cross-repo context. No wiring.

For custom agent pipelines, Recon ships an SDK — same install pattern, same interface. Your agent gets a tool it can call; the answer comes back grounded in source.

Either way, the actual flow is four commands:

recon server          # start the local server once
recon init            # register the current workspace
recon peers           # see what's addressable
recon ask --to homeserver \
  "how do we access homeserver remotely? include exact methods, files, and commands"

Why local, why read-only

The moment this becomes remote and write-capable, it stops being a developer tool and becomes an org policy problem — security review, access control, approval chains. All valid concerns, none of which should block validating the core idea.

So the stance is intentionally boring: registry and session logs live on your machine (~/.recon/), cross-repo interactions are read-only, and output goes to stdout so agents can consume it directly.

The actual takeaway

Monorepos didn’t die. They just stopped being the default answer once your teammate has a limited context window, ships whatever you ask, and couldn’t tell you why repo A and repo B should even know about each other.

If you’re living across 10–30 repos and find yourself becoming the human router between your agent and your own codebase — that’s the boundary problem resurfacing, amplified by how agents consume context. The tooling just hasn’t caught up to the architecture shift yet.

Local cross-repo context, read-only, no infrastructure: github.com/ermirbeqiraj/recon