Four APIs — DoAnything, Track, DeepResearch, WebSearch — hosted in the cloud, replayable end to end.

What is Web Agent

About 90% of productive work happens in a browser today. Booking, expensing, reporting, publishing, price-checking — all inside one browser tab. Models are already smart enough — they write, calculate, reason — but the world is beyond the screen: pages change, prices move, things happen. For an agent to take on real work, what it needs isn't smarter conversation. It's the interface humans have used for thirty years: a browser.

Web Agent is Qoni's action layer: it hosts the entire execution loop in the cloud — open the page, observe, decide, act, retry on failure. On integration, it's one API: the agent states what it wants, and the rest happens in the cloud.

There's no shortage of browser-use style automation options, open source and paid alike. But a "library that can drive a browser" is only the starting point: headless browser clusters to maintain, proxies and login state to babysit, concurrency scheduling, crash recovery, and observation capture to assemble by hand — and scripts that shatter every time a page gets redesigned. The library answers "can it click"; the engineering has to answer "usable every day."

Web Agent's four core capabilities

"One API" means DoAnything, the general-purpose entry point; alongside it sit three specialists:

DoAnything — one sentence, and the agent runs a whole flow.

Say "open the back office, go store by store through 20 shops, filter this week's orders, and export them into one consolidated table."

The agent works through that chain in a hosted browser, re-observing the page after every action before deciding the next one. The failure it guards against is "looks successful, actually clicked elsewhere": success is never self-reported — it has to be backed by an end state visible on the page. Every run is recorded, every step replayable. When a step genuinely needs a human — a login, a CAPTCHA — it goes through the takeover mechanism below, not through brute force.

Track — watches pages; "did it change" is not decided by the model.

Say "watch round-trip flights to Tokyo and alert when the price drops more than 10%."

Once the goal and cadence are set, the verdict goes to deterministic rules: the same page is "a price cut" today and "a promotion launch" tomorrow, and if wording decides whether to alert, the watch becomes a random number generator. So the split is: the model only describes what it observed; "did it change, should an alert fire" is decided by rules. When the rules detect a change, a webhook lands at the configured endpoint.

DeepResearch — turns "looking things up" into "delivering a report."

Say "research the agent-identity-auth space and produce a report ready to drop into due-diligence material."

The pipeline is explicit: brief → plan → outline → gather → cross-check → synthesize. The outline stage can stop and wait for sign-off, and the pause sits deliberately before large-scale gathering: when the direction is wrong, diligence multiplies the waste. Otherwise the deliverable is just a page of links; what it hands over is a conclusion document with a citation list and confidence annotations.

WebSearch — one search, one round of verification.

Say "check today's pricing on these three competitors and produce a sourced comparison."

Multiple engines queried in parallel, URLs normalized and deduplicated, sources cross-checked — returning structured, citation-backed results, ready for downstream pipelines. What it really avoids is treating "most similar" as true: a search engine's first answer is not a fact.

Add reusable login profiles on top: sign in once, and later tasks carry the state. One profile is one complete browser identity (deliberately not split per site — single sign-on would trap the user otherwise), and its current validity is queryable.

The agent does one action at a time, then looks again

The most insidious class of browser-automation accident: the page changes between two actions — a dialog covers the button, a list re-sorts — and an agent operating on old snapshots "looks successful while clicking somewhere else."

The execution loop is therefore broken into strict micro-steps: one action per round — observe → decide → act, then back to observe. The agent never chains operations on a stale page snapshot, and re-verifies the target element before executing.

The highest law of success judgment: if there is no evidence it succeeded, it failed. Green lights from intermediate layers don't count — a status flag flipped, a script ran to completion, the model said "done." Success must trace to the terminal state the user actually sees: the order confirmation page rendered, the report file landed in the workspace. Regression testing follows the same law: real user tasks are replayed over and over, and the assertions target the final answer, not "the flow completed."

Three observation tiers keep the agent fast and steady

Not every step dumps the whole DOM into the model. Observation has three tiers, light to heavy:

• Accessibility tree (the default): for most steps, knowing which interactive elements exist is enough;
• Targeted queries: only the fragment this step needs;
• Full page snapshot: the last resort.

