I ran into a misguided pattern going by the terrifying name "the monorepo." People are seriously merging different projects into a single physical git repository because they think it makes it easier for an agent to "walk the files" and understand the overall context of a large corporate system. Dozens of comments under the post: oh yes, we started doing this too, excellent mechanism, everyone is happy.
This is the wrong abstraction boundary.
You Mistook an Out-of-the-Box Feature for LLM Magic
What looks like repository awareness is usually just tool-mediated file access.
What you observe with your eyes — the agent reading files from disk — is simply a tool. A built-in tool of your application that the model triggers to call shell commands: ls on a directory, read a file. The model receives text returned by a tool; it does not gain a special architectural understanding from the repository layout.
File-system access is only one possible implementation of context retrieval. It is one feature out of the box. It is simply easier to master AI this way when you see it for the first time: because the first visible implementation often uses local directory traversal.
And from this "wow" a conclusion is born: let’s move unrelated repositories into one physical repository, how convenient it will be for the agent!
The problem is not that this is ugly. The problem is that you are making an irreversible architectural decision — breaking repository boundaries, history, access rights, CI, code ownership — to optimize for a local-file access demo rather than for repository ownership, permissions, and CI boundaries. The costs are concrete, while the claimed benefit can be achieved at the tool layer.
The Model Does Not Care Where the File Came From
The key technical point is this:
The tool_use programming interface of the model is standardized. The model does not care where the file is actually, physically read from. Straight from the disk in the current directory. Or from another directory. Or from a remote git repository. Or from an SFTP connection. Or over HTTP from somewhere on the network.
For the model, it is just content. And you can deliver content to it in any way.
The relevant separation is: "where the code physically lies" and "what the model sees" are two different things that the tool_use abstraction has already decoupled for you. The source of content and the method of feeding it to the model are not the same. The model does not walk your disk. It calls a tool that returns text to it. Where that tool got the text is an implementation detail not represented in the model input unless the tool exposes it.
Since that is the case, a physical monorepo built for the agent solves a problem that belongs to context retrieval, not repository topology. You joined two projects at the filesystem level to solve a task that lives at the tool interface level. It changes persistent source-control structure to solve a runtime context-delivery issue.
How to Do It If You Actually Need Adjacent Context
If the agent needs adjacent project context, expose that context through a read-only retrieval tool.
You can provide an MCP server or another read-only retrieval layer with readonly access to neighboring directories — or to a shared GitLab or GitHub — and provide the same model-visible code context. The model triggers the tool the same way, gets the content of the adjacent project the same way, and "understands the overall context" the same way. Only without the need to physically merge unrelated codebases into one repository.
The same result for the model. Repository boundaries, history, permissions, pipelines, and ownership remain unchanged. Your repositories remain themselves: separate history, separate permissions, separate pipelines, clean ownership boundaries. And the agent's access to foreign context becomes a configurable context source rather than a property of your directory tree.
Reading from disk is the default they showed you first because it is the easiest thing to explain to a beginner. It should not be treated as the only supported context-delivery model. It is the most primitive method of feeding content, and you are using a default retrieval mechanism as justification for repository restructuring.
Stop Breaking Repositories for a Hallucinated Convenience
The conclusion is: This approach confuses context access with source-control architecture. Do not restructure repositories merely to match the first file-access mechanism your agent exposes — do not gut your architecture for a demo interaction mistaken for an architectural requirement.
The source of content and the method of feeding it to the model are different layers. tool_use already decoupled them. A physical monorepo "to make it convenient for the agent" is implementation mimicry without understanding the abstraction boundary: you are copying the visible local-file workflow instead of designing the retrieval layer explicitly.
A safer design is to keep repositories separate and expose adjacent context through controlled read-only tools.