The Model Is Not the AI System — What Actually Makes AI Useful

A customer asks a simple question: “Can I make this $120 purchase?”

A language model can understand the request. It can explain credit limits, outstanding balances, and why a transaction might be declined. It might even produce a careful, reassuring answer.

But where does it get the customer's available credit? Who decides which policy applies? And if the response says the transaction succeeded, what proves that anything happened?

These are the questions I wanted to explore after my last fine-tuning tutorial. In that video, I worked through training, evaluation, export, and calling a model from Python. This time, I wanted to look at what surrounds the model when we ask it to participate in a real workflow.

My work on Ohere makes this distinction concrete. Credit operations connect a person's request to changing account information, business rules, permissions, and actual transactions. A fluent answer is one part of that chain.

Four things I want to see in a useful system

The framework I use in the video is Capability × Context × Control × Feedback.

I use the multiplication sign as a teaching device, not a mathematical performance formula. It emphasizes that a serious weakness in one part can undermine the value of the others.

Capability is what the model can do: interpret language, summarize a document, recognize a pattern, or reason through a situation. Better models and well-designed fine-tuning can improve this part.

Context is the information needed for this particular task, at this particular moment. It includes the user's request, relevant records, current state, applicable policies, and the history that changes how the request should be handled.

Control defines what is allowed to happen. It includes exact rules, access permissions, approval requirements, and the software boundaries around actions. A model's recommendation does not grant it permission to act.

Feedback tells us what happened and whether it was useful. It includes execution results, verification, evaluation, operational failures, and human corrections. Some feedback supports an immediate decision. Some becomes evidence for improving the system later.

The engineering work is in connecting these parts and deciding which component has authority over each decision.

▶ Watch this section: capability, context, control and feedback (04:40)

Put the framework inside a $120 question

Imagine Ada has a $500 credit limit and a $220 outstanding balance. In our simplified example, she has $280 available and wants to make a $120 purchase.

Those numbers are easy. Their source is the more interesting question.

If I paste them into a chat, the model can work with them. That demonstrates conditional reasoning over supplied information. It does not demonstrate that the model retrieved an authoritative balance, that the records are current, or that the person asking is allowed to see them.

In the video, I first ask the question in a normal chat interface. The model can discuss the conditions under which a purchase would be possible, but Ada's private account state is missing. When I supply context, the response becomes more specific.

That change is useful to observe. The model did not need to learn Ada's balance during training. It needed the relevant information at runtime.

Training can shape behavior. A live account balance belongs in a system that can retrieve and maintain current records.

All customer and account examples here are synthetic. The code in the video is simplified teaching logic, not Ohere's production authorization, risk, credit-decision, payment, or ledger logic.

Draw the deterministic boundary

Even with the account information present, I still need to decide where the model's judgment ends.

For a rule that requires an exact answer, I want explicit software to apply it. If our teaching policy requires an active account, an active card, and sufficient available credit, the decision should come from those defined checks.

The model can help interpret what Ada wants and explain the result. The application should enforce the relevant rule and permission boundary.

This also makes failures easier to inspect. If a transaction is rejected, I can identify which check rejected it. I can test a disabled card, an inactive account, and an amount that exceeds the available credit. I am no longer relying on whether a generated paragraph sounds reasonable.

The demonstration keeps this deliberately small. A production system would need more: concurrency handling, authoritative transaction state, appropriate security, and the full set of domain-specific requirements. The point of the example is to make the division of responsibility visible.

A decision is not an execution record

There are at least three different claims hidden inside “the AI handled it.”

First, the system determined that an action was allowed. Second, an authorized service attempted or completed the action. Third, the system checked the resulting state.

Those claims need different evidence.

An allowed decision does not prove that the execution service ran. A response from that service may need reconciliation with an authoritative record. A generated sentence saying “completed” proves only that the sentence was produced.

In the Python demonstration, I separate decision logic from synthetic execution and verification. The execution trace makes the distinction inspectable: we can look for an identifier, inspect what the service recorded, and check the expected outcome.

This is the practical meaning of the line I return to in the video: language is not proof.

▶ Watch the demonstration: exact decision logic in code (16:19)

The customer-facing response should reflect what the system can support. If execution is pending, say it is pending. If verification failed, that uncertainty belongs in the result rather than disappearing behind confident prose.

The same words can describe different operational states

Consider another customer message: “I have repaid. Can my credit limit increase?”

The wording alone does not settle the question. Was a repayment initiated, received, or reconciled? Is the account eligible under the relevant policy? Is there a review or approval step?

The same sentence can require different actions depending on those answers.

This is why I think domain knowledge and operational state deserve as much attention as model selection. Knowing what a repayment means in the business includes knowing the sequence of events and which records establish that it happened.

The pattern extends beyond credit

In settlement operations, an analyst might ask why the processor's total differs from the ledger. A model can help organize the investigation, but it needs the relevant records, reconciliation rules, and tools. The conclusion needs evidence that explains the difference.

In marketing, a model can draft a campaign. Sending it introduces different responsibilities: audience selection, consent, budget limits, approvals, and confirmation that the campaign actually ran. Feedback then helps the team judge the outcome.

These workflows look different on the surface. Each combines model capability with business context, controlled actions, and evidence about the result.

What should the organization own?

Model providers may change. The knowledge of how a business operates should remain usable across those changes.

That includes its policies, workflows, tool contracts, evaluation cases, decision history, and feedback. These are the assets that help a team define correct behavior and recognize when a system is failing.

I think of this as the domain intelligence layer: the organized knowledge and operational structure that let model capability participate in useful work.

It also changes the starting question. Alongside “Which model should we use?”, ask: What does this workflow need to know? Who has authority to act? What evidence will establish success? How will we detect and learn from failure?

Pick one workflow and answer those questions before adding more components. A small system with visible responsibilities gives you something you can test and improve.

The next step in the series is to turn that architecture into a build, starting with a naked-model baseline and an explicit evaluation rubric.

If you are building something similar, which part is hardest to make reliable in your own workflow: current context, control, execution, verification, or feedback?