Raw page data lands in artifact storage; what enters the model context is only what this one step needs. The cleaner the context, the steadier the decisions; the lighter the observation, the faster the loop.

Paths the agent has walked harden into skills

An operation path repeatedly validated on a site hardens into a deterministic action sequence: on a hit, it executes directly, skipping the model call — faster, steadier, cheaper for high-frequency tasks.

Skills are not static scripts: when a redesign makes selectors drift, regeneration and revalidation trigger automatically, and the new deterministic sequence replaces the old — scripts still shatter, but they grow back on their own. One boundary: each site's skills are validated independently — never generalized to another site just because the two look alike. Two checkout flows can be identical except for the position of one button, and that button happens to be "confirm payment."

Dangerous actions pass gates; a human can take over anytime

Submitting forms, paying, deleting — these must pass typed gates: actions are explicitly classified, and high-risk categories trigger additional confirmation logic, not a "please be careful" line in the prompt. Recognizing login walls, error pages, and risk-control pages is a required structured output at every step: required means the model cannot silently skip it. On CAPTCHAs and identity checks, Qoni's position: no silent bypasses, ever — the correct move is to escalate to a human. CAPTCHAs exist precisely to tell humans from programs, and a production system should not sell bypassing them as a feature.

Some steps must be done by a person: logging in, scanning a QR code, solving a CAPTCHA. Web Agent's answer is Take Control: it hands the browser to the operator — a person takes over, finishes that one step, and after handback it resumes from the breakpoint with the context intact. One carefully designed detail: initiating a takeover does not pause the task; it merely issues a control link valid for a few minutes. Only when someone actually opens the link and takes the wheel does the task pause; if nobody comes, the link expires and the agent keeps working the problem itself. The link can be forwarded straight to the end user — SMS or QR code both work — and only one person can hold control at a time. On handback, the agent forcibly re-observes the page before continuing: it doesn't guess what happened during the takeover, it looks.

Web Agent uses the Browser Harness for production stability and reliability

Wiring a model to a browser takes an afternoon; running for hours without falling over is the actual engineering. Long-horizon tasks rarely die because the agent "couldn't click the button" — they die of context management, failure recovery, and state persistence. And an agent's execution path is decided by the model at runtime; nobody can enumerate it in advance. A system like that can only be constrained at runtime: every step observable and recorded, high-risk actions passing through gates.

So the shape of Web Agent isn't "a wrapper around a model." It's four layers, each with one job:

• Orchestration: prompt and context assembly, task memory, the planning loop, behavioral guardrails — so the model always knows where it is, what's done, and what remains;
• Browser: sandboxed cloud browsers, one dedicated instance per session; login state, fingerprints, and caches never bleed between sessions. A dedicated instance isn't a luxury — it's the baseline of isolation: two tasks sharing one browser is two people sharing one logged-in computer;
• Scheduling: large-scale concurrent orchestration — queues, quotas, crash recovery — so a task can resume after an instance failure;
• Output: structured artifacts with citations, confidence, and a replayable execution trail — objects downstream programs can consume and humans can audit step by step.

A long task breaks into three objects. The Session holds the environment: one dedicated browser, one login state, one workspace. The Run holds one task: the complete life of one instruction. The event stream records everything: reasoning, actions, input requests, and artifacts pushed with sequence numbers, resumable after a disconnect — live progress reads it, after-the-fact replay reads it too.

All seven run states are explicit: pending, running, awaiting input, paused, done, failed, canceled. Awaiting input is first-class, not an anomaly: when a login, QR scan, or CAPTCHA needs a human, the task suspends in place and resumes from the breakpoint. The workspace passes files across runs, and login profiles carry identity across sessions: tasks are disposable; the environment accumulates.

Web Agent's target: P90 under two minutes, success rate toward 99%

The bar Qoni sets for Web Agent is a target, not an achievement already reached but one being ground toward: P90 task completion latency within two minutes, and the success rate pushed toward 99%. The method isn't mysterious: take the real tasks users have handed to Qoni over the past few years and test against them relentlessly; locate and fix every underperforming scenario, then replay to verify; distill improvements into general capability, not one-off patches.

Two workloads already running in production

