Copy English

Why

Tracking where computer-use agents actually stand in production, not in demos. The a16z piece is built on interviews with real operators — a CPG data platform running 15-20M portal interactions a month, a systems integrator running 27 live workflows — not just benchmark numbers. A useful checkpoint for judging whether an "agent operates a browser or UI" idea is worth building now versus still a research toy.

The headline number is real and the argument is that it stopped mattering. OSWorld-Verified, a real-desktop benchmark, went from 42% a year ago to 85% today, above the roughly 72% human baseline. But once models cleared a good enough bar, buyers stopped comparing models and started buying infrastructure — verification, escalation, error handling. The model is no longer the product.

And the other end of the same question is a much smaller, much cheaper answer that this catalogue kept as a separate card for no good reason. Alibaba's page-agent is an in-page GUI agent: one script tag or npm install, and natural language operates that page's UI. No screenshots, no browser extension, no headless browser — it reads a text-based DOM, connects to any LLM you bring, has a beta MCP server, and is built on browser-use. The general capability question and the specific embedding decision are the same question at two scales, and holding them together is what makes either useful: the a16z piece says the bottleneck is now operations, and page-agent is the case where almost all of the operations disappear because the agent only ever touches one page you control.

The failure mode that matters most is the one neither half advertises. It is not the UI click failing — it is silent failure with no verifiable signal at run time. An insurance claim that "succeeded" on screen and stalls two days later on a phone call nobody logged. That is why verification, not accuracy, is what buyers pay for, and it is the same shape as the-harness-not-the-model: the interesting engineering is around the model, not in it.

How it works

Where the benchmark went, and why it stopped mattering

Once models cleared the bar, the purchase became verification, escalation and error handling. A common pattern: an agent runs a workflow once, caches it as deterministic code, and is only re-invoked when something breaks — so cost falls over a workflow's lifetime rather than staying flat.

The cost comparison that decides whether to build

Two scales of the same capability

The right way to read the pair: the general case is where the operations layer is the product, and the embedded case is the one where you can skip most of it — because you control the surface, so a failure is visible in your own application rather than two days later on somebody else's phone call. A landing-page or SaaS copilot, or smart form-filling, is the natural first use.

The failure mode to design against

Not the click that fails — the one that appears to succeed. No verifiable signal exists at run time, so the workflow reports done and the real state diverges silently. Verification is not a feature bolted on afterwards; it is the reason the infrastructure layer exists, and it is why the honest first question for any browser-agent idea is how would I know this went wrong rather than can the model do it.

The authoring end of the same question

This card asks whether an agent can drive a computer and concludes that once it can, what you buy is operations. demonstration-is-not-a-specification arrives at the same conclusion from the other end — how a task gets stated — by way of the screen-recording interfaces that a startup and a large vendor shipped weeks apart in 2026. The short version: recording lowers the cost of authoring a task and leaves the cost of running it reliably exactly where it was.

Where it lands in Jayverse

• Rabbit: treat verification, not task success, as the product surface for agent-driven mandates. Session keys and mandates already let an agent act on a user's behalf; log a false-promise rate — the share of agent actions that reported success but whose downstream effect never landed — the same metric simulate-before-sign proposes for Wallet.
• Wallet: give any agent-driven flow through the embedded wallet its own escalation path. A mandate-authorized agent action that looks successful but whose effect never lands needs a defined "what happens next," not a silent stall two days later.
• Game: if the Unity street ever hosts an in-page agent, scope it as page-agent's narrow case. Keep it limited to the DOM Jayverse itself controls — its own boards and UI — rather than general computer-use, since that is what keeps the operations burden to almost nothing.

← All Knowledge Notes · Workspace Index · Top ↑ · Open on jaylabs.xyz →

Copy 한국어

에이전트는 이제 컴퓨터를 쓸 수 있나 — 그렇다면, 누구의 컴퓨터를?

OSWorld 가 1년 만에 42% 에서 85% 로 뛰었고 구매자는 모델 비교를 그만뒀습니다. 대신 사는 것은 검증·에스컬레이션·오류 처리이고 — 같은 질문의 반대쪽 끝에서는, 스크립트 한 줄이 그 전부 없이 특정 페이지 하나를 자연어로 조작하게 합니다.

시장 절반은 정독 노트 — 데모 없음, 지갑 불필요. 구축 절반은 스크립트 한 줄: github.com/alibaba/page-agent, <script> 하나 또는 npm 설치, 이미 갖고 있는 페이지에 붙여 보고 DOM 만으로 부족해지는 지점이 어디인지 적습니다. 출처: https://www.a16z.news/p/can-agents-use-a-computer-yet-weve

왜

컴퓨터 사용 에이전트가 데모가 아니라 프로덕션에서 실제로 어디까지 와 있는지 추적합니다. a16z 글은 실제 운영자 인터뷰 위에 세워져 있습니다 — 월 1,500~2,100만 건의 포털 상호작용을 처리하는 CPG 데이터 플랫폼, 27개 라이브 워크플로를 돌리는 시스템 통합사 — 벤치마크 숫자만이 아니라. "에이전트가 브라우저/UI를 조작한다"는 아이디어가 지금 만들 만한지, 아직 리서치 토이인지 판단할 때 쓸 체크포인트입니다.

