Two pieces of recent work, one from Credo AI and one from Qodo, have surfaced something useful about where the agentic coding industry has converged. They were not written together. They reach the same destination from opposite directions.
The two halves
Credo AI, in a recent post on enterprise-level agentic coding, argues that the productivity gains from agents like Cursor and Claude Code in large monorepos depend less on the agent and more on the constraints it operates under. The piece advances a specific frame: agents should be governed by machine-readable rules embedded in the repository itself, rules that specify which imports are permitted, which components to reach for, how files should be named, what to do when a legacy pattern is encountered. The analogy offered is linting configuration, but for architectural guidance rather than syntax. The argument is that without these constraints, agents reach for the wrong primitives, propagate the wrong dependencies, and produce work that looks correct in isolation but is structurally wrong in context.
This is upstream governance. It shapes the work before it is written.
Qodo, in its February 2026 release of version 2.0, advances the opposite end of the same problem. Qodo Merge is a multi-agent review architecture that analyses the diff of a pull request before merge: parsing the actual changes, isolating modified logic paths, identifying coverage gaps, security issues, and quality regressions. Specialised agents evaluate different dimensions of the change in parallel and produce structured review feedback while the PR is still open. The architecture has now been benchmarked against seven other leading review tools and produced the highest recall and F1 score.
This is at-gate governance. It evaluates the work after it is written and before it lands.
Both are real, both are necessary, and both are doing useful work. Together they bracket the agentic coding lifecycle from two ends: Credo's rules constraining what the agent generates, Qodo's review catching what slips through. This is good. The industry is converging on the right pattern.
What neither half captures
Neither layer, on its own or in combination, captures the governance decision itself.
Credo's rules tell the agent what it may and may not do. They are policy declarations applied to authoring. The agent obeys them, or it does not. Either way, no human approval event is recorded.
Qodo's diff analysis produces structured feedback at the gate. It tells a human reviewer what the multi-agent system found: coverage gaps here, a suspicious empty error handler there, a JWT verification path that looks unverified. The human reads this, decides whether the issues are acceptable, and clicks approve or request changes. The review feedback is captured. The decision is not.
This is not a criticism of either tool. They are doing exactly what they were designed to do, and doing it well. The observation is that what they were designed to do does not include capturing the human governance decision as a first-class event, because that is not the layer they sit at.
There is a layer between Credo's upstream policy and Qodo's at-gate review that nobody is currently building deliberately. It is the layer where the human approval happens. The audit trail at that layer is whatever the underlying platform (GitHub, GitLab, Bitbucket) captures by default, which is the click, the timestamp, and not much else.
The layer between the layers
A complete governance architecture at the merge gate has three components, not two.
Upstream: machine-readable policy applied during authoring. Credo's frame is correct here. Agents need explicit, programmatic constraints, not chat-window guidance. Without these, the agent's output drifts from what the codebase actually requires, and review becomes adversarial rather than collaborative.
At the gate: diff-aware structured analysis surfaced to the human reviewer. Qodo's frame is correct here. The reviewer needs the agent's findings parsed, weighted, and presented as decision context: not a wall of comments, but structured signals about what the change actually does and what risks it carries.
On top: the governance decision record itself. This is the layer that captures the human approval as a structured event: what the reviewer was looking at, what risks the system surfaced, what the reviewer accepted as residual risk, and what authorised the merge to proceed. This layer does not replace policy-as-code or diff analysis. It sits on top of them and produces the auditable record that the other two layers, by design, do not.
The three components compose. Policy upstream constrains the agent. Analysis at the gate informs the human. The governance record on top captures what the human decided and on what basis. Removing any of the three weakens the other two. The upstream policy without the gate analysis cannot catch violations that arise from interactions the rules did not anticipate. The gate analysis without the governance record cannot prove to an auditor what the human reviewer was actually shown. The governance record without the first two captures decisions made on incomplete information.
Why the layer between matters
The reason this layer is not being built today is straightforward. Each existing tool sits at the layer it sits at because that is the layer where its competitive advantage lives. Credo AI is a governance platform vendor focused on AI risk across the lifecycle, with the rules-in-monorepo work being one expression of a broader product. Qodo is a code quality platform focused on what AI can do at the review gate. Neither is incentivised to build a layer that sits on top of both, because that layer is by definition tool-agnostic; it has to work regardless of which upstream policy engine or which review system the customer chose.
That tool-agnosticism is exactly why the layer needs to exist as its own infrastructure rather than as a feature inside any one product. The governance decision record at the merge gate must be portable across the policy engine, the review system, the version control platform, and the CI/CD layer, because in any real enterprise codebase those four things were chosen at different times by different teams for different reasons. An organisation that standardises on Credo for policy and Qodo for review still needs a governance record that survives the day they swap one of them out.
This is the layer Tomosu is building.
Tomosu builds merge-gate governance infrastructure that sits on top of your policy and review tooling. If you're operating production AI-assisted development workflows and need an auditable governance record at the merge gate, we are opening a small design partner cohort. Book a call →