Choose AI around the work your business needs to finish
Website edition prepared November 11, 2026. The archive date is a reading order; the source news date is listed below.
A customer asking about opening hours and an employee reviewing a complicated technical brief may both be using AI. That does not mean they need the same model, the same instructions or the same review process. The useful starting point is the job each person needs to complete.
1Read the request
2Choose the right review
3Check the receiving end
Integrations are scoped and tested separately.
Start with the actual request
Anthropic's November 9, 2026 announcement of Claude Fable 5.2 and Mythos 5.2 makes that distinction particularly relevant. The company positions these models for demanding technical work and continues to recommend Opus as a daily driver for most everyday coding and knowledge work. Fable has safeguards for broader access; Mythos access requires a verification programme. An announcement about advanced capability is therefore not evidence that every business can or should deploy every model.
For a smaller company, the choice begins closer to the customer. What information arrives? What decision follows? What happens when the answer is uncertain? Those questions tell you much more about a useful setup than the name of the newest release.
Consider an installer receiving enquiries through a mobile website. One visitor asks which areas the company serves. Another sends a description of a difficult job and asks whether a proposed installation is suitable. The first answer might come from a short, approved service-area statement. The second requires someone qualified to review the actual details. A fluent response should never quietly become a technical commitment.
This is an illustrative workflow, not a claim about a completed ProgressorAI client project. We would keep the customer's original request in the CRM, record what the assistant actually answered and give the unresolved question an owner. A more capable model may help prepare a useful summary. It does not replace the company's responsibility for the final decision.
Compare the work that remains
Before choosing a setup, collect representative examples without exposing private customer information. Include straightforward enquiries, ambiguous descriptions and requests outside the service area. Decide what an acceptable result looks like before comparing answers. For a routine enquiry, that may mean an accurate response based only on approved information. For a technical request, success may mean recognising uncertainty and handing over a clear summary.
Then review the work that remains. How often does a person need to correct the response? Does the summary preserve the customer's important detail? Can the receiving employee understand what they need to do next? An inexpensive response can become costly when somebody has to reconstruct the conversation. Equally, paying for more reasoning may offer little value for a question answered by one verified sentence.
The website and the receiving system should be tested together. Submit a synthetic enquiry from a phone, inspect the saved record and follow it to the responsible person. Test an incomplete request as well as a clean one. The customer should receive a truthful acknowledgement, while the team can distinguish receipt from review and an approved answer from a draft.
The practical aim is a process the business can explain and maintain. Keep approved information current, define when human review is necessary and review the choice again when the work changes. At ProgressorAI, that is the conversation we would start before selecting a model for a website, CRM or front desk.