Models Interpret. Systems Decide.

The fastest way to make an AI demo impressive is to let the model do everything.

The fastest way to make a production system dangerous is often the same thing.

Over the last year I have been building AI-assisted workflows for real operational processes: invoice handling, onboarding, classification, document interpretation, routing and integrations with existing business systems. The more production exposure these systems get, the less interested I become in giving an LLM authority it does not need.

My default rule now is simple:

Models interpret and propose. Systems decide and execute.

That sounds conservative. In practice, it makes AI much more useful.

The model should own ambiguity

Language models are excellent when the input is messy and the answer is not naturally expressed as a deterministic function.

Examples:

• understanding what a document is about,
• extracting meaning from inconsistent text,
• classifying an unusual request,
• proposing a normalized representation,
• generating human-facing language,
• reasoning about several plausible interpretations.

Trying to replace those tasks with hundreds of brittle rules is usually a waste of time.

But once ambiguity has been reduced, the job changes.

A tax identifier either passes validation or it does not. A required field is present or missing. A process can move from state A to state B only when its prerequisites are satisfied. A payment above a threshold requires approval. A webhook has already been processed or it has not.

Those are not language problems.

They are system problems.

InvoiceFlow changed how I think about AI

One of the production systems I work on, InvoiceFlow, handles roughly 10,000 invoices per month.

The important part is not that AI can read an invoice. Many models can do that.

The important part is everything around the model:

1. ingestion and source tracking,
2. extraction,
3. schema validation,
4. deterministic business checks,
5. routing and acceptance rules,
6. human approval where risk requires it,
7. integration with accounting and operational systems,
8. auditability and tests.

The LLM is a component inside the process. It is not the process.

That distinction is why I increasingly dislike the phrase “AI automation” when it implies that an agent should simply be given tools and freedom to figure everything out.

In production, freedom has a cost.

Give every decision an owner

For each step I ask one question:

Who should have authority here?

Sometimes the answer is the model. Sometimes it is a schema. Sometimes it is a database constraint. Sometimes it is a business rule. Sometimes it is a human.

The architecture becomes clearer when you stop asking “Can the LLM do this?” and start asking “Should the LLM be allowed to decide this?”

That shift sounds small, but it changes the whole system.

Instead of one intelligent black box, you get a chain of explicit responsibilities.

MESSY INPUT
    ↓
AI INTERPRETATION
    ↓
STRUCTURED PROPOSAL
    ↓
VALIDATION + POLICY
    ↓
HUMAN GATE (WHEN NEEDED)
    ↓
DETERMINISTIC EXECUTION

Now failures are diagnosable. Decisions can be audited. Models can be swapped. Business rules can change without rewriting prompts. And people can understand why something happened.

Human-in-the-loop is not a failure of automation

There is a strange tendency in AI demos to treat every human checkpoint as evidence that the system is not autonomous enough.

I think that is backwards.

If a decision is rare, high-impact, legally sensitive or expensive to reverse, a human checkpoint can be the most efficient architecture available.

The goal is not maximum autonomy.

The goal is minimum unnecessary human work without losing control of the process.

That is a very different optimization problem.

This also changes product design

Once AI is bounded this way, the user experience changes too.

Instead of asking users to trust a magical agent, you can show:

• what the system understood,
• what it is proposing,
• which rule is blocking execution,
• what requires approval,
• what already happened,
• what can safely happen next.

Trust becomes a product surface, not a paragraph in the documentation.

This is one of the principles I now use across the systems I build at work and in my own experiments.

I am interested in agents, but I am even more interested in systems in which agents can be useful without becoming the source of truth.

That is where I think a large part of serious enterprise AI is heading.