The Principle of Least AI

Put intelligence where uncertainty creates value.

One pattern I keep seeing in AI architecture is surprisingly simple: we use AI because we can. A model can classify the request, so we let it. It can decide where the request should be routed, so we let it. It can validate the response, so we ask another model to do that too.

Soon a workflow that could have contained three deterministic operations and one genuinely difficult reasoning step contains twelve model calls. It looks sophisticated. It may even work. But sophistication is not the same thing as good architecture.

I have started using a simple principle when thinking about these systems:

Use the least AI necessary to solve the problem well.

I call it the Principle of Least AI. That phrase is easy to misread. It is not an argument against AI. It is not a mandate to minimize model spend at the expense of quality.

It is an argument for putting intelligence where intelligence creates value—and for refusing to spend scarce reasoning capacity on work the organization already understands.

Non-determinism is a capability—and a cost

Generative AI is powerful partly because it can operate where traditional software struggles. Give ordinary code an ambiguous requirement and it fails. Give a capable model the same requirement and it may infer intent, gather context, propose alternatives, and produce a useful result. That is exactly why AI is transformative. But that flexibility comes with properties we should not pretend away.

Model outputs are probabilistic. They can vary. They require context. They add latency and cost. They can misunderstand ambiguous evidence.

Their rationale may sound more certain than the evidence warrants. That trade is often worthwhile when the task genuinely requires interpretation. It is a strange trade to make when it doesn't.

Consider schema validation. If a field must contain a valid date, I don't want an intelligent agent to “reason” about whether the value feels like a date.

I want a deterministic validator. If a claim total must equal the sum of its line items, I don't want a model evaluating the arithmetic. I want arithmetic. If every production deployment must pass a security scan, I don't want an AI agent deciding whether this particular deployment probably deserves one.

I want the pipeline to make the scan unavoidable. Known constraints should become software. Intelligence should handle the uncertainty left over. The same pattern shows up outside pure engineering.

A claims team that re-investigates every denial from first principles may look thorough. A manufacturing line that asks a model to re-derive a stable quality gate on every unit may look advanced. In both cases, repeated inference without retained learning is operating cost that never becomes operating leverage.

The strongest AI systems need strong deterministic boundaries

This becomes more important as agents become more capable. When an AI assistant suggests a paragraph, the consequences of variability are limited. When an agent can modify source code, execute commands, submit a claim, communicate with a customer, change infrastructure, or trigger another agent, the cost of an incorrect inference grows significantly. At that point, prompting alone is not governance.

I want the non-deterministic parts of the system surrounded by extremely deterministic mechanisms: contracts, schemas, permissions, tests, architectural boundaries, policy enforcement, observable state transitions, human gates where the consequence warrants one, and rollback mechanisms.

The objective is not to eliminate agent autonomy. The objective is to give autonomy a safe operating envelope. This is the same principle we apply to good organizations. We don't make experienced employees ask for permission before every minor decision.

We give them clear responsibility, clear boundaries, the information they need, and escalation paths for situations outside their authority. Agentic systems need the same maturity.

There are really three kinds of work

The Principle of Least AI becomes easier to apply if we stop treating an entire workflow as either “AI-powered” or “automated.” A workflow usually contains at least three categories of activity.

### Work that should already be deterministic

These are problems for which we know the answer. Validation is a common example. So are known calculations, explicit mappings, permission checks, transformations, and stable routing rules. Using generative reasoning here usually adds uncertainty without adding useful intelligence.

### Work that actually requires reasoning

This is where AI shines. Interpret an ambiguous customer request. Investigate several conflicting pieces of evidence.

Diagnose a failure with incomplete information. Compare architectural alternatives. Determine what documentation is missing from a complicated case.

Generate hypotheses. Synthesize an argument. These problems contain uncertainty that cannot simply be coded away.

### Work that is uncertain today but may become deterministic tomorrow

This third category is the most interesting. Suppose an agent repeatedly encounters the same family of problem. At first, it has to investigate.

It gathers evidence. It reasons through possibilities.

It chooses an action. Humans review the result. The organization observes what happened. Then another similar case arrives. And another.

At some point, we should ask a question that is strangely absent from many AI architectures:

Have we learned enough that this decision no longer requires the same amount of reasoning?

If a bounded family of cases keeps producing the same validated conclusion under the same conditions, asking an expensive generative model to rediscover that conclusion forever may not be intelligence. It may simply be waste.

Good AI workflows should often use less AI as they mature

This is the implication I find especially important. Many AI product roadmaps I see assume that maturity means adding more intelligence. More agents.

More reasoning. More autonomy.

