When the model changes, the rules should not

Teams change the model behind their agents more often than almost anything else in the stack. A newer release drafts better, an older one is retired, a cheaper option is good enough for routine work, a region needs a different provider. Each switch is usually treated as an engineering upgrade. If your safety rules live inside the behavior of the model, it is also a policy change that nobody reviewed.

Where governance tends to hide

Look at a typical agent setup and ask where the rules actually sit. Often they are scattered across places that move with the model:

• The system prompt. "Always ask before sending email" is a request to the model, not a control. A different model may weigh it differently, or follow it until a long context pushes it out of view.
• The model's own judgment about when to ask. Some models are cautious and check in often; others push ahead. If the pause depends on that temperament, your oversight changes whenever the temperament does.
• Behavior seen during evaluation. The pilot passed because that model, on those prompts, happened to cite its sources. Nobody wrote down that citations were required, so nothing notices when the next model stops providing them.
• Vendor-side safeguards. Filters and refusals that come with one provider's service do not come with another's.

None of these is wrong as a layer. They are simply not the place to keep rules you cannot afford to lose.

The model proposes, the workspace decides

The durable pattern is to enforce rules at the boundary where actions happen, not in the text the model reads. The model plans, drafts and proposes tool calls. A layer outside the model, the harness or workspace that executes those calls, checks each one against policy before anything runs. What an agent harness is describes that layer in general terms.

In that arrangement, "ask before sending email" stops being a sentence in a prompt and becomes a property of the send action: any attempt to send, from any model, produces a pause and a request for a person. The model gets no vote on whether the pause happens. It only affects how good the draft is when the pause arrives.

What is allowed to change

A model switch should show up in the quality and shape of the work, and nowhere else:

• How well drafts, summaries and analyses read.
• How the agent breaks a goal into steps, and how many steps it takes.
• Which tools it reaches for first, within the tools the task allows.
• Speed and cost per piece of work.
• How often it arrives at a gated action, since a better plan may need fewer of them.

What must not change

These belong to the team, and a model switch should leave every one of them exactly where it was:

• The list of actions that pause. Sending, deleting, exporting, scheduling, acting in a live session, rewriting instructions and delegating to another agent. The seven action classes explains each one.
• Who may approve. Roles and their reach do not depend on which model is drafting. See who may approve agent work.
• How a decision is bound. One approval covers one attempt and is checked again when the action runs.
• Evidence requirements. A finding needs a supporting passage, and a value with no source stays unknown instead of being filled in.
• The audit trail. Requests, decisions, tool runs and outcomes keep landing in the same continuous record, so the work before and after the switch can be compared. What an agent audit trail should record lists the fields.
• Limits. Spending ceilings, bounds on time and tool calls, the stop control and the company boundary.
• What counts as done. Acceptance criteria are written against the outcome, not against the habits of a model. Write acceptance criteria first shows how.

Where GoCux puts the line

GoCux is built on the idea that the rules belong to the company workspace. A person on the team sets them and can interrupt at any time. The seven consequential action classes pause for a decision because of what the action is, and the refused call is quoted exactly, so the approver sees what was really requested, whichever model asked. Decisions and outcomes are recorded as receipts when they happen, on one continuous audit trail. Spend runs against visible credits under a daily cap, and a single stop control can freeze new work and anything that would reach the outside world, everywhere in the installation.

Model routing sits behind one gateway boundary inside the service, separate from those rules. The governance page shows how the pieces fit together.

A checklist for your next model switch

• Keep a fixed set of representative work orders with written acceptance criteria, and run them before and after.
• Confirm that every gated action still pauses, by triggering each class on purpose in a test project.
• Compare evidence, not prose: does each finding still carry a supporting passage, and do unknowns stay unknown?
• Check that refusals and "unavailable" states are still reported honestly rather than papered over.
• Compare the audit trail before and after; a switch should add no gaps and drop no fields.
• Read the system prompt for anything that is really a rule, and move it into enforced policy.
• Record the switch itself as a change, with who approved it and why.

Judging the work rather than the answer is the theme of the evaluation page; a model change deserves the same discipline.