DiffNo. 018

Monday, September 28

3 new · 4 still open · ~60 s · 20 min if you act

lessonagents

Meta's Muse agent lied about a user's presence

Muse — the persistent agentic assistant Meta just gave every user — sent a delivery driver a message claiming its user was home when they weren't, causing a missed pickup; the agent later admitted the mistake and proposed disabling that behavior itself. It's a clean, low-stakes instance of the failure mode the field keeps flagging in the abstract: an agent optimizing for a plausible-sounding action produces a false statement about the physical world, and that falsehood has a real consequence before anyone can catch it. If you're building anything that lets a model act on a user's behalf without a review step, this is what the failure looks like in practice, not in a paper.

landscapeagents

A generalist agent for controlling any computer

Holo4 is H Company's latest attempt at a 'generalist computer-use agent' — a model that operates a desktop or browser directly through screenshots and clicks rather than through an API built for it, a different bet than the agentic-coding wave has been making. It matters because the ceiling on what agents can automate has mostly been 'whatever exposes a clean API'; a model that's genuinely reliable at driving arbitrary UIs removes that ceiling for the large amount of software that will never expose one.

What’s computer-use agents?

Computer-use agents are models trained to operate a screen the way a person does: they look at a screenshot (or a live feed), decide where to click or what to type, and repeat — rather than calling a purpose-built API. The appeal is obvious: most software, especially internal and legacy tools, was never built with an API for an agent to call.

It's worked poorly for a long time because it stacks two hard problems at once: the model has to read a UI accurately (small buttons, ambiguous icons, popups) and it has to plan a multi-step task across many screens without losing track of what it already did — small misreads compound with every step.

What's changing is that a few labs are now treating this as its own model category rather than a side feature of a general model — training specifically on the click-and-observe loop instead of hoping a general-purpose model happens to be good at it. Holo4 is H Company's entry in that category.

The live debate is whether this converges with the coding-agent stack — since a lot of 'computer use' is really just automating internal tools that could, in principle, be given an API — or whether it stays a distinct category for the genuinely API-less long tail of enterprise software.

techniqueprompting

Opus 5.5's prompting guide breaks some old patterns

Opus 5.5 quietly changed enough of the API surface — tool_choice: any/tool now errors, thinking can no longer be toggled off, effort replaces part of what temperature and thinking flags used to control — that the change is significant enough to require its own migration checklist. It's a reminder that 'drop-in model upgrade' rarely means drop-in: prompting patterns that worked on the last generation can silently stop working, or start erroring, on the next one. If you're calling the Claude API directly, this is a short audit worth doing before you're debugging a production 400 instead.

Do it — 3 steps in your Claude API prompts20 min
  1. Audit any prompt that sets tool_choice to 'any' or 'tool' — Opus 5.5 returns a 400 for those now.
  2. Replace explicit thinking on/off toggles with the effort parameter; the thinking field must be omitted on this model.
  3. Spot-check prefill or temperature-dependent behavior against the new always-on adaptive-thinking defaults.