Social media automation and data collection. An ops teammate tells the agent, "watch these three competitors' pricing and new-release pages, tell me when anything changes." Track takes over: patrol on schedule, rule-adjudicated verdicts, alerts pushed into the team channel. The same capability set runs multi-platform publishing, comment-section monitoring, and public data aggregation.

The systems inside enterprises that "can't be integrated." Real enterprises are littered with legacy systems that have no API but do have a web page. A finance teammate exports a report from a legacy web UI every week; Web Agent takes over the flow — log in, navigate, export, drop the file into the workspace for the downstream task. Login expired? The task moves into awaiting input, the control link goes to the teammate, and after re-login the task resumes from the breakpoint. Unattended operation doesn't come from "nothing ever goes wrong." It comes from having a viable path after something does.

Integrating Web Agent: scope permissions first, then tell "run finished" from "goal achieved"

The SDK ships as @qoniai/qoni (Node 18+, ESM / CommonJS dual build, full TypeScript types), initialized with the AK / SK issued in Qoni Console. Step one isn't sending a task — it's getting a delegation: issue a scoped delegation credential for the current user, and the agent acts only inside its boundary.

import { Qoni } from "@qoniai/qoni";

const qoni = new Qoni({ accessKey, secretKey });

// Authorization first: the products sugar expands each product into its read + manage scope pair
const { data } = await qoni.delegateToken({
  user: { id: userId },
  products: ["doAnything", "track"],
});

// One instruction, one run
const run = await qoni.doAnything.run({
  token: data.token,
  prompt: "Open the back office, export last week's reconciliation report, drop it into the workspace",
});

const result = await run.wait();
result.status;            // succeeded / failed / canceled: the delivery status of this run
result.isTaskSuccessful;  // whether the task's goal was actually achieved: a separate field

The last two lines deserve a pause: delivery status and goal achievement are two fields — a clean finish can still miss the goal. A run can end normally (succeeded) without achieving its goal; the protocol answers the two questions separately — "no evidence means failure," as seen from inside the SDK.

When a human is needed, the interaction isn't an exception — it's a typed event. All five interaction types (site_login / clarification / confirmation / take_control / wait) arrive on the event stream, wrapped in a handle with methods:

for await (const event of run.events()) {
  if (event.type !== "interaction") continue;
  const i = run.interactionHandle(event.data);
  if (i.type === "clarification" && i.can("answer")) await i.answer("the blue button");
  else if (i.can("confirm")) await i.confirm();
}

i.can() carries a deliberate design: whether each action is available is declared explicitly by the backend, and calling an undeclared method throws — the SDK won't paint a button that does nothing. Standing watch follows the same shape: qoni.track.create() returns a monitor handle; a new monitor first enters intent alignment (pending_clarification), and once active, runNow() triggers an immediate patrol, refine() adjusts the schedule and notification channel, and pause() / resume() / delete() manage its lifecycle. After a disconnect, attach() by id returns to the same monitor or run, resuming the event stream from the breakpoint.

One quick-reference table to gather everything this piece covered:

Next, two things — no dates promised, both under way: prove on public industry benchmarks and publish the real-task test set accumulated over the years; and let the agent run beyond the cloud — someday, on local browsers and computers.

Not another agent that demos well — "fast and right" delivered as an engineering metric.

Web Agent is currently in private build and will open in stages with Qoni. Join the waitlist on the website.

import { Qoni } from "@qoniai/qoni";

const qoni = new Qoni({ accessKey, secretKey });

// 权限先行：products 语法糖会为每个产品展开 read + manage 一对 scope
const { data } = await qoni.delegateToken({
  user: { id: userId },
  products: ["doAnything", "track"],
});

// 一条指令，一次执行
const run = await qoni.doAnything.run({
  token: data.token,
  prompt: "打开后台，导出上周的对账单，放到工作目录",
});

const result = await run.wait();
result.status;            // succeeded / failed / canceled：这次执行的交付状态
result.isTaskSuccessful;  // 任务目标是否真的达成：另一个字段，分开回答

for await (const event of run.events()) {
  if (event.type !== "interaction") continue;
  const i = run.interactionHandle(event.data);
  if (i.type === "clarification" && i.can("answer")) await i.answer("蓝色那个按钮");
  else if (i.can("confirm")) await i.confirm();
}