A friend told me he had been using ChatGPT to learn Morse code and had noticed mistakes when it checked his answers. That struck me as a useful software-design example. Morse has a fixed reference: if an application needs to check whether S is ..., it can look that up directly.

A language model can still explain the result, suggest exercises and respond to the learner. But it does not need to be responsible for the exact check. Tested software can handle the fixed mapping, while the model handles the part that benefits from language and interpretation.

That small distinction becomes much more useful in a business workflow. Some tasks involve exact records, calculations or rules. Others require understanding what a customer means. And some require human judgement. The interesting design question is not how much of the workflow a model can do, but which part it should do.

Different kinds of work in one application

A lookup table, a calculation or a rule for checking required fields can be handled by deterministic software. For the same inputs, it follows defined rules and produces the same result. Here I mean software whose rules and implementation have also been tested. Repeatability alone would not make a wrong rule correct.

A language model is useful for a different kind of work. It can handle varied wording, connect information expressed in different ways and help interpret a request without requiring a separate hand-written rule for every possible phrasing. That flexibility is valuable, but it also means the interpretation can be wrong.

Human judgement enters where the task requires experience, responsibility or a decision that cannot be reduced to a simple check. In a business workflow, that may mean deciding whether a proposed solution actually fits the customer’s application.

These roles can exist in the same application. Software can retrieve records, calculate values and enforce permissions. A model can interpret the customer’s wording and prepare a structured brief. A person can review the result, resolve uncertainty and approve actions that carry technical or commercial consequences.

The useful question is not which of these should replace the others. It is where each one gives the application the strongest result.

One inquiry, shared responsibilities

Consider this illustrative industrial sales inquiry:

We are planning a new line and need something for handling pallets after packing. Can you advise?

Suppose the message is already linked to a confirmed customer record. Software can retrieve the assigned salesperson, selected project fields and other relevant information without asking a model to search through the entire customer database.

The model can then work on the part that benefits from interpretation. It might identify pallet handling after packing as the likely application, prepare a short brief and suggest questions about the load, layout and required throughput. It should keep what the customer actually said separate from what it inferred.

For example:

• Stated in the inquiry: the customer is planning a new line and asks about handling pallets after packing.
• Possible interpretation: the request concerns moving pallets at the end of the packing process. Confirm the intended operation.
• Question to resolve: what is the maximum loaded pallet weight? It is not stated in this message; check existing project information before asking again.

At this point, the model has helped structure an ambiguous message, but it has not established a technical solution.

If the workflow later suggests a product, software can check whether the product code exists in the current catalogue. That is a different task from deciding whether the product is suitable for the application. A valid catalogue record confirms that the product exists. It does not confirm that it meets the customer’s load, layout, environmental or performance requirements.

The colleague reviewing the case should therefore receive the brief together with its sources, open questions and any checks already performed. Sending a technical recommendation or changing an approved record can require a separate approval step enforced by the application.

This is the division of work in practice: the model helps interpret the request, software supplies and checks exact information, and a person assesses the recommendation and unresolved assumptions.

Prepare the information before asking the model

Once the model’s role is defined, conventional software can prepare the information it actually needs.

If a customer message is already linked to a known account or project, the application does not need to pass the entire CRM history to the model. It can retrieve the relevant records, select specific fields, remove duplicates and calculate values before the model sees anything.

The same applies to other sources. A defined query can return the current catalogue entries relevant to the case. Existing software can supply confirmed identifiers, dates, quantities or status fields directly instead of asking the model to reconstruct them from a larger body of data.

This can reduce unnecessary processing and limit how much information enters the model context. It can also make the model’s task clearer. Instead of searching through a large collection of loosely related material, it receives a smaller set of information selected for the job.

The selection still needs care. Removing too much context can make interpretation worse. The goal is not to minimise input at any cost, but to supply the information needed for the task while keeping unrelated data outside it.

This is another place where the surrounding application matters as much as the model itself. Better retrieval, filtering and preparation can simplify the work the model is being asked to do.

Choose a model for the workflow

Once the model has a defined role and receives prepared context, model choice becomes a more practical question.

A larger model may handle a broader range of cases or require less careful task design. A smaller model may be sufficient when the job is narrow, the inputs are well prepared and the expected output is clearly defined. That can matter if the application needs to run frequently, operate within a controlled environment or fit available local hardware.

Size alone does not answer the question. A small model is not automatically cheaper once retries, corrections and review are included, and a locally operated model still carries hardware, energy and maintenance costs. A larger model may also be unnecessary if most of the exact work has already been handled elsewhere in the application.

The useful comparison is therefore the cost and quality of completing the whole workflow to an acceptable standard.

For a sales workflow, candidate models are better evaluated on representative inquiries than on isolated prompts. The evaluation should include clear cases, vague messages and unusual requests, and should measure how much correction is needed after review.

A model is useful here not because it can do everything, but because it can handle its assigned part of the workflow well enough. If that part becomes narrower through better retrieval, checking and software support, the model requirement may change with it.

Find out whether it helps

A workflow that looks sensible on paper still needs to prove itself on real work.

A useful evaluation starts with a representative set of inquiries and compares the resulting briefs with their source material. The test should include straightforward cases, vague messages and unusual requests. Those difficult examples matter because real business communication is rarely as clean as a demonstration.

The evaluation should measure the corrections needed after review, the time saved once that review is included and the total processing cost. It should also show where the workflow fails: missing context, weak interpretation, unnecessary questions, incorrect assumptions or checks that do not catch the right problem.

Those results can guide the next change. The answer may be a better prompt, better input selection, an additional software check, a different model or a smaller automated step.

The division of work does not need to be permanent. As the application improves and models change, responsibilities can move between software, the model and the person reviewing the case.

What matters is that the workflow is designed around the work itself. Exact tasks are best handled by components that can perform them exactly; the model adds value where interpretation is needed, while human judgement remains where a decision still requires context, experience or responsibility.