An agent is useful exactly as far as it sees the right context, and Devin gathers it by several paths at once: from the current and other open files, from a local index of the whole repository, and from retrieval that pulls relevant fragments as you work. For Teams and Enterprise, an index of remote repositories and a Knowledge Base from Google Docs are added to this.
The naive move, when context matters, is to add more of it: pin every document that seems related, open more files, connect the whole knowledge base. The logic is clear: the more the model sees, the smarter the answer. In practice this logic inverts past a certain threshold.
It breaks against competition for attention. The context window and the model's attention are finite; an extra pinned document adds no knowledge but dilutes it, pulling weight away from what actually pertains to the task. An overfilled context gives answers that are more generic and less precise - the exact opposite of what it was filled for.
The professional technique is to pin narrowly and to the point. Keep module definitions, the target framework, the files you are editing in context - and remove everything "that might come in handy". For external documentation, do not dump it whole but give the version, the date and the specific section: this both aims retrieval more precisely and guards against relying on a stale edition. Conversely, an empty context is as harmful as an overfilled one: a model that does not see the target framework or the neighboring module honestly fills the gaps with guesses, so the goal is neither a minimum nor a maximum but a precise selection for the task. Context is a map, not a warehouse: the selection is valuable, not the volume.
Knowing how the engine works under the hood helps build the right intuition. It is a retrieval-augmented approach: the local code is indexed in full, including unopened files, and a proprietary retrieval technique feeds the model relevant fragments. So the engine does not "remember the whole repository" verbatim but each time retrieves what resembles the query. Hence a practical consequence: the more precisely the task is stated and the more narrowly the context is pinned, the more precise the selection.
Team capabilities have their own mechanics and their own boundaries. Indexing remote repositories and the Knowledge Base are available on Teams and Enterprise; on Pro the context lengths and indexing limits are expanded. The Knowledge Base in the current beta accepts Google Docs as a shared source, understands tables, charts and formatted text, but does not import images from documents, and the maximum is about 50 documents. This is a snapshot guide, to be checked against the current page.
One property of the Knowledge Base matters not as a limit but as a question of access. Once an admin publishes a document for the team, access to it within the team does not follow the individual ACL on the Google Drive side: all users of the team will see it regardless of the original restrictions in Drive. This is deliberate behavior of a shared base, but it easily surprises if you expect Drive's permissions to carry over on their own.
Why it is built this way rather than as a mirror of Drive's permissions. The Knowledge Base is a shared team context, not a file gateway; its point is that one piece of knowledge be available to everyone working on the task. The price of this uniformity is that publication becomes a separate decision about access rather than an automatic inheritance of someone else's permission model. The boundary is drawn by the admin at the moment of publication, not by Drive.
The cost of ignoring this is concrete and not always about answer quality. An overfilled context costs you precision and extra tokens - that is reversible. A document with a sensitive section published to the Knowledge Base costs not tokens but a possible leak within the team: what three people saw in Drive, everyone sees after publication. The second is fixed far more expensively than the first.
Two different things are worth checking. For quality - make sure only what is needed is pinned in context and that external links are marked with a version and a section; remove the excess and see whether the answer became more precise. For access - before connecting a document to the Knowledge Base, check its audience and sensitive sections, remembering that publication lifts Drive's restrictions. The first check is about precision, the second about safety.
The typical failures are two-sided. On one side - stuffing the context "just in case" and getting blurry answers, explaining them by "the model being dumb". On the other - publishing a document to the shared base without checking who will now see it, assuming Drive's permissions will hold. The sign of both is the same: context is filled without asking what exactly it adds and for whom. Answer that first - and most of both the precision misses and the access misses will not happen.