AI · Source published 28 September 2026
What makes an AI agent useful?
A new model can be faster without being right about everything. Learn the difference between a model and an agent, then compare usefulness with a simple classroom example.
Vendor-reported resultsAbout 5 minutes of core reading · school-level background
Why it matters
Choosing a tool means asking whether it completes your task, how much it costs, and where a person must stay in control.
What you will understand
Explain the difference between a model and an agent, then compare useful work rather than impressive-looking answers.
In this lesson
What the source reports
What the Sonnet announcement adds
Anthropic introduced Claude Sonnet 5.5 on 28 September 2026. Its announcement reports faster output, lower task costs in its tests and stronger performance on several evaluations than Sonnet 5. It presents the model as useful for everyday agent work. These are the provider's reported results. WRS has not independently repeated the comparisons, and the announcement does not establish that the model will succeed on your own research task.
Original report: Anthropic’s Sonnet 5.5 launch and evaluation notes
Build the idea
Start with something familiar: a helpful classmate
Imagine asking a classmate to help plan a school event. They can suggest a timetable, work out a budget and notice a missing task. But a suggestion does not book the room. Someone must check what is allowed, use the booking system and confirm the result. This is a useful starting point for understanding an AI agent.
An AI model is a system that takes an input and produces an output, such as text or a proposed action. An agent combines a model with a way to use tools, observe results and decide what to do next. A tool might read a file, run a calculation or search a source. The surrounding software decides which actions are actually permitted.
Suppose you ask for the total cost of a trip. A text-only answer might guess a number. An agent could read a price list, use a calculator, notice a missing ticket price and ask for it. The extra value comes from that whole loop. A more capable model can help, but a badly designed loop can still produce a bad result.
Build the idea
Why fluent answers are not the same as useful work
An answer can sound calm, clear and confident while being wrong. You have probably seen a neat piece of schoolwork with an arithmetic mistake in the middle. Good presentation helps us read an answer. It does not replace checking it. For an agent, the most useful question is often: can we inspect the result outside the agent's own explanation?
For a spreadsheet task, that might mean checking the sums. For a small program, it might mean trying inputs whose correct outputs are known. For a source summary, it means following the cited passage and seeing whether it actually supports the sentence. Different tasks need different checks. One generic success score cannot tell you all of this.
A benchmark is a fixed collection of tasks used to compare systems. Think of a common exam with shared rules. The score is easier to interpret when the questions, tools, time limits and marking rules are clear. It becomes harder to interpret when one system gets more attempts, different tools or a different version of the exam.
Worked teaching example
Work through a small comparison
These are invented classroom numbers, not results for any real model. Two agents attempt the same 100 small tasks. Agent A produces 90 checked successes and uses 25 budget units. Agent B produces 80 checked successes and uses 20 units. The first success rate is 90 out of 100, or 90 percent. The second is 80 percent.
Now divide the total budget by the number of useful successes. For A, 25 divided by 90 is about 0.28 units per success. For B, 20 divided by 80 is 0.25. A succeeds more often, while B costs less per success in this example. Which would you choose? A tight budget and a task where failure is expensive can lead to different choices.
The average still hides important details. Perhaps A solves the hardest tasks while B solves only easy ones. Perhaps both fail on the one type of question you care about. Keep the results for each task, including failures. Then compare the shared tasks directly. A small, clearly defined test can be more useful to you than a large number without its conditions.
Build the idea
Speed, tokens and the whole job
A token is a small unit used by a model to process text. It can be a word, part of a word or another text fragment. Token counts are not the same as word counts. An agent may process a long input, produce a short reply, run a tool and then read that tool's output. The job can involve several rounds.
Faster text generation can make those rounds quicker. But it is only one part of the total time. Reading a large file, waiting for a tool or checking a result can dominate the job. Imagine a fast runner waiting for a locked door to open. Improving their running speed will not remove the wait. The same distinction matters when comparing agents.
Tokens also do not measure scientific truth. Spending twice as many tokens may mean deeper work, repeated mistakes or a long explanation. A short counterexample can settle a precise claim with very little text. Keep reported resource use separate from the result and its evidence. That lets people judge efficiency without treating effort as proof.
Use the idea
Design a comparison that someone else can repeat
Start with a task small enough to describe completely. For example, ask an agent to sort a list of ten numbers and explain how duplicate values are handled. Save the exact list and the allowed tools. Decide in advance whether a second attempt is allowed. Specify what counts as a correct output before looking at the replies.
Keep the same conditions for both agents. Record a failed run as a failed run, not as a result that disappears from the table. If a service is unavailable, distinguish that from a wrong answer. A later reader should be able to tell whether the model failed, a tool failed or the test never actually ran.
You can help without buying a model call. Write the protocol, make a few checked test cases or find an unclear rule in an existing comparison. Someone with their own agent can later run that work. In WRS, a reusable test design can be a useful contribution. Its value comes from what it enables people to check, not from the fame of a provider.
Words you can now use
- Model
- A system that produces outputs from inputs; the agent's tool access and permissions are separate.
- Agent
- A system combining a model with tools, observations and a loop for choosing further actions.
- Benchmark
- A specified collection of tasks and rules used to compare systems.
- Token
- A text-processing unit used by a model; it is not always one whole word.
Check your understanding
In the classroom example, which agent has the higher success rate, and which has the lower budget per checked success? Why is one overall winner still unclear?
Show the explanation
A has the higher success rate: 90 percent rather than 80 percent. B uses less budget per success: 0.25 rather than about 0.28 units. We still need the kinds of tasks, the costs of failure and the individual results. The example provides no measured performance for Sonnet or any other real model.
What the evidence does and does not show
The launch comparisons are Anthropic reports, not WRS measurements. The classroom numbers in this lesson are invented examples, not benchmarks for real products.
Read the original sources
- Anthropic’s Sonnet 5.5 launch and evaluation notesvendor announcement · 2026-09-28
Continue the reading path
Next: When an AI gets a pass for the wrong problemWRS explanation · 2026-10-08.1. Report a correction. Suggested work is independent of the source authors.