Amazon Says Strands Decider Cut Labeling Costs 98%

Amazon engineers Carr Onstott and Mehul Jaiswal say replacing Claude Sonnet 4.6 with Strands Decider cut AI costs for an internal ticket-labeling system by 98%. The team reports comparable classification performance and projects millions of dollars in annual token savings.

Their November 9, 2026 Strands Agents write-up describes a specific migration: take a high-volume task with 20 known categories, replace generated JSON with a decision output, and compare both systems before changing which one controls production labels.

The useful contribution is the implementation pattern. Teams considering a similar move can copy the evaluation sequence, deployment structure and rollback mechanism without assuming they will reproduce Amazon's savings.

Why Ticket Labeling Fits a Decision Model

Amazon's system handles customer escalations, capacity requests, automated alarms, security findings and other internal tickets. Sonnet 4.6 processed each ticket with a long system prompt, reasoned against the label catalog and generated JSON.

Strands Decider accepts a state, a question and a set of possible answers. It returns probabilities for the options plus a confidence score. It cannot generate free-form text, according to the engineers' account.

For this application, the mapping is straightforward:

• State: the ticket's content.
• Options: the available ticket categories, plus a "none" option.
• Decision: which category to apply, subject to a confidence threshold.

A fixed catalog removes much of the need for text generation. The consuming application needs a label, not a paragraph explaining it. That makes this a plausible candidate for specialization.

I'd begin with that output contract when assessing a replacement. If a downstream workflow needs explanations, summaries or suggested actions, a label-only model cannot supply them. The engineers also caution that frequently changing catalogs and tickets requiring extensive context are poor fits for this approach. Those constraints narrow the opportunity to a particular class of classification work; they do not make this a general replacement for Anthropic's Sonnet.

Build the Comparison Around Labels and Confidence

The engineers started with the original Strands Decider 2B, then selected the E4B Gemma 4 build after it performed better on their ticket test set. They tuned the confidence required to apply a label and compared that configuration with production Sonnet on a separate ticket set.

Their documented sequence offers a useful evaluation plan:

1. Define the closed label catalog. Identify the decisions the application actually needs to make, including what happens when no category fits.
2. Rewrite labels as concise criteria. Amazon reduced each of its 20 label descriptions to one or two sentences and supplied them as options in a single-choice question.
3. Compare candidate builds offline. Use held-out tickets to select a candidate before changing production behavior.
4. Tune the confidence threshold. Decide how much confidence is required before the application accepts a label.
5. Compare the selected configuration with production on a separate set. Keep model selection and the final comparison distinct.

The shorter criteria were necessary because Decider's context window was 4,096 tokens. Amazon's production label descriptions alone exceeded that limit. The team also dropped the oldest comments from long tickets to make them fit.

That means the migration changed three things together: the model, the label descriptions and, for long tickets, the available history. Any quality comparison evaluates that complete pipeline. I'd explicitly track long-ticket results because losing an early comment could matter even when aggregate results look healthy.

The authors say E4B beat production Sonnet on the separate comparison set. However, the post supplies no raw ticket dataset, numerical quality scores, absolute traffic volume or independent replication. It also leaves readers without enough evaluation detail to reproduce the quality claim.

Treat Confidence as a Policy Setting

A confidence threshold determines which predictions the application accepts. Raising it generally trades coverage for selectivity: fewer tickets may receive an automatic label, but the accepted subset can be more reliable.

A confidence score is not automatically a calibrated probability of correctness. For another deployment, I'd measure both accepted-label accuracy and the proportion of tickets accepted at each threshold. A model that performs well only after declining most tickets may be useful, but it has different economics from one that handles nearly everything.

The write-up does not specify the low-confidence handling policy, so teams need to define their own path for those tickets, such as review, leaving them unlabeled or invoking another model.

Use Three Modes to Separate Testing From Control

Amazon's labeling Lambda reads a three-way setting from AWS AppConfig for every message. The modes determine which models run and whose answer reaches the ticket:

The important distinction is between producing a prediction and allowing it to affect production. In DUAL, Decider sees live traffic without controlling the labels. The engineers say examining disagreements on real tickets taught them more than offline evaluation alone.

I'd copy this switch before copying the model choice. It creates a controlled way to inspect unfamiliar ticket formats, changing traffic and operational failures while preserving the existing labeling path. Returning the setting to BEDROCK also provides a rollback route, provided that path remains available.

Agreement alone is not a quality metric: both models can make the same mistake. A practical evaluation should assess disagreements against the intended labeling rules and inspect some agreements too. That is an evaluation recommendation, not an additional result published by Amazon.

The team defined its infrastructure in AWS CDK with Beta, Gamma and Prod deployment stages, adding environment-level staging alongside the runtime model switch.

Deploy the Model Behind a Network-Isolated Endpoint

The production path uses standard AWS services:

• Ticket events enter an SQS queue.
• A Lambda function reads ticket data and calls the model.
• A SageMaker AI endpoint serves Strands Decider.
• AppConfig holds the operating mode.
• CloudWatch carries logs, metrics and alarms.

The engineers ran E4B on SageMaker ml.g5.xlarge instances, each with one A10G GPU and 24 GB of GPU memory. They report roughly 19 GiB of model memory use and about 640 milliseconds for one request on one instance.

The endpoint autoscales with traffic. Its model container has outbound network access blocked, and SageMaker copies the model weights from S3 before startup. Teams adopting this setup should therefore plan for the model to start from supplied artifacts without downloading dependencies during serving.

The reported 640 ms single-instance request time should stay separate from the 897 ms average call time in the comparison below. The post provides both figures without enough timing detail to treat them as interchangeable measurements.

Read the 98% Savings as a Utilization-Dependent Claim

The engineers report these results for their Sonnet and Decider pipelines: