Programmable AI Policy Is Not Enough for Coding Agents

Governance is moving into the execution path

Enterprise AI governance spent several years as a documentation exercise. Model cards, risk registers, review boards, retrospective audit. The agentic shift has made that posture untenable, because an agent that has already executed a tool call has already changed something.

Cognizant's Venkatesh Subramanian made the argument directly in August 2026 in How to Govern Agentic Systems in Real Time. Governance, he argues, has to evaluate prompts, responses, tool calls, and agent-to-agent messages "before actions take effect" rather than explaining them afterwards. The piece also makes two adjacent points worth taking seriously: policy should be updatable by the people who own the risk rather than only by the people who own the code, and every governed interaction should leave an audit-ready record of which policy applied and what was decided.

That is a large consultancy describing the same movement from observation to enforcement that we have been arguing for. It is useful external validation. It is also, for software engineering specifically, only half of the problem.

Architectural rules are not thresholds

Consider the kind of policy that translates cleanly into a runtime control. A transfer above a set amount requires additional authorization. An agent may not send external email. Tool X is unavailable to agents operating in region Y. These are conditions over values, and turning them into code is mostly an implementation detail.

Now consider the equivalent statements in a software architecture:

• Services communicate asynchronously through the event bus.
• This bounded context owns customer identity.
• Persistence in the payments subtree goes through the repository layer.
• Nothing in the domain package may import from infrastructure.

Every one of these is a real decision that a team actually made, and none of them is a threshold. They require knowing what counts as the event bus in this codebase, which paths constitute the payments subtree, and which imports are infrastructure. They carry semantics and scope rather than values.

Most of them are also not written down anywhere a machine could reach. They live in an architecture decision record from two years ago, in a diagram, in a convention nobody documented, or in the head of the engineer who set the pattern. You cannot make a policy programmable if it was never expressed as a policy.

Agents turn undocumented architecture into an operational problem

Human teams absorb this gap without noticing. A new engineer writes something that violates an unwritten convention, a reviewer says we do not do it that way here, and the convention propagates socially. Slowly, but it works.

That mechanism does not scale to agents, for two reasons. Agents do not accumulate institutional memory across sessions, so the correction has to be re-delivered every time. And the volume of changes rises to a point where re-delivering it manually stops being viable.

The result is that architectural ambiguity, which was previously a slow tax on onboarding, becomes an operational failure mode. The question stops being whether generated code is correct. It becomes whether the implementation was permissible under the architecture governing that part of the system.

Retrieval gets the decision into the room

The common answer is to retrieve the relevant decision and put it in the agent's context. That is necessary and it is not the same as governing.

Retrieval can surface a decision. It cannot guarantee that the right decision was selected, that it applies to the files actually being changed, that conflicting decisions were resolved in the right order, that prose was interpreted as intended, or that the prohibited construct was actually avoided. We have set out the full version of this argument in RAG versus governance, so it is enough here to note that the two operate at different layers.

Decisions need scope before they can be controls

The missing piece between an architecture decision record and an enforceable control is applicability. A decision needs to say where it binds.

Concretely, that means a decision carries three things rather than one: the choice itself, the paths or constructs it governs, and the constraint that follows. A decision that persistence services use PostgreSQL, applying to the payments and orders subtrees, prohibiting new SQLite dependencies, is evaluable. The same decision as a paragraph of prose is context.

This is what the site means by executable architectural intent, and the distinction it turns on is simple. An architectural decision without applicability is documentation. An architectural decision with deterministic applicability and an explicit constraint can function as a control.

Where the check happens

Real-time is doing a lot of work in the phrase real-time governance, so it is worth being exact about the surfaces available for coding agents. There are three, and they are not interchangeable.

• Before generation. Applicable decisions are selected and supplied as part of the agent's working context, so the implementation starts inside the constraint rather than being corrected toward it.
• At the agent's action. A hook evaluates an attempted file write or edit and returns a verdict before the operation executes. This is the surface that most resembles what Cognizant describes, because the action has not taken effect yet.
• On the resulting change. A deterministic check evaluates a diff or working tree, in a developer's environment or in continuous integration, before a change merges.

Each catches something the others miss, and none of them is a substitute for having written the decision down in an evaluable form in the first place.

An enforcement record is the deliverable

Subramanian's audit point translates well, and for engineering it is more useful than it first appears. Six months after the fact, the valuable artifact is not the diff. It is the answer to a specific set of questions: which agent made the change, which decision applied, which version of that decision, why it applied to that path, what constraint was evaluated, and what the verdict was.

That record is what makes architectural governance reviewable rather than advisory. It is also what makes it possible to change a decision deliberately, because you can see everything that was previously enforced under the old one. Without it, an override is indistinguishable from a violation.

Two layers, not two products

It would be easy to read the Cognizant piece as a competitor staking a claim. It is more accurate to read it as a description of an adjacent layer.

Runtime AI governance asks whether a deployed agent is permitted to perform an action: call this tool, move this money, message this counterparty. Architectural governance asks whether a coding agent is permitted to build the system this way. Both are enforcement, both need programmable policy, both need provenance. They govern different objects, and an organization running agentic engineering at any scale will eventually need both.

What software engineering adds is the harder input problem. The runtime layer inherits its policies from risk and compliance functions that are used to writing them. The architectural layer has to first turn decisions that were never written as rules into something a machine can evaluate. That translation, from decision to scope to constraint to verdict to evidence, is the actual work.