AI decision architecture

For founders, operators and technical teams deciding what part of a workflow should be deterministic, probabilistic, generative or explicitly human.

Give each decision to the simplest kind of intelligence that can handle it reliably.

Finding something that could use AI is easy. The harder decision is what kind of intelligence the workflow actually needs. Some problems belong in ordinary code. Some require judgment without generation. Some need an LLM. And some should stop and ask a person. The Intelligence Stack separates those layers before the model choice starts.

Start with the decision

Choose the mechanism after you understand the shape of the problem.

AI projects often start with “can we use an LLM here?” That question comes too early. First identify what the system is being asked to decide, what information it can use, whether the answer space is fixed and what happens when the system is uncertain.

One workflow can contain several kinds of intelligence. A lead process might use code for hard eligibility, a decision model for fit, an LLM for account research and a person for high-value ambiguous cases.

Known logic

If the answer can be derived exactly from rules or data, keep it deterministic.

Bounded uncertainty

If interpretation is required but the possible outputs are known, use a classifier or decision model.

Open-ended reasoning

If the system must discover, synthesize or create the answer, use an LLM or agent.

Consequential uncertainty

If confidence remains weak and the cost of error is meaningful, route to a human.

Layer 1 — code

Deterministic work should stay deterministic.

Calculations, permissions, required-field checks, dates, state transitions, hard qualification criteria and explicit thresholds do not become better because a model touches them.

Code is fast, cheap, testable and predictable. A useful AI workflow assessment often removes model calls by recognizing decisions that were never probabilistic problems.

Calculate

Use code when the answer follows directly from known inputs and rules.

Validate

Required fields, permissions and policy checks should not depend on model judgment.

Transition

Known workflow states and explicit stop conditions belong in software.

Measure

Deterministic steps make the rest of the system easier to test and observe.

Layer 2 — bounded judgment

Semantic judgment does not always require language generation.

Some decisions are not exact, but the answer space is already known: pursue, review or reject; sales, support or billing; low, medium or high risk. The system needs interpretation, not prose.

This middle layer can include traditional classifiers, embedding similarity, rerankers, scoring models or newer decision-focused models such as TypeSafe Jev. The product matters less than recognizing the category.

Classify

Map ambiguous input into a known set of categories.

Score

Estimate fit, urgency, quality or risk on a bounded scale.

Route

Choose among known agents, teams or workflow branches.

Escalate

Use confidence to decide whether the system can act or needs another layer.

Layer 3 — generative reasoning

Use LLMs where the answer has to be discovered, synthesized or created.

Research, explanation, comparison, drafting and strategy are genuinely open-ended. The system cannot enumerate every valid answer before the task begins.

This is where generative models earn their complexity. The mistake is using the same mechanism for a decision whose downstream result is only one enum, score or category.

Research

Gather and interpret information across sources when the answer is not already known.

Synthesize

Combine conflicting or scattered context into a useful conclusion.

Generate

Create messages, plans, summaries or other open-form outputs.

Investigate

Reason through unusual cases that do not fit a stable decision boundary.

Layer 4 — human review

A reliable system routes uncertainty instead of hiding it.

Human review belongs where evidence conflicts, confidence is weak, consequences are significant or policy requires accountable approval.

Escalation is not failed automation. It is a control boundary. A mature system knows which decisions it is allowed to make and when to stop.

Confidence

Low-confidence predictions should trigger a different path than clear decisions.

Consequence

The higher the cost of error, the stronger the review boundary should be.

Conflict

Contradictory evidence should remain visible rather than being flattened into false certainty.

Authority

Keep model permissions bounded to the actions the workflow genuinely needs.

Confidence is control flow

The answer and the certainty should both affect what happens next.

A decision model returning 95% confidence and one returning 48% confidence should not drive the same behavior. High confidence may allow automatic action. Medium confidence may trigger enrichment or a stronger model. Low confidence may require review.

That turns uncertainty into explicit workflow state instead of burying it inside a prompt or model response.

High confidence

Act automatically when the decision is well inside the approved boundary.

Medium confidence

Gather more evidence or escalate to a more capable reasoning layer.

Low confidence

Pause, defer or route to a person.

Observe

Track overrides, disagreements and outcomes so thresholds can be improved with evidence.

Use the stack in an assessment

An AI opportunity assessment should determine the intelligence layer before it chooses the tool.

For each workflow, define the operating problem, the decision, the available state, the answer space, the consequence of failure and the escalation path. Only then choose code, a classifier, a decision model, an LLM or a human checkpoint.

The goal is not to maximize AI usage. It is to use the simplest reliable mechanism at each step and spend generative reasoning only where the workflow actually benefits from it.