Детерминированное принудительное выполнение и запросы

When you need an agent to always follow a rule, you have two fundamentally different tools.

• Prompts ask the model to behave a certain way. The model usually complies — but it's still a probabilistic system making a judgment call.
• Hooks are deterministic code that runs around tool calls. They don't ask — they enforce.

This lesson teaches the single most important number in workflow enforcement: a well-written prompt gives you roughly ~90% compliance; a hook gives you 100%.

A system prompt is guidance. Even an excellent one — explicit criteria, few-shot examples — steers the model toward the right behavior but never guarantees it.

Across thousands of requests, that residual ~10% surfaces: an edge case, an unusual phrasing, a long context where the rule sits in the lost-in-the-middle zone. The model generalizes from your instructions, which is exactly why it can also generalize wrong.

For most behaviors that's fine. For rules where a single violation is unacceptable, ~90% is a liability.

A hook is ordinary code wired into the agent lifecycle. It runs every time, evaluates a condition the same way every time, and its decision does not depend on model reasoning.

• PostToolUse hooks intercept a tool's result before the model ever sees it.
• Outgoing-call hooks block policy-violating actions before they execute.

Because the logic is hard-coded, the guarantee is absolute: 100% deterministic enforcement. A blocked action is blocked — no matter what the model decides.

Here is the rule to memorize for the exam and for real architecture:

Use hooks when failure has financial, legal, or safety consequences.

If a single violation costs money, breaks the law, or endangers someone, ~90% is not acceptable — you need 100%. That is a hook's job. Prompts are for guidance, tone, preference, and the countless soft behaviors where an occasional miss is recoverable.

Don't enforce a critical business rule with prompts alone. That is one of the most common wrong answers on scenario questions.

The same deterministic principle applies to preconditions — rules about what must happen before an action is allowed.

Example from the Customer Support scenario: never run process_refund until get_customer has returned a verified customer ID. You could write that as a prompt instruction... or you could enforce it in code so it physically cannot be skipped.

A programmatic precondition gives a deterministic guarantee that prompt guidance cannot. The identity check happens 100% of the time, not 90%.

A tempting trap: "I'll write a really strong prompt — all caps, repeated three times, with examples." This improves compliance, but it does not change the category. You are still on the probabilistic side of the line.

Few-shot examples and explicit criteria are powerful — they raise quality, reduce hallucination, and lock in output format. But they raise the ceiling of ~90%; they never reach the deterministic 100% that financial, legal, and safety rules demand.

If the requirement is a guarantee, no amount of prompt engineering substitutes for code.

Important balance: hooks are not a license to hard-code everything. The agentic loop is model-driven — the model decides which tools to call and when, based on stop reasons.

You reserve hard code for guarantees, not for routine decision-making. Think of it as a thin, deterministic safety boundary around an intelligent, flexible core.

The same wisdom appears with iteration caps: a cap is a safety net, never the primary stop mechanism. Terminate on stop_reason, and use deterministic code only where a hard guarantee is genuinely required.

A PostToolUse hook intercepts a tool result before the model sees it. This is more than blocking — it's a deterministic checkpoint on data flowing back into the conversation.

Use it to enforce things like: redact secrets from output, validate that a required field is present, or refuse to surface a result that violates policy. Because it runs deterministically on every result, the model never even gets a chance to mishandle data you've decided it must not see raw.

The mirror image of PostToolUse is the outgoing-call hook: it sits between the model's decision to act and the action actually firing.

This is where you block policy-violating actions — the refund over $500, the email to an unapproved domain, the deletion of a protected resource. The model may request the action; the hook decides whether it executes.

This separation is the architecture: the model proposes, deterministic code disposes — but only for the small set of rules that truly require a guarantee.

Exam scenarios telegraph the answer with their wording. Train yourself to spot it:

• Words like "must never," "financial," "compliance," "safety," "regulatory," or a hard dollar threshold → the answer involves a hook / deterministic enforcement.
• Words like "prefer," "tone," "style," "usually," "when appropriate" → a prompt is fine.

If an option proposes enforcing a hard, costly rule with "a stronger system prompt," it is almost certainly a distractor.

The strongest designs use both. The prompt makes the model want to do the right thing 90% of the time — fewer blocked attempts, smoother conversations, better UX. The hook catches the remaining 10% with a hard guarantee.

Prompt for good default behavior; hook for the non-negotiable boundary. You get a system that is both intelligent and provably safe — guidance for the common case, deterministic enforcement for the catastrophic one.

Apply the decision rule to a real scenario.

Key takeaways:

• Prompts are ~90% probabilistic guidance; hooks are 100% deterministic enforcement.
• Use hooks when failure has financial, legal, or safety consequences; use prompts for tone, preference, and soft behavior.
• PostToolUse hooks guard results before the model sees them; outgoing-call hooks block policy-violating actions before they fire.
• Programmatic preconditions (block a refund until identity is verified) give guarantees prompts cannot.
• Reserve hard code for guarantees — keep the loop model-driven, and combine a good prompt (default behavior) with a hook (hard boundary).
• Distrust any answer that enforces a critical, costly rule with "a stronger prompt" alone.