The short version

Prompts can guide behavior, but they should not be the only barrier protecting a consequential action. A robust agent design lets Claude understand the request and prepare a proposed change, while the surrounding application checks permissions, limits, identifiers, and current state before anything is applied.

The division is simple:

  • Claude: understand, reason, recommend, and stage.
  • Trusted software: validate, authorize, enforce, and apply.
  • People: approve decisions that require accountable judgment.

Why prompts are not enforcement

A language model produces probabilistic outputs. Even a careful instruction can be misunderstood or affected by untrusted material in the context. If the same model both chooses an action and decides whether its own safety rule applies, the boundary is fragile.

Deterministic checks give the application an independent decision point. They can compare the requested amount with a current limit, confirm that an identifier exists, verify the caller’s permission, protect fields that may not change, and refuse a stale proposal.

Propose, stage, apply

For high-impact workflows, split the action into three states:

  1. Propose: Claude explains what should change and why.
  2. Stage: the system records an exact, reversible proposal without executing it.
  3. Apply: trusted code rechecks the current state and executes only after every policy and approval condition passes.

The staged record should contain enough detail for a reviewer to understand the effect. It should also expire or require revalidation when underlying data changes.

Example

Consider an invoice workflow. Giving Claude a direct payment tool and adding “never pay above the limit without approval” leaves the model close to an irreversible action. A safer design lets Claude create a payment proposal containing the invoice identifier, supplier, amount, and supporting evidence.

The payment service then checks supplier status, duplicates, user authority, and current thresholds. When approval is required, the proposal remains pending until an authorized person confirms it through the established system. The service rechecks the state immediately before execution.

The same design applies to account changes, customer records, contract language, publication workflows, and configuration updates.

Design for containment

Ask a practical question: if Claude selected the wrong action, could the surrounding system still prevent harm? If not, move more authority out of the model. Prefer narrow tools that express proposals over broad tools that can directly alter many parts of a system.

Practical checklist

  • Keep behavioral guidance in the prompt.
  • Use proposal or staging tools for high-impact changes.
  • Validate identifiers and permissions in code.
  • Protect limits and sensitive fields independently.
  • Require accountable approval where appropriate.
  • Recheck current state at execution time.
  • Preserve a clear record of proposed and applied changes.

Try it

Choose one workflow that changes money, access, data, or a customer-facing result. Define what Claude may recommend, what it may stage, what software must validate, who may approve, and what must be rechecked before execution.