The Agentic Post
Breaking
Gemini’s Multimodal Features, Explained  Â·  ChatGPT Custom GPTs, Explained  Â·  What Is Constitutional AI? Explained  Â·  AI Capex Explained for Investors  Â·  AI Startup Valuations: How They Are Set  Â·  How to Reskill for an AI Job Market  ·  
Home/AI Agents/Computer-Use Agents
Computer Agents Fall From 85% to 20%

Computer Agents Fall From 85% to 20%

Computer-Use Agents

OSWorld 2.0, released June 26, 2026, exposes a major gap between how well computer-use agents perform on saturated benchmarks versus realistic, long-horizon tasks.

Computer-use agents just went from bragging rights to a reality check in a single release cycle. The field’s flagship benchmark, OSWorld, had become so thoroughly beaten by frontier models that scores were pushing past 85% — comfortably ahead of the roughly 72% human baseline. Then on June 26, 2026, the same research group released a harder version, OSWorld 2.0, and the best model in the world dropped straight back down to around 20.6%.

Quick facts

  • OSWorld (the original benchmark) measures how well AI agents complete real desktop tasks — 369 tasks spanning web and desktop apps, file operations, and multi-app workflows — using only screenshots, clicks, and keystrokes, the same interface a human uses.
  • Top computer-use agents reached roughly 85% on OSWorld by mid-2026, up from around 12% in April 2024 and ahead of the ~72% human baseline.
  • OSWorld 2.0, released June 26, 2026, is designed to capture the realism, complexity, and long-horizon demands the original benchmark missed.
  • On the new benchmark, the best-performing model’s score fell to roughly 20.6% — a genuine capability gap, not a rounding difference.

Why the old benchmark stopped meaning much

Benchmark saturation is a familiar pattern in AI: a test is hard, models improve until they beat it, and eventually the test stops distinguishing genuinely capable systems from ones that have simply learned the test’s specific patterns. OSWorld followed that arc unusually fast — from roughly 12% success in April 2024 to around 85% little more than two years later, according to independent analysis published on Medium. That’s an unusually steep improvement curve for a benchmark meant to represent real-world computer use, and it’s exactly the kind of trajectory that should make anyone skeptical that the underlying capability actually improved as fast as the score did.

What OSWorld 2.0 actually tests differently

The research team behind the original benchmark built OSWorld 2.0 specifically because, in their own framing, existing computer-use benchmarks fail to capture the realism, complexity, and long-horizon demands of how people actually use computers — limiting the benchmark’s ability to reveal where frontier agents genuinely fall short. Rather than adjusting scoring on the same task set, the new benchmark changes what’s being asked: longer task chains, more realistic multi-step workflows, and less tolerance for the kind of narrow pattern-matching that let agents rack up points on the original test without a durable underlying capability.

The result, per an independent field guide covering the benchmark shift, was a genuine inversion rather than a gradual correction: the best model available dropped from beating the human baseline to completing roughly one in five tasks, in a single release. The guide’s framing is blunt about what that means for anything written about computer-use agents before this benchmark existed — most of the 2025-era leaderboard claims are now effectively obsolete.

What this means if you’re evaluating a computer-use agent

The practical lesson isn’t that computer-use agents are useless — it’s that a headline benchmark score tells you almost nothing without knowing which benchmark, and how recently it was set. An 85% OSWorld score earned before June 2026 and a 20% OSWorld 2.0 score earned after it can both be accurate descriptions of the same underlying model on different tests. Treat any vendor’s computer-use benchmark claim as incomplete until you know which version of which benchmark it’s citing, and be specifically wary of vendors quoting only their best number without naming the test.

For real deployments, the gap between short, narrow tasks and long, multi-step workflows is exactly where computer-use agents still struggle most — consistent with what OSWorld 2.0 is specifically designed to expose. If you’re evaluating a computer-use agent for a real workflow, test it on your actual longest, messiest task, not a demo-friendly short one.

Common questions

Is OSWorld 2.0 harder for every model equally? The reporting reviewed here doesn’t provide a full model-by-model breakdown; the headline figure is the best available model’s score falling to roughly 20.6%, which implies every model dropped substantially, but relative rankings between specific models on the new benchmark weren’t detailed in the sources available.

Does this mean computer-use agents got worse? No — the models didn’t change. What changed is the test. The same agents that scored 85% on the original OSWorld are the ones scoring 20.6% on OSWorld 2.0; the underlying capability is the same, but the harder benchmark reveals limitations the easier one didn’t test for.

Should I stop trusting OSWorld scores? Not entirely, but always check which version. “OSWorld” without a version number, especially in vendor marketing, should be treated as a yellow flag until you confirm whether it’s the original benchmark or OSWorld 2.0 — the two numbers aren’t comparable.

Key takeaway

Computer-use agents genuinely improved enormously between 2024 and mid-2026 — the 12%-to-85% climb on the original OSWorld is real. But OSWorld 2.0’s results are a useful corrective against treating that climb as evidence the problem is solved: on harder, more realistic tasks, the field is closer to where it started than the old leaderboard suggested.

