Catalog / Governance

Propose and dispose

The model proposes and code disposes. The agent returns a typed proposal, and a deterministic gate validates it against policy before executing anything.

Reference task used across all patterns: "My order arrived damaged. Can I get a refund?"

Topology

ActorLead agentGateTool

Run

07 steps

Ready to run

Play runs the whole scenario. Step advances one event at a time so you can read what happens.

Metrics

Wall-clock time0.0 s
Tokens processed0
Estimated cost$0.000
Unvalidated actions
0
Illustrative values. They show proportions between patterns, not benchmarks.

All steps

Normal run

  1. Request arrives. The agent can read the order system, but it has no tool that changes anything.
  2. The agent decides. Order 4417, damage confirmed, inside the 30-day window. The agent concludes that a full refund is due.
  3. Propose. Its output is a typed proposal, not an action: refund, order 4417, $240, reason damage. The schema leaves no room for free text.
  4. Validate. The gate is ordinary code. It checks the proposal against the system of record: the order exists, the amount equals its total, the date is in range.
  5. Execute. The gate, not the agent, calls the payment tool, using the values it has just verified.
  6. Confirm. The result goes back to the agent as a fact it can report. A rejected proposal would return here too, with the reason.
  7. Respond. Refund approved. Validation added a tenth of a second and no tokens.

Outcome: correct answer, verified by code. Judgment stayed with the model and exactness stayed with code. The agent could be wrong about the amount without the customer ever being paid the wrong amount.

Failure mode

  1. Request arrives. In this build there is no gate in the path. The agent calls the payment tool itself.
  2. A misread number. The agent pulls the order total out of a long context and gets $420 instead of $240. Models transpose digits; that is expected, not exceptional.
  3. Direct execution. With the payment tool in its own hands, the agent's guess is executed as is. Nothing compared the amount with order 4417.
  4. Response. The customer is told the right thing and paid the wrong amount. The error surfaces weeks later, in accounting.

Failure: an unvalidated action. The reasoning was right and one parameter was wrong, which no prompt can rule out. Mitigation: agents emit typed proposals, and a deterministic gate validates them before anything executes.

Execution trace

Model workingSending a message

Reference

Problem
Model output is probabilistic, but some actions have to be exactly right: amounts, recipients, record ids.
Analogy
An architect draws the plan, and a building inspector checks it against the code before anyone pours concrete.
Use when
Actions have hard, checkable rules such as limits, schemas and referential integrity, and the check is cheap to write as code.
Avoid when
Correctness is a matter of judgment that no rule captures. A human gate or an evaluator fits better there.
Typical failure
The agent holds the tool directly, so a hallucinated parameter is executed without validation.
Also known as
Structured outputs (OpenAI, related)Action-selector pattern (Beurer-Kellner et al., related)
Related patterns
Sources

Space play or pause   → next step   ← previous step  R reset   F failure mode