Why AI coding agents ignore your team's standards

AI coding agents ignore your team’s standards because those standards were never written where the agent can read them. The agent optimizes against the code in the repository, not against the decisions your team made in meetings, chat threads, and old pull requests. So it ships code that compiles, passes tests, and violates conventions it never saw.

The failure looks like success

Hand an agent a ticket — “implement tenant administration” — and it does exactly what you asked. It reads the ticket, reads the repo, and writes clean, working code. Tests pass. Code compiles. If you’re only watching the CI pipeline, everything is green.

Then a reviewer notices it logs customer identifiers you decided never to log, uses a database driver you banned two quarters ago, and bypasses the repository layer you standardized on. None of that was in the ticket. None of it was in the repo. The agent had no way to know.

This is the difference between technically plausible and organizationally correct. Capable agents clear the first bar easily and fail the second silently.

Why the standards aren’t in the repo

Most organizational standards live outside the codebase:

• Decisions made in meetings, with the rationale captured (if at all) in notes nobody re-reads.
• Rejected alternatives that explain why not — usually remembered only by whoever was in the room.
• Constraints (“never log customer IDs,” “no external upload without approval”) known to a few senior people.
• Skills — the expected way to do a class of work — passed on by osmosis during code review.

A README or a CONTRIBUTING.md captures a fraction of this, and it goes stale the moment a decision changes. The reasoning behind the decision — the part that tells you whether it still applies — is almost never written down. As one engineering leader told us, teams “remember what was implemented but not the assumptions, trade-offs, or constraints that led to that choice.”

Why copying rules into every tool doesn’t fix it

The common workaround is to write the rules into the agent’s context: a .cursor/rules file here, a CLAUDE.md there, an AGENTS.md on one developer’s laptop, a system prompt pasted into a chat and then lost. It feels like progress.

It isn’t a shared, governed memory. It’s the same rules, duplicated per tool and per repo, unversioned, and disconnected from the decision that created them. One repo’s .cursor/rules contradicts another’s. Nobody knows which copy is current, who owns it, or which one wins. The copies drift, and the drift is silent until something breaks in production. We wrote about this failure mode in detail in “.cursor/rules and CLAUDE.md are not decision memory”.

Closing the gap

The fix isn’t a smarter model or a longer prompt — it’s giving the agent access to an approved decision layer — a governed memory of the decisions your team already made — and serving only the part that applies to the task at hand.

In practice that means when the agent picks up “implement tenant administration,” it receives the tenant and data-model decision with its rationale, the repository-layer rule, the “never log customer IDs” constraint, the authorization for what it may touch, and a flag on anything in the task that conflicts with an existing decision. It does the work already aligned.

When it’s done, it writes back what it applied, a proposed architecture decision record, and any open question — and a human approves what becomes trusted memory. The agent proposes; it never approves organizational memory on its own.

The short version

Your agents aren’t careless. They’re context-starved. They will keep ignoring standards that live only in people’s heads, because a standard the agent can’t read is a standard that, to the agent, does not exist. Put those decisions in one place the agent can query, keep a human in the approval loop, and the same agent that shipped the wrong thing ships the right one.

See how this works end-to-end in the coding-agent alignment use case, or start with what Decision Memory is.