A tier description is a hypothesis about your workload
Anthropic’s September 28 launch describes Sonnet 5.5 as the second model in its 5.5 family and a complement to Opus 5.5. The announcement positions it for well-scoped everyday tasks, bug fixes, and creating documents, slides, and spreadsheets. It reports speed and cost comparisons with Sonnet 5. These are vendor statements and evaluation results, not independent evidence that the model will complete a particular team’s work with less review.
The useful idea is to separate routine, bounded work from tasks that require deeper judgment or carry a larger consequence. That distinction often aligns better with operating needs than putting every job through one powerful model. But a family label does not tell you which of your own tasks belong in each tier. You need an explicit task definition and a review path.
Start with work a reviewer can check quickly
Choose one recurring task where the right result is visible: format a draft from approved notes, categorize a known set of requests, or update a spreadsheet from a controlled input. Write down the allowed sources, required fields, formatting rules, and cases that should be escalated. Do not use “looks good” as the acceptance test. The reviewer should know what must be present and what must never be invented.
Build examples that include ordinary cases and edge conditions. A missing attachment, ambiguous date, conflicting row, or empty value can show whether the workflow safely pauses. Run the candidate with the same inputs and instructions as the current process. Track correction time, accepted results, and any serious error. Avoid calling the pilot a productivity measurement unless the case set and review effort support that claim.
Keep documents and spreadsheets attached to their sources
For document work, verify every material fact against the supplied source and preserve the link between a claim and the record supporting it. For spreadsheet work, inspect formulas, row counts, filters, and treatment of blanks before accepting an output. A clean-looking slide or table can hide a changed number or a formula that no longer includes all rows. Use a copy or a sandbox until the review procedure is reliable.
Decide who owns the final approval and how changes are tracked. The model can prepare a draft or propose edits; a person should accept changes that affect customer commitments, financial reporting, or policy. Keep a source copy and a change log so an operator can compare the before and after state.
Route exceptions by their consequence
Do not send every task to a more expensive model when only a few cases need additional reasoning. Define the exception in terms the system can detect: missing required data, conflicting sources, unsupported request type, failed validation, or a human reviewer’s escalation. Test whether the routing rule catches the cases you intended and whether routine work remains in the simple lane. If the rule is vague, keep the process human-reviewed.
The immediate next step is a small, reversible pilot on one low-risk, well-scoped task. Compare the vendor’s positioning with your own acceptance criteria and keep the current workflow available. If the candidate passes, expand deliberately. If it fails, record why; that information is more useful than a broad conclusion that one model is “better.”