Agents, loops, and tools

People say “agent” when they mean the chat box, the model, or the product that already runs a loop for them. Those are three different things. The chat box is a product. The model is the part that writes tokens. The loop is the part that keeps going after the first answer.

A product can hide the loop. You type a goal, and the product calls the model, uses its own tools, and shows you the result. You did not write the loop. You still depend on it. When the product stops at a bad step, the failure is often the loop or the tool, not the model’s vocabulary.

Something has to carry the work from one step to the next. A long context window is one way: the earlier tokens are still in the prompt. A store of notes is another: the loop writes a fact down and reads it back later. Meta describes Muse Wonder as a model for agents that remember a person and stay on a task. That is a claim about memory and focus, and it is Meta’s claim.

If the loop forgets, the agent repeats itself. If the loop remembers everything, the bill grows, because every remembered token is input on the next call. Memory is a design choice with a price, not a feature you turn on for free.

Four places cover most of the work. A hosted model API is where you pay a lab by the token and keep the loop in your own code. A finished product, such as a coding agent or a chat workspace, already contains a loop and a set of tools. An open-weight runtime is where you serve a model you can inspect: vLLM, Ray Serve, Ollama, or llama.cpp. An evaluation set is the list of cases that tells you whether a change helped.

Coinbase used that split on purpose. The training run was SkyRL on Anyscale. The serving path was Ray Serve LLM and vLLM. The score was their own fraud set, not a public medal. The tools mattered because the team could see the training, the server, and the test.

A new wrapper with a waitlist is not a tool yet. File it when it changes who can run the loop, or who can score the result.