Reason Where You Must. Execute Deterministically Where You Can.

I already argued that AI versus rules is the wrong fight. The next mistake is softer—and more common. Teams agree, in principle, that some steps need judgment and some steps should be software. Then they still design as if the whole workflow were one mechanism. They wrap a known check in a model “for flexibility.”

They freeze an ambiguous exception class into a brittle table “for control.” They leave human authority implicit until an incident forces a postmortem. I am not anti-AI.

I am not anti-automation. I am against mis-placement.

The operating rule is blunt:

Reason where you must. Execute deterministically where you can.

Keep the boundary explicit. Keep it owned. Keep it reversible when the world moves.

Placement is the design, not the slogan

Least AI said: use probabilistic intelligence where uncertainty requires reasoning, and deterministic mechanisms where the answer is already sufficiently known. The false-binary piece said: different portions of the same workflow have different uncertainty profiles, so architecture should place mechanisms by decision type—and promote or demote as evidence changes. This piece is about doing the placement without joining either camp. Placement means, for each consequential step, answering four questions before you pick a tool:

1. What does this step decide or enforce? 2. How much uncertainty remains in the inputs, evidence, or policy? 3. Who or what has authority to act—and under what envelope? 4. What signal would invalidate that authority?

If you cannot answer those, you are not choosing AI or rules. You are guessing which brand of failure you prefer. A schema check with a known contract does not need a model. A contested exception with incomplete evidence does not need a confident rule pretending the contest is over.

A high-consequence action may need a human gate even when a model sounds sure. Those are different placements inside one unit of work. Treating them as one ideology is how programs oscillate between “AI everywhere” and “automate everything,” and end up trustworthy at neither.

Deterministic where you can is not anti-AI

I want lint, tests, permission checks, arithmetic, mandatory scans, and stable postconditions to be unavoidable. Not because models are bad. Because known constraints should become software. If every production deployment must pass a security scan, I do not want an agent deciding whether this particular change probably deserves one.

I want the pipeline to make the scan non-optional. If a claim total must equal the sum of its line items, I want arithmetic—not a second model “validating” the first. If a BPM path already encodes a stable approval sequence with clear ownership, I do not want that sequence rediscovered in chat every Tuesday. None of that is an argument against generative systems.

It is an argument for giving reasoning a clean envelope so the uncertain work can stay uncertain without inventing fake certainty around it. The anti-AI camp hears “deterministic gates” and cheers for abolition. That is not the claim. The claim is narrower: do not spend scarce judgment on what the organization already knows how to check.

Reason where you must is not anti-automation

Ambiguous intake, conflicting evidence, novel exceptions, and contested judgment are exactly where probabilistic reasoning helps—if the outcome remains recoverable. A denial packet with missing clinical context still needs investigation. A production incident with incomplete telemetry still needs diagnosis. A policy change that does not map cleanly to yesterday’s decision table still needs human-owned interpretation.

Automation camps sometimes treat those cases as temporary defects in the rules estate. Sometimes they are. Often they are the frontier: work the organization does not yet understand well enough to execute under a tight contract. Forcing that work onto a deterministic path early does not create maturity.

It creates confident wrongness with a ticket queue attached. Reasoning belongs there—not as theater, and not as a permanent tax on every familiar case either.

The same workflow, typed by uncertainty

Inside one workflow, uncertainty is uneven. Intake may be messy. Reasoning helps assemble and interpret incomplete packets.

Validation may already be sharp. Deterministic checks should fire without negotiation.

Judgment may be genuinely contested. Human accountability stays. Action may be permitted only after both a known gate and an owned decision. Learning may show that a once-novel family of cases has become boring under stable conditions.

Promotion should be possible. Invalidation may show that yesterday’s boredom was conditional. Demotion should be possible too. This typing can sit above or beside the CI gates, runbooks, CAB/RFC paths, rules engines, BPM paths, and reasoning tools you already run.

It does not require a greenfield hybrid platform. It does require refusing to treat “the workflow” as a single loyalty test for AI or automation vendors. I have seen architecture reviews where the only question was whether the team was “going agentic” or “staying with rules.” That is procurement theater dressed as design. The useful review asks which steps are known, which are uncertain, which remain human-owned, and how movement between those buckets is approved.

Coexist first with what already works

Serious organizations already have deterministic machinery. CI/CD gates. Schema and contract tests. Rules engines. BPM case paths. Runbooks. Change boards. Permission systems.

Audit logs. Hybrid placement should start by telling the truth about those assets—not by implying they are obsolete because a model can approximate them. If a gate already enforces a known postcondition, keep it.

If a model is being asked to re-derive that postcondition for aesthetics, remove the model from that step. If a BPM path already owns a stable routing sequence, do not launder the same sequence into an unowned chat plan. If a rules estate covers a bounded family well, do not demote it to “legacy” merely because an AI program needs a narrative.

Coexistence is not nostalgia. It is how you avoid paying twice for the same certainty—once in software you trust, and again in probabilistic rediscovery that pretends the software never existed.

Promotion and demotion keep placement honest

A static split—“these steps are AI, those steps are rules”—ages badly. Useful systems need motion in both directions. Promotion is the governed path from repeated successful reasoning to deterministic capability. It is not “the model got lucky three times.”

It is an organizational decision with evidence: validated outcomes, similarity bounds, exclusions, invalidation signals, and named approvers. Without those, “we automated it” is tribal habit with a new label. Demotion is the reverse motion: suspend or narrow a governed path when invalidation signals appear, return affected cases to reasoning or human judgment, and rebuild only after new evidence earns trust.

A payer changes documentation requirements. A jurisdiction adopts a new code.

A vendor changes an API. A workload changes shape. If deterministic automation has no path back to investigation, the organization has not gained maturity.

It has gained confident wrongness. I am not claiming a formula for when promotion is ready.

Volume alone is not enough. Quiet quarters hide fragile assumptions. I am claiming that without owned promotion and demotion, placement freezes into another form of process debt—either forever-expensive rediscovery, or forever-brittle rules.

Score the placement, not the camp

A practical Monday test for a consequential workflow:

1. Which steps are already known well enough to execute deterministically—under gates you already trust? 2. Which steps still contain uncertainty that requires reasoning? 3. Which decisions must remain human-owned regardless of model quality? 4. What evidence would justify promoting a repeated reasoning pattern into a governed path? 5. What signals would force demotion of a path that used to be safe? 6. If the chat history disappeared tomorrow, would those answers still be recoverable from owned artifacts?

Those questions do not require a product category name. They do require a design discipline: type steps by uncertainty, place mechanisms accordingly, coexist with the deterministic estate you already have, and keep the frontier movable as experience accumulates. For transformation offices, the scorecard implication is the same shape. Stop asking teams to pick AI or automation as a loyalty identity.

Ask them to show known / uncertain / human-owned placement—and the promotion/demotion ownership that keeps that map honest.

Neither camp gets the last word

AI is valuable because some work does not fit neatly into rigid software. Deterministic execution is valuable because some work does. The organization that reasons where it must—and executes deterministically where it can—stops spending energy on camps. It spends energy on finishing work well, under authority that can still change when reality does.

That is not a call to eliminate intelligence. It is not a call to freeze the enterprise into permanent procedures. It is a call to place both honestly inside the same unit of work. The next question is temporal, not tribal: if placement is right today, what does maturity look like over time—and why should a valuable AI workflow often need less probabilistic AI as familiar cases earn governed certainty?