Pre-Action Enforcement: Where Agent Governance Takes Effect

Agents act, and most controls arrive afterwards

A coding agent does more than suggest text. It edits files, runs shell commands, installs packages and opens pull requests. Most of the controls engineering teams rely on see only the result. Code review sees a diff. Continuous integration (CI) sees a branch. Observability sees a log. By the time any of them looks, the action has already happened.

That ordering was fine when a person made every change and a reviewer checked a handful a day. It holds up less well when agents make changes faster than people can read them. The question becomes where a control can take effect, not only whether one exists.

What pre-action enforcement means

Pre-action enforcement evaluates a proposed agent action against the team's decisions before the action executes. Decisions here are the engineering choices a team has recorded, such as a banned library or a boundary between layers. The check returns a deterministic verdict: allow it, warn about it, or block it. The control sits between "the agent decided to do something" and "it happened".

The term names where a control runs, not a product category. Pre-action enforcement is one of the ways engineering decision governance, which determines which decisions govern a given change, gets applied to agent work. The other ways are guidance before the agent writes anything and verification after it has.

intent -> context -> generation -> proposed action
                                       |
                              decision check (verdict)
                                       |
                       execute  |  warn  |  block
                                       |
                              verify (CI, review)

Not every boundary is equal

An agent's work passes several points where a control could run. They differ in what the control can see and what it can stop:

Boundary	What a control can do there	Limit
Before generation	Give the agent the decisions that apply, as context	Guidance only. The model can still ignore it.
Before a write or tool call	Inspect the proposed change and block it before it lands	Only works when the control can reconstruct exactly what the action will do
End of turn or session	Check every file the agent changed	The change is already on disk, though not yet merged
Pull request and CI	Verify the final tree before merge	Late, but it sees everything that reached the repository

A common mistake in agent governance claims is to treat these boundaries as equivalent. Guidance before generation is useful, but it is not enforcement. A rule in a prompt or an instruction file is a request. A check at the write boundary that can refuse the change is a control.

Guide before generation, govern before action

A frequent objection: by the time a pre-write check runs, the model has already generated the violating code. That is true. The goal is not to stop a model from thinking of a bad change. It is to stop the change reaching the codebase.

A useful way to hold the three stages together is: guide before generation, govern before action, verify after action. Each stage catches what the earlier one missed.

A gate can only judge what it can see

Pre-action enforcement has a hard technical limit. The gate, meaning the check that runs at the boundary, has to know the action's effect in advance: which file, and what content.

A structured edit tool call carries both. The gate can compute the resulting file and check it. A shell command such as sed -i, a chained command or a script hides the path and content inside command text. The gate cannot reliably reconstruct what it will do, so it cannot judge it reliably beforehand.

That means pre-action coverage is per action path, not per agent. Any honest integration states which paths it checks before execution and which fall through to a backstop, a check at a later boundary. Two examples come from the integrations of Mneme, an open-source decision and control layer for agentic software development:

Claude Code. Its file-editing tools (Edit, Write and MultiEdit) are checked before they touch the filesystem. One narrow shell form, a single cat command that writes inline text to a file, is checked before it runs. Other shell writes pass through and are caught at the end of the agent's turn, when every changed file is checked. See the Claude Code integration.
OpenAI Codex command-line interface (CLI). Native apply_patch additions and updates are checked before execution, and a violation denies the whole patch. Shell writes are not checked beforehand; a Stop hook audits every file the session changed. Validated against Codex CLI 0.149.1. See the Codex CLI integration.

Why the verdict has to be deterministic

A pre-action gate that asks a language model "does this change look acceptable?" will answer differently on different runs. That is a second opinion, not a control. A team cannot audit it, and an agent cannot learn a consistent boundary from it.

A deterministic gate gives the same verdict for the same change and the same decisions, every time. It can record which decision fired and why, so a person can reconstruct the verdict afterwards. The deterministic enforcement concept page covers the property in more detail.

What belongs in a pre-action policy

Not every decision should block an agent. Good candidates share two traits: they are expensive to reverse, and they can be checked mechanically.

