What was announced
Anthropic introduced Claude Sonnet 5.5 on September 28, 2026. The announcement positions it for well-scoped everyday work and reports higher speed and lower task costs than Sonnet 5 in its evaluations. It also retains Opus 5.5 as the stronger option for complex, open-ended work requiring sustained judgment.
Those comparisons belong to Anthropic. They do not establish which model best handles a particular studio's enquiries. The useful question is whether a reviewer can consistently accept the output the application actually needs.
The araNET take: improve the handoff first
Write an output contract before extending the prompt. For an enquiry-summary assistant, the contract should describe what the reviewer receives and how uncertainty survives the handoff. Here is a fictional input, created for this example:
“We run a bicycle repair shop. Our contact form stopped working after a site update. Could you look at it? We would prefer next week. I can send the website address later. — Morgan”
The proposed contract requests six fields: requested service, reported problem, supplied facts, missing information, preferred timing and decision status. It also requires a reference to the original enquiry. The assistant may summarize that input; it may not diagnose the site, quote a price or accept the job.
Define the output before the prompt gets longer
A reviewable output for that input would look like this:
- Requested service: website support; suggested category for a reviewer to confirm.
- Reported problem: the sender says the contact form stopped working after an update. Cause not established.
- Supplied facts: bicycle repair business; sender named Morgan; an update preceded the reported failure.
- Missing information: website address, example error and an agreed way to investigate. Budget not supplied.
- Preferred timing: next week, as requested by the sender; no appointment agreed.
- Decision status: awaiting review. No quote, booking or outbound message authorized.
The difference between “after an update” and “caused by the update” is central to the contract. The first preserves the report. The second invents a diagnosis. Likewise, a preference for next week must not become a promised completion date.
Give the reviewer explicit rejection reasons: unsupported diagnosis, invented budget, missing source reference, omitted uncertainty or unauthorized commitment. A draft can be well written and still fail any of those checks.
Test a second input with two requested services and a third with contradictory dates. Define whether those cases need multiple categories or escalation before comparing models. Save the accepted examples and the rejected variants so a later model change faces the same standard.
A faster draft is not an approved action
Keep the summary beside the original message. Let the reviewer accept, revise or escalate it, and record which fields required correction. If the summary goes into an app, enforce access and save permissions in that app rather than relying on the model to remember them.
Retain the contract with the accepted and rejected examples. A later model comparison then has a repeatable task and specific reasons for accepting or returning a draft.
