Imagine getting a supplier comparison back almost immediately. The prices are neatly lined up, there's a recommendation at the bottom. Then you notice one price is from last year, and another buys a different product. The AI has finished. You haven't. Sakana's new research offers a way for a model to improve how it works. Using examples, it helps judge itself. That's worth attention. For the person checking that supplier report, the useful improvement would be fewer mistakes to untangle, not just an earlier arrival in the inbox. This is the Augur dispatch for Monday, October 12, 2026. Sakana calls the method multi-agent self-supervision, or mass. It sounds like a room full of machines. In this case, one underlying model takes different roles, doing the work, suggesting a better approach, and judging which attempts to keep. The selected examples become training material. The model learns from them and tries again. That goes beyond asking several assistants to discuss an answer. The training changes the model itself. The training tasks were machine-generated research exercises, so the experiment doesn't establish how well this transfers to a company's own records. The appeal is easy to see. If a system can produce useful lessons from its own attempts, improving it may require less hand-prepared training material. Sakana's experiment gives that idea something concrete to examine. After two rounds of training, Sakana reports better research results, including more benchmark score for each output token. Tokens are the chunks of text a model produces. Across four research tests, the reported ratio is roughly 1.2 to 1.6 times the starting models. There are gains in the answers too. On a scientific task benchmark, success rises from about 29% to about 32%. Some coding benchmarks go the other way. Those results make the choice more interesting than whether to believe in self-improving AI. A system might become a better research assistant without becoming a better programmer. Buying it for the wrong job could erase the benefit before anyone opens the bill. There's also a distinction worth getting right about who marked the work. During training, the model judge's candidate approaches itself. The paper then reports separate evaluation using other models and public benchmarks with their own scoring methods. That corrects the original dispatch's claim that there was no outside evaluation. There was. Other model judges aren't a human accepting the work, and the author's tests aren't independent replication, but they shouldn't be dismissed as the model simply awarding itself a prize. For our supplier comparison, the unanswered question is whether the trained system would make fewer of the mistakes that sent the analyst back to the source documents. The paper doesn't establish that result on this imagined business task. The way the job is divided could matter as much as the model doing it. Suppose the analyst needs information about several suppliers. Separate assistants could each investigate a company using the same requirements and the same date for prices. That work has room to happen in parallel. Now suppose one assistant calculates the costs, another applies a discount, and a third chooses the winner. If they pass along an assumption incorrectly, each later step can make the wrong answer look more complete. Putting the assistants in a group doesn't resolve that difference. Anyone who has tried to reconcile several versions of the same spreadsheet has met the human version of this problem. Google Research tested 180 agent configurations. Coordination improved performance on a financial reasoning benchmark whose work could be split apart. On a sequential planning benchmark, where later steps depended on earlier ones, the tested multi-agent approaches performed worse. That was separate research, not a test of Sakana's system, and its results don't predict the saving in a purchasing department. It does give us a reason to separate two jobs that often get bundled together, gathering independent evidence and maintaining one consistent chain of reasoning. Auger's reading is that the supplier search may be a better place to try coordinated assistance than the final calculation deciding which contract to sign. Come back to the analyst with the finished report. The first useful change might happen before the model starts writing. Give it the terms the comparison must satisfy. The same product category, comparable contract periods, and current prices with sources the reviewer can open. When a price isn't available, the report should say so rather than fill the space with a plausible substitute. That doesn't guarantee a correct answer. It gives the person reviewing it a defined job, instead of asking them to discover what the comparison was supposed to mean after the recommendation has already arrived. A review process that checks dates and contract terms is different from one that rereads polished paragraphs. If the new system saves effort on those checks, it has done something useful, even though a person still signs off. It could also help the analyst investigate another viable supplier rather than stop at the familiar short list. That's a possible use of time saved, not a result Sakana has demonstrated. The value would depend on whether the extra research changes the decision. This is where the efficiency number runs out. Score per output token doesn't include the entire training bill, tool use, failed attempts, or the analyst's afternoon, nor does a shorter response automatically mean less checking. A concise report can still omit the condition that would have changed the purchase. Brevity has never stopped a document from creating a meeting. A useful comparison would follow the work all the way to acceptance. Keep the failed runs and the cost, count the corrections, and record how often the result meets the requirements. Otherwise, a cheap answer that nobody can use can make the spreadsheet look better while the work piles up elsewhere. The detailed test plan is in the episode notes. It starts with 20 recent non-sensitive research tasks and compares the existing process with single-agent and coordinated runs. The research or operations lead owns the result, with an experienced reviewer deciding what passes against criteria agreed beforehand. The first review is October 26th. Stop a task group if acceptance gets worse, a critical error slips through, or the experiment exceeds its approved data scope. A small sample can expose a problem. Repeat the comparison on fresh tasks before treating a saving as dependable. This tests the workflow. Reproducing mass would also require its training procedure and a separately measured training cost. Sakana already has public workflow and training code, although the repository documents differences from the reported experiments. The opportunity for a business is to learn which parts of a recurring job can be delegated reliably. That knowledge can remain useful when the next model arrives. The model name is likely to change sooner than the need to compare suppliers fairly. Augur would pilot the independent research work while keeping the purchasing decision and its checks with people. Adopt the full cost measure now. Watch whether Mass's gains survive independent reproduction and human review before treating this as evidence for a broader replacement. Expansion would make sense if the reviewer could accept more useful work with less total effort, without letting serious errors through. A fast draft that still needs reconstructing hasn't earned that change. In our supplier example, the analyst should finish knowing which prices can actually be compared and which uncertainties still need a call to the vendor. The AI's contribution is worth paying for when it helps the person reach that point sooner. The written brief with every source is at augurd dispatch.ai. Portions of the Augur Dispatch are AI generated. That is the Augur Dispatch for Monday, October 12th, 2026. Thank you for listening.