A coding agent completes a feature, passes unit tests and opens a clean pull request. The reviewer still rejects it. The code introduces a dependency the architecture team explicitly prohibited, bypasses the approved error-handling pattern, or stores customer data in the wrong place. To the agent, the implementation may be technically sound. To the organization, it is the wrong solution.
The problem is rarely that a model has never heard of engineering standards. It is that the relevant local standards did not reach the task in a current, authoritative and applicable form. A model can follow the instructions in front of it while missing a design decision made outside the repository.
Why the rule gets lost
An organization may store conventions in .cursor/rules, CLAUDE.md, AGENTS.md, wiki pages, ADRs and pull-request discussions. Those files are useful, but they are often maintained by different owners and at different times. A new agent client may read one file and ignore another. A rule may apply to one service but be copied to all. A past incident may have superseded a constraint without updating the agent’s instructions.
Imagine that the team once permitted direct database access for a reporting prototype. After a security review, it approved access through a dedicated service. A coding agent prompted to “implement reporting” finds the prototype’s direct-query example and follows it. The resulting feature can pass tests because the tests measure functionality rather than whether the design respects the reviewed boundary.
Three checks before asking for better prompts
The reviewer can diagnose the problem with three explicit checks:
- Availability: Did the agent actually receive the rule or have an authorized way to retrieve it?
- Eligibility: Is the rule current for this project, actor and environment, or was it superseded?
- Evidence and authority: Is this the team’s approved standard, or merely a historical suggestion?
A failure at any check can generate the same complaint: “The agent ignored our standards.” But each requires a different fix.
These checks lead to different fixes. If the agent never saw the rule, improve context distribution. If it saw the wrong version, repair the source of truth. If it sees conflicting instructions, establish precedence and ownership. Rewording the prompt is useful only after the system can identify the correct instruction.
Native rule files are the last mile, not always the authority
A repository might contain AGENTS.md, a team’s CLAUDE.md, and .cursor/rules. Each can be an effective place to tell a coding assistant which tests to run or which patterns to avoid. Version control and code review can keep these files reliable within one repository. Problems begin when the same organizational decision is duplicated across different tools, repositories and developer setups.
Consider an authentication policy revised after an incident. The service team’s rule file is updated on Monday, the infrastructure team’s on Thursday, and a developer’s copied local file is never changed. Each agent may follow its own local instructions correctly, yet the organization gets three incompatible outcomes. Putting another sentence in the prompt doesn’t resolve which version is authoritative or where an exception applies.
A workable split is to keep tool-native instructions concise and operational while preserving the reviewed cross-team decision, rationale, owner, validity and supersession in a separate record. A connected agent can request the current, applicable context at task time; the local file can still explain how that particular tool should carry out work. This does not imply DM automatically synchronizes every vendor’s native files.
A concrete repair workflow
Pick one recent rejected PR. Identify the standard it violated and the evidence behind that standard. Write the current approved statement concisely, with its rationale, scope and owner. Link it to the relevant ADR or security review. Then rerun the agent task with that context explicitly supplied. Compare the implementation and the review comments.
If the problem disappears, make that context reusable for the next task rather than pasting the instruction manually every time. The goal is not to stuff every repository policy into a prompt; it is to select the handful that materially constrain this change.
How DM helps bridge coding tools and team decisions
DM maintains reviewed Decisions, Rules and Skills with evidence and applicability, so a connected coding agent can request the current organizational context for its task. Search and Ask DM help an engineer verify why a constraint exists. Prepare Context supports selecting appropriate records rather than indiscriminately loading a wiki. Graphify-backed repository intelligence can help connect the task to relevant codebase relationships.
The product does not replace tests, code review, branch protection or the coding agent runtime. It provides a governed source of team context that those workflows can consult. Nor does it assume that every local CLAUDE.md or Cursor rule is synchronized automatically; integrations and rule distribution should be verified for the tools actually in use.
Measure review friction, not prompt length
For a small pilot, track how many agent-authored PRs are rejected for known local constraints and how long engineers spend restating them. Improve one high-frequency category first—security, architecture or release practice. A useful outcome is fewer repeat comments and faster onboarding for another agent, not a bigger rules file.
Make review comments part of the feedback loop
A rejected pull request is valuable evidence of a context gap. Categorize the reviewer comment: was the agent missing a known rule, following a stale version, or making a choice the team has never formally decided? The remedy differs. A known rule should become retrievable task guidance; a stale rule needs an explicit successor; a genuinely new choice needs an owner to approve or reject the approach.
For example, suppose three PRs in a month reintroduce direct SQL access. The team can add a test or lint rule to catch the pattern, but it should also record the reason for the architectural restriction and supply it before code generation. Static checks prevent a particular error at the end of the workflow; reviewed context helps avoid proposing the wrong design in the first place. These controls reinforce one another.
Sources
Put shared context to work.
DM is AuzzurA’s Beta product for human + AI teams. Sign up or sign in through the DM portal.