헤드라인 숫자는 진짜이고, 논지는 그것이 더 이상 중요하지 않게 됐다는 것입니다. 실제 데스크톱 벤치마크 OSWorld-Verified 가 1년 전 42% 에서 오늘 85% 로, 인간 기준선 약 72% 를 넘었습니다. 그런데 모델이 충분히 좋은 문턱을 넘자 구매자들은 모델 비교를 멈추고 인프라를 사기 시작했습니다 — 검증, 에스컬레이션, 오류 처리. 모델은 더 이상 제품이 아닙니다.

그리고 같은 질문의 반대쪽 끝에, 훨씬 작고 훨씬 싼 답이 있습니다. 이 카탈로그가 별 이유 없이 따로 두고 있던 것입니다. Alibaba page-agent 는 페이지 안에 심는 GUI 에이전트입니다 — 스크립트 한 줄 또는 npm 설치로 자연어가 그 페이지의 UI를 조작합니다. 스크린샷도, 브라우저 확장도, 헤드리스 브라우저도 없이 — 텍스트 기반 DOM 을 읽고, 원하는 LLM 을 붙이고(BYO), MCP 서버 베타가 있으며, browser-use 기반입니다. 일반 역량 질문과 구체적 임베딩 결정은 두 축척의 같은 질문이고, 둘을 함께 두는 것이 어느 쪽이든 쓸모 있게 만듭니다 — a16z 는 병목이 이제 운영이라고 말하고, page-agent 는 에이전트가 내가 통제하는 페이지 하나만 건드리기 때문에 그 운영의 거의 전부가 사라지는 사례입니다.

가장 중요한 실패 유형은 어느 쪽도 광고하지 않는 것입니다. UI 클릭 실패가 아니라 — 실행 시점에 검증할 신호가 없는 조용한 실패입니다. 화면상 "접수 완료"된 보험 청구가 이틀 뒤 아무도 기록하지 않은 전화 한 통 때문에 멈추는 것. 정확도가 아니라 검증에 구매자가 돈을 내는 이유이고, the-harness-not-the-model 과 같은 모양입니다 — 흥미로운 엔지니어링은 모델 안이 아니라 모델 둘레에 있습니다.

동작 방식

벤치마크는 어디로 갔고, 왜 중요하지 않게 됐나

모델이 문턱을 넘자, 구매 대상이 검증·에스컬레이션·오류 처리가 됐습니다. 흔한 패턴 하나: 에이전트가 워크플로를 한 번 실행한 뒤 결정론적 코드로 캐싱해 두고, 뭔가 깨질 때만 다시 호출됩니다 — 비용이 평평하게 유지되는 게 아니라 워크플로 수명 동안 떨어집니다.

만들지 말지를 정하는 비용 비교

같은 역량의 두 축척

둘을 읽는 올바른 방법: 범용 사례는 운영 계층이 곧 제품인 자리이고, 임베디드 사례는 그 대부분을 건너뛸 수 있는 자리입니다 — 표면을 내가 통제하므로, 실패가 이틀 뒤 남의 전화가 아니라 내 애플리케이션 안에서 보이기 때문입니다. 랜딩/SaaS 코파일럿, 스마트 폼 채우기가 자연스러운 첫 용도입니다.

설계로 막아야 할 실패 유형

실패하는 클릭이 아니라, 성공한 것처럼 보이는 클릭. 실행 시점에 검증 가능한 신호가 없어서, 워크플로는 완료를 보고하고 실제 상태는 조용히 갈라집니다. 검증은 나중에 덧붙이는 기능이 아니라 인프라 계층이 존재하는 이유 그 자체이고, 그래서 어떤 브라우저 에이전트 아이디어든 정직한 첫 질문은 모델이 할 수 있나 가 아니라 잘못됐다는 걸 내가 어떻게 알지 입니다.

같은 질문의 작성 쪽 끝

이 카드는 에이전트가 컴퓨터를 몰 수 있는지를 묻고, 몰 수 있게 된 뒤에 사는 것은 운영이라고 결론짓습니다. demonstration-is-not-a-specification 은 같은 결론에 반대쪽 끝 — 작업을 어떻게 진술하는가 — 에서 도달합니다. 2026년 스타트업과 대형 벤더가 몇 주 간격으로 내놓은 화면 녹화 인터페이스가 그 경로입니다. 짧게: 녹화는 작업을 작성하는 비용을 낮추고, 그것을 신뢰성 있게 돌리는 비용은 있던 자리에 그대로 둡니다.

Jayverse에서의 위치

• Rabbit: 에이전트가 주도하는 mandate의 상품 표면을 작업 성공이 아니라 검증으로 삼는다. 세션 키와 mandate는 이미 에이전트가 사용자를 대신해 행동하게 하므로, 성공으로 보고됐지만 실제 결과가 반영되지 않은 비율, 즉 simulate-before-sign이 Wallet에 제안하는 것과 같은 false-promise rate를 기록한다.
• Wallet: 임베디드 지갑을 거치는 에이전트 주도 흐름에는 별도의 에스컬레이션 경로를 둔다. mandate로 승인된 에이전트 행동이 겉으로는 성공했지만 실제 효과가 반영되지 않았을 때 "다음에 무슨 일이 일어나는지"를 정의해두어야지, 이틀 뒤에 조용히 멈추게 두면 안 된다.
• Game: Unity 거리에 인페이지 에이전트를 넣는다면 page-agent의 좁은 사례로 범위를 잡는다. 범용 컴퓨터 사용이 아니라 Jayverse가 직접 통제하는 DOM, 즉 자체 보드와 UI로 한정한다. 그래야 운영 부담이 거의 사라진다.

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑ · Open on jaylabs.xyz →