Consider a column containing 150 rows of messy free text. The obvious AI implementation is to send the rows to a model and ask it to normalize them.

The unit of judgment is the phrase. In one workflow, those 150 rows collapsed into a few hundred distinct phrases. Many could be handled mechanically. Only the ambiguous phrases required interpretation.

So the model operated on the phrase vocabulary, while a deterministic mapper independently checked the result.

The interesting optimization was shrinking the place where the prompt was needed.

That distinction matters. A workflow may contain thousands of tokens while only a few hundred tokens contain genuine uncertainty.

A document may be fifty pages long while one paragraph contains the decision.

A process may have twenty steps while three require judgment. Treating the entire workflow as an AI problem spreads probabilistic behavior across areas that never needed to be probabilistic.

The most important AI product decision is where the model stops. Better models create a predictable temptation: give the model more of the workflow.

More context. More tools. More autonomy. More decisions. That is often backwards. A useful AI system is defined by how precisely we can identify the part of the work that actually requires a model.

Call that the AI surface. The AI surface is the portion of a product where the answer cannot be computed, the path cannot be completely specified in advance, or reasonable people could look at the same evidence and reach different conclusions.

Everything outside that surface deserves suspicion. If a date can be calculated, calculate it. If a schema can be checked, check it. If a sequence can be encoded, encode it. If a human is the one who defines what "good" means, do not let the model quietly invent the standard.

Models are useful precisely because some problems resist deterministic rules.

Deterministic problems stay with deterministic rules.

Computable uncertainty is usually self-inflicted

One of my systems ran a scheduled review at 2:00 AM. The model was asked to inspect activity from "today." It occasionally interpreted the window incorrectly and reported a quiet night.

Nothing about this required intelligence. The scheduler already knew the time. So the scheduler now computes the window and gives the result to the model.

That is a tiny architectural change, but it reflects a larger rule: Never spend model uncertainty on something the system can know. The same applies to output structure. A model can write a report. Code can verify whether the report contains the required sections. A model can produce a classification. Code can verify whether the value belongs to the allowed set. A model can reason about evidence. Code can verify whether the cited URL, date, identifier, or hash actually exists.

The model handles the part where multiple answers are possible. The surrounding system handles the parts where they are not.

Autonomy is also a surface

The same principle applies to agents. An agent is useful when the path through the work cannot be known ahead of time.

If the sequence is already known, an agent may be an expensive way to implement a state machine.

In one prototype, code decides which step is ready, passed, or locked. The model performs the work that requires interpretation, but it cannot declare its own step complete.

This is an argument for putting agency where branching is real. A goal without boundaries gives the model a larger search space. A useful agent usually has at least three things: goal, scope, done. Increasingly, the answer to "Can an agent do this?" will be yes. The better question is: Which part benefits from not knowing the path in advance?

Human oversight has a surface too

"Human in the loop" sounds reassuring until the loop contains 400 decisions.

If the expert can inspect only 40, then human oversight becomes an allocation problem.

Which 40? A common answer is model confidence. Review the decisions where the model appears least sure.

That is convenient because confidence is already available. It is not necessarily where human attention creates the most value. In one small review-budget experiment, allocating 40 reviews based on the cost of being wrong prevented 48% of potential damage. A fixed confidence policy prevented 17%.

Same model. Same number of human reviews. Different allocation of attention. The important variable was where the human surface was placed. This changes how I think about human review. The person should appear at the consequential boundaries instead of being distributed evenly across an AI system.

Where money moves. Where trust can be damaged. Where taste defines the standard. Where evidence runs out.

The product should stop where the evidence stops

This may be the hardest boundary. AI makes it cheap to extend a prototype beyond what its builder actually knows.

A system that can summarize bid documents can probably generate pricing recommendations.

A system that can classify a request can probably issue a final verdict.

A system that can produce a draft can probably press Send. Capability makes the next step look deceptively close. But product scope and model capability are different things. One bid workflow I built deliberately stops general triage where pricing begins because my evidence becomes discipline-specific at that point.

Another system can send an opportunity to REVIEW, but cannot independently declare NO.

These are product boundaries. A narrower claim that can be tested is more useful than a broader claim that cannot.

This suggests another way to think about AI product scope: Ask how far the evidence lets the product reach.

Reliability improves the same way

When AI systems fail, the instinct is often to improve the prompt. Sometimes that is the right layer. Often it is not. A failure may belong in code. It may belong in retrieved knowledge. It may belong in the evaluation harness. It may be stale source data. It may be an environment problem that has nothing to do with the model.

One replay test made this painfully clear. A learned rule told a review system to check a manufacturer's datasheet before making a decision.

The rule transferred correctly. The decision still failed. A coded gate enforcing the check also failed. The missing piece was the sourced value from the datasheet itself. Once that fact was present, the decision changed. The rule and the gate each operated outside the layer that contained the missing information.

This is why reliable AI systems need more than better prompts. They need clear ownership of uncertainty.

Shrink the jurisdiction

A useful design review for an AI product might therefore ask something like:

What can be computed? → code What requires interpretation? → model Where is the path genuinely unknown? → agent Where does being wrong become expensive? → human What fact does the decision depend on? → evidence Where does our ability to verify the system end? → product boundary

It concentrates AI. And concentration matters because every probabilistic decision introduces something the system now has to observe, evaluate, review, recover from, or explain.

As models improve, the AI surface will expand. Some boundaries that require humans today will disappear. Some workflows that require agents today will become ordinary software patterns.

Some tasks that are currently unreliable will become routine. But the design question remains the same. Where does intelligence actually need to exist? The strongest AI products may be the ones that know exactly where to stop.