Give the Agent a Bounded Context
OpenCodeReview has now fixed both the evidence and the policy: it knows which change it is reading and which files and rules are admissible. This chapter examines the next design question: how can OCR give an agent enough related context to reason well without handing it an unbounded repository-wide conversation? The answer is a bounded review unit, formed by guarded grouping and then processed through separate planning and review phases.
The boundary matters because file-by-file review can miss relationships, while one conversation containing an entire pull request can lose focus and consume an unpredictable amount of context. OCR places a controlled layer between those extremes. It lets related files share a conversation, but it keeps grouping, tool access, round limits, and comment targets explicit.
Grouping creates a bounded review unit
When a change is large enough for partitioning to add information, OCR makes one inexpensive grouping request. The grouping model does not receive the full diffs. It sees metadata such as the repository-relative path, whether a file was added or modified, and its insertion and deletion counts. From that limited view it proposes groups of related files.
This restriction serves two purposes. First, it keeps the partitioning call cheap: the system does not spend a full code-review context merely deciding which files belong together. Second, it keeps responsibility clear. The grouping model is proposing a context arrangement, not reviewing the code or issuing findings. The actual diffs enter the later group conversations, where the main review prompt and rules apply.
A group is useful when the relationship among files changes the meaning of a local edit. An API handler and its service implementation may need to be read together. A renamed file and its call sites may form one logical change. Several localization files may be meaningful as a set. In each case, the group gives the agent a shared conversation in which it can compare the changes directly instead of reconstructing the relationship through repeated, separate calls.
The grouping result is not trusted blindly. OCR maps the model’s returned file indices back to the original diff list, ignores invalid or duplicate assignments, and gives every unassigned file a single-file group. It also splits groups that are too large in two different senses. A group cannot exceed the configured maximum number of files, and a group whose combined diff exceeds the prompt budget is broken down further. These are not quality heuristics the model can waive; they are mechanical limits around the proposed partition.
When the grouping response is empty, malformed, or unavailable, OCR falls back to one-file groups. That may lose some cross-file context, but it does not turn a failed optimization into a failed review of every file. The same principle applies to small change sets. When there are too few files for an LLM partition to buy much information, OCR can bundle them locally or review them per file according to churn thresholds, without spending another model call on grouping.