Decisiones impulsadas por el modelo frente a decisiones codificadas

Every agent you build has to make decisions. Who makes them is the design choice.

There are two options:

• Model-driven: Claude looks at the situation and chooses the next step.
• Hard-coded: your code forces the step, no matter what.

The rule for the exam: let the model decide, and reserve hard code for guarantees you cannot afford to get wrong.

Real tasks are open-ended. The order of steps is not known in advance.

A customer message might need one lookup, or three. A research task might branch in ways you cannot predict. Claude reads the live context every turn and adapts.

If you hard-code the path, you freeze the agent into one rigid script. It breaks the moment reality differs from your plan. So the default is: give Claude tools and let it choose.

Here is the model-driven loop. You send the full message history every turn (the model keeps no state). Then you inspect stop_reason:

• tool_use → run the tool, append the result, loop again.
• end_turn → the model is done. Stop.

The model decides what to do; your code just executes and loops.

How do you know the agent is finished? Terminate on stop_reason — never by scanning the text for words like "done" or "finished".

Parsing text for completion signals is a classic anti-pattern. The model might say "I'm done thinking" mid-task, or never say "done" at all. The structured stop_reason is the real, reliable signal.

You may add a maximum number of loop iterations. That is fine — but understand its role.

An iteration cap is a safety net that stops a runaway loop. It is never the primary stop mechanism. The primary stop is always stop_reason == "end_turn".

If your agent normally finishes only by hitting the cap, the decision logic is broken — you are hard-coding what should be model-driven.

Now the other half of the rule. Some outcomes are too important to leave to a probabilistic model.

A prompt is roughly 90% reliable — it usually follows instructions, but not always. For rules with financial, legal, or safety consequences, "usually" is not good enough.

For those, you reserve hard code, which is 100% deterministic. This is the one place where you take the decision away from the model.

The deterministic tool for this is a hook. A hook intercepts an action and can block it before it ever happens — with 100% certainty.

Classic example: "never refund more than $500." You do not write that as a prompt instruction. You write it as an outgoing-call hook that blocks any refund over the limit, every single time.

Hooks for guarantees, prompts for judgment.

The same idea applies to preconditions — things that must be true before an action runs.

Example: never process a refund until the customer's identity is verified. Prompt guidance ("please verify identity first") is only ~90% reliable. A programmatic precondition — block process_refund until get_customer returns a verified ID — is a deterministic guarantee.

Code enforces the precondition; the model still decides everything else.

The mistake in the other direction is just as costly: hard-coding decisions that the model should make.

If you wrap every step in branching if/else logic, you have rebuilt a rigid pipeline and thrown away Claude's adaptability. The agent can no longer handle the unexpected case.

Reserve hard code for the narrow set of guarantees — money, law, safety, required preconditions. Everything else stays model-driven.

Put it together as a division of labor:

• Model decides: which tool to call, in what order, when the task is complete, how to recover from an unexpected result.
• Code guarantees: policy ceilings (refund ≤ $500), required preconditions (verified ID), and the loop terminating on stop_reason.

The model drives the trajectory. Code draws the hard boundaries it can never cross.

One nuance: not every task is open-ended.

• For a known, sequential process, a fixed pipeline (prompt chaining) is fine — the steps really are fixed.
• For an open-ended investigation, use adaptive decomposition and let the model choose its path.

So "let the model decide" applies where the path is genuinely uncertain. Where the sequence is truly known, structure is appropriate — just don't force structure onto problems that need adaptability.

A support agent must never issue a refund above $500. Refunds at or below $500 should be handled smoothly within the conversation. What is the architect-grade design?

Remember the rule: let the model decide; reserve code for guarantees.

• Default to model-driven decisions — Claude adapts to live context.
• Drive the agentic loop and terminate on stop_reason, never by parsing text.
• Iteration caps are a safety net, not the primary stop.
• Use hooks and programmatic preconditions for financial, legal, or safety rules — 100% deterministic vs a prompt's ~90%.
• Don't over-hard-code: guarantees are a narrow boundary, not the whole agent.