More model calls. I think mature systems should often move in the opposite direction. Early in a new process, we need exploration.

We don't fully understand the problem yet. Agents investigate.

Humans correct them. Exceptions appear. Patterns emerge. But once the organization genuinely understands a bounded part of the problem, the result of that learning should be made explicit.

Perhaps the stable result becomes a rule. Perhaps it becomes a validation check.

A decision table. A parameterized query. A reusable transformation. A standard tool sequence. A workflow fragment.

None of this is brand new. Rules engines, progressive automation, and graduating learned patterns into governed procedures have been part of serious operations for a long time. What is new is how often agentic systems rediscover the same answer without ever capturing that learning as durable capability. The exact implementation is less important than the underlying principle:

Stop paying for probabilistic reasoning when experience has already earned sufficient certainty. Then preserve the reasoning capability for everything that remains uncertain. That is what an intelligent system should do.

Recognizing when reasoning can become capability

The hard part is not agreeing with the thesis. The hard part is recognizing, honestly, when a once-agentic decision is ready to become deterministic—and when it is not. I do not think there is a universal formula for that judgment.

Volume alone is not enough. A large pile of similar-looking successes can still hide fragile assumptions. Before promoting repeated reasoning into a governed deterministic mechanism, I want the organization to be able to answer questions like these:

• Evidence: What outcomes, reviews, or checks actually validated the pattern—not just that it ran often?
• Similarity bounds: Under what input conditions does the pattern apply? What variations are still “the same problem”?
• Exclusions: Which cases must remain on a reasoning path even when they look adjacent?
• Invalidation signals: What policy change, error rate, upstream dependency shift, or human override should reopen the question?
• Review authority: Who is accountable for approving the promotion, and who can force demotion when those signals appear?

Those dimensions do not solve recognition by themselves. They make recognition an explicit organizational decision instead of an accidental side effect of another model call. Ownership matters here. In practice, the people closest to the workflow should propose promotion or demotion. Architecture or engineering standards should review the boundary.

Operators and domain experts closest to outcomes should be able to raise invalidation signals without waiting for a roadmap cycle. If nobody owns those decisions, the maturity loop is only a slogan.

Deterministic does not mean permanent

There is an obvious danger here. Today's correct rule can become tomorrow's legacy defect. A payer changes its policy.

A jurisdiction adopts a new building code. A vendor changes an API.

A workload changes shape. A new regulatory requirement appears. A business objective changes. If we turn learned behavior into deterministic automation and then forget why the rule exists, we have simply created another form of technical debt.

I have seen the premature version of this. A team promotes a “stable” denial-routing rule after a quiet quarter. Then the payer changes documentation requirements.

The rule still fires confidently. Exceptions pile up in a queue nobody designed for demotion. Recovery means treating the rule as suspect again: suspend it, return those cases to investigation, and rebuild only after the new evidence earns trust.

So every learned mechanism needs an answer to another question:

What would have to change before we should stop trusting this?

That means the deterministic side of the system cannot simply contain rules. It needs context. What evidence supported the rule? What assumptions were true when it was validated?

Where does it apply? What cases were excluded? What outcomes demonstrated that it worked?

What signals should cause us to reconsider it? A mature automation system needs a path in both directions. Reasoning can become deterministic when experience warrants it.

Deterministic behavior can become a reasoning problem again when reality changes.

This is not about minimizing AI usage

The phrase “Least AI” can sound like the goal is reducing model usage. It isn't. The goal is maximizing the value of intelligence. If a problem is novel, ambiguous, high-impact, contested, or poorly understood, I want the system to use every appropriate reasoning capability available.

Retrieve evidence. Ask another specialist. Simulate alternatives. Challenge the first answer. Escalate to a human.

Take more time. AI is valuable precisely because these problems don't fit neatly into rigid software. But that is also why we shouldn't waste AI on the parts that do.

The best architecture places non-determinism exactly where uncertainty exists and uses deterministic systems to constrain, validate, and operationalize the result.

Intelligence should leave something behind

There is a final test I increasingly use when evaluating an agentic workflow. Imagine the system solves the same bounded problem correctly many times. What has the organization learned? If the next execution still starts from essentially the same blank slate, retrieves the same evidence, performs the same reasoning, incurs the same inference cost, and arrives at the same decision...

...then the workflow has accumulated history. But it hasn't necessarily accumulated intelligence.

The most valuable AI systems won't simply perform intelligent work. They will turn repeated intelligent work into organizational capability. And if we take that idea seriously, a mature AI workflow may have an unexpected characteristic: The better it gets at solving a familiar problem, the less AI that familiar part of the problem should require.