a client library or import that is banned in a given part of the codebase
a dependency the team ruled out
a path the agent should not write to, such as production migrations
a boundary that one layer may not cross, expressed as something a check can detect

Mneme's typed rules cover the first two today, with a ruled-out dependency raised as a repository-wide warning rather than a path-scoped failure. Write-path restrictions are not a shipped Mneme rule.

Judgment calls stay with people. "Is this abstraction right?" is not a pre-action rule. Neither is code style, which linters already handle. Package Hallucinations Show Why AI Coding Needs Pre-Action Governance walks through one worked case: a dependency that exists, passes security checks and still breaks a team decision.

Pre-action does not replace post-action

Pre-action enforcement stops what it can see. It does not see everything, so the later boundaries stay. The working model is prevent, catch, verify:

Prevent supported actions before they execute.
Catch what escaped at the end of the turn or session.
Verify the final state of the repository in CI, and keep human review for trade-offs.

Review still matters, but it is a different control with a different job. See Review Is Not Governance.

What engineering leaders should do

List the actions your agents can take. File edits, shell commands, package installs, pull requests, and anything else their tools allow.
For each, find the earliest boundary that can see it. Be explicit about which actions have a pre-action check and which only have a backstop.
Turn the costly, checkable decisions into rules. Scope each rule to the code it governs, so it fires where it applies and nowhere else.
Keep the backstops. End-of-turn checks and CI catch what pre-action gates cannot reconstruct.

A useful single question for the team: which decisions can our agents violate before any control intervenes?

Where Mneme fits

Mneme applies pre-action enforcement to architectural decisions in a repository. It compiles the enforceable parts of accepted decisions into typed rules. The typed rule that can fail a change in specific paths is FORBID_LITERAL. It forbids an exact string, such as a disallowed import, in the paths a decision governs.

Mneme sits mainly at the boundary between a proposed action and its execution. Pre-write hooks ship for five coding agents: Claude Code, the Claude Agent SDK, Codex CLI, Kiro and Google Antigravity, each covering the action paths its integration page lists. The Claude Agent SDK adapter also injects the relevant decisions into the model's context when a task is submitted; in Claude Code, the /mneme:context command retrieves them on request. A reference GitHub Actions workflow runs the same check on every pull request; set as a required status check, it blocks the merge. Extending enforcement beyond code writes, to database migrations, infrastructure changes or agent delegation, is a direction, not a shipped capability.

The Architecture Audit answers part of that question for a repository. It classifies each documented decision as Protected (verified protection by an existing typed rule), Mneme-ready, Requires modelling or Guidance (no deterministic enforcement shape).

Frequently asked questions

What is pre-action enforcement for AI agents?+

Pre-action enforcement checks a proposed agent action against a team's decisions before the action executes, and returns a deterministic verdict: allow, warn or block. For a coding agent, the typical action is a file write. The check runs after the agent has decided what to change but before the change reaches the codebase, so a violating write can be refused instead of found later in review.

Is pre-action enforcement the same as pre-generation guidance?+

No. Pre-generation guidance gives the agent relevant decisions as context before it writes anything. It shapes what the model produces, but the model can still ignore it. Pre-action enforcement inspects the change the agent is about to make and can refuse it. The two work together: guide before generation, govern before action, then verify after action in CI and review.

Can pre-action enforcement check shell commands?+

Only when the gate can reconstruct exactly what the command will do. A structured edit carries the target file and content, so it can be checked in advance. Commands such as sed -i, chained commands or scripts hide the path and content in command text, so most cannot be judged beforehand. Honest integrations list which action paths they check before execution and catch the rest at a later backstop, such as an end-of-turn audit or CI.

Does pre-action enforcement replace code review and CI?+

No. It stops the actions it can see, and some actions are always out of view. The working model is prevent, catch, verify: prevent supported actions before they execute, catch what escaped at the end of the turn or session, and verify the final state of the repository in CI before merge. Human review remains the place for design trade-offs that no rule can encode.