Up Next
MCP Ships Its Biggest Rewrite Yet

MCP Ships Its Biggest Rewrite Yet

Agent Frameworks

The Model Context Protocol's 2026-07-28 specification makes the protocol stateless at its core, deprecates several long-standing features, and formalizes an Extensions framework.

The Model Context Protocol just shipped its biggest rewrite since launch. On July 28, 2026, MCP’s maintainers finalized the 2026-07-28 specification — the standard that lets AI models securely connect to external tools, files, and services — and the headline change is that the protocol is now stateless at its core, a shift aimed squarely at running AI agents at real production scale.

Quick facts

  • The MCP 2026-07-28 specification finalized on July 28, 2026, described by its maintainers as the largest revision since the protocol launched.
  • The core protocol is now stateless, removing the requirement to track a session ID across requests so any server instance can answer any request.
  • Tasks (long-running operations) and MCP Apps (server-rendered UIs) move out of the core spec into a new formal Extensions framework.
  • Roots, Sampling, and Logging are formally deprecated, along with Dynamic Client Registration; deprecated features stay functional for at least 12 months.
  • Adoption is enormous: MCP’s Tier 1 SDKs see nearly half a billion downloads a month, with both the TypeScript and Python SDKs individually crossing 1 billion total downloads.

What MCP actually is, for anyone catching up

MCP is the plumbing that lets an AI model reach into your calendar, your database, or an internal company tool without an engineering team building a custom connection for every single service. Instead of every AI product inventing its own integration format, an MCP server exposes a standard set of capabilities — callable tools, readable resources, reusable prompt templates — that any MCP-compatible client can use the same way. It’s become the de facto standard for wiring AI agents up to real-world systems since Anthropic introduced it in late 2024.

Why “stateless” is the change that matters most

Under the previous specification, an MCP client and server tracked a session together using a session ID header, meaning the same server instance generally needed to handle every request in a conversation. That’s a real constraint at scale: it makes load balancing harder and forces more state to live in one place. The new stateless core removes that requirement entirely, achieved through six separate Specification Enhancement Proposals working together, according to the official MCP blog. In practice, that means any request can now be answered by any available server instance behind ordinary HTTP load-balancing infrastructure, which is exactly the kind of infrastructure most companies already run everything else on.

Anthropic’s David Soria Parra, one of MCP’s lead maintainers, called it the most substantial change to the specification, according to reporting from The Register, probably since authorization was added. He was direct that this isn’t a drop-in upgrade: the underlying data transfer mechanism has been rebuilt, and “a lot of things that made MCP are gone” in their old form.

What’s deprecated, and what that means for you

Roots, Sampling, and Logging are formally deprecated in the new spec, along with Dynamic Client Registration, which is being replaced by a newer Client ID Metadata Document approach. None of this breaks overnight — MCP’s formal deprecation policy guarantees deprecated features keep working for at least 12 months — but it’s a real migration project for anyone maintaining MCP servers or clients, not a background update you can ignore. Worth noting explicitly: servers built on the new revision aren’t guaranteed to work with older clients, and vice versa, so mixed-version environments need real compatibility testing rather than assumptions.

The enterprise piece: centralized authorization

Separately, on July 6, 2026, MCP’s Enterprise-Managed Authorization extension reached stable status, according to InfoQ. It lets organizations control access to MCP servers centrally through their existing identity provider, replacing per-server consent prompts with a sign-in-once flow. For any company managing dozens or hundreds of internal MCP servers, that’s the difference between a security team that can actually audit access and one drowning in individual approval requests.

Why the download numbers matter

Close to half a billion downloads a month across the official SDKs, with the TypeScript and Python SDKs each individually past a billion downloads total, is the real signal here: MCP isn’t a promising standard anymore, it’s already the substrate a huge share of production agentic workflows run on. That’s exactly why a breaking change to the core transport layer is a genuinely big deal rather than routine protocol housekeeping — it touches an enormous, already-deployed base of agent frameworks and integrations built on the old assumptions.

Common questions

Do I need to upgrade immediately? No. Deprecated features remain functional for at least 12 months under MCP’s formal deprecation policy, giving server and client maintainers real runway to migrate rather than a hard cutover.

Will my existing MCP server keep working with newer clients? Not guaranteed. Because the transport layer itself changed, cross-version compatibility needs explicit testing rather than assumption — treat it the same way you’d treat any breaking API version change.

What replaced Tasks and MCP Apps in the core spec? Nothing replaced them — they moved out of the core protocol into the new formal Extensions framework, meaning they’re still fully supported, just structured as optional add-ons rather than baked into the base spec everyone must implement.

Key takeaway

If you build or host MCP servers, this isn’t optional reading: audit your implementation against the 2026-07-28 changelog, check whether you depend on Roots, Sampling, Logging, or Dynamic Client Registration, and test compatibility explicitly rather than assuming your existing clients and servers will keep talking to each other across the version boundary.