I totally disagree about the monorepo argument. Mono-repos exist as a reaction to poor modularization and tight coupling which creates a need to update dependencies frequently.
The reason for having dependencies in the same repo as the trunk of the project code is precisely because the dependencies aren't sufficiently generic, too dependent on the project's business domain and so they require constant maintenance.
This tight coupling means that the agent requires more context to solve problems and implement simple features. The need for more context is a problem for agents, not a benefit. Agents benefit from modularization, loose coupling and well-chosen abstractions. These attributes do not correspond to the kinds of complex, tightly integrated codebases which benefit from having a monorepo structure.
Dependencies should be like tools. If you think of a hammer, you can do a lot of different jobs with the same hammer... You can debate whether or not a hammer is the right tool for any given job, but for those jobs where a hammer is the right tool, how often do you need to tweak the hammer itself? A hammer solves a very specific problem but that problem can be generalized to countless different use cases. A hammer would make a good module.
Now if you did a project for a candle factory and let the project business domain leak into the design of your tools/modules; you may build a hammer out of wax to straighten out candles... Then in your next project building a house you will find that this hammer doesn't work for that case and needs to be modified. This is a failure of separation of concerns. The tool was not originally optimized for the specific task of applying blunt force to a limited area; it couldn't do that narrow job very well and that's why it needs to be changed. Had you built a hammer out of steel, it would likely have solved both problems even through it's a completely different use case.