One sentence, and it starts observing, acting, responding.

Ninety percent of productive work happens in the browser; give agents that interface and they can take on real work

What stands between a person and the digital world?

In the command-line era, it was a set of instructions you had to memorize. In the GUI era, it was windows, buttons, and a mouse. Then the web won everything: roughly ninety percent of productivity scenarios end up inside a browser tab. Booking, expensing, reporting, publishing, price-checking — the entire operational surface of the digital world grew onto web pages.

Now it's the agent's turn to answer that question.

Models are already smart enough. They can write, calculate, reason. But the world is beyond the screen: pages change, prices move, things happen. For an agent to genuinely take over human productivity, what it needs isn't smarter conversation. It's the interface humans have used for thirty years: a browser.

The industry has produced plenty of demos of agents observing, acting, and responding to the real world. The hard part is getting from "the demo runs" to "usable every day."

Web Agent is Qoni's action layer, built for that second thing.

One sentence to delegate, and it watches pages and runs flows for you

Give it one sentence, and the agent opens a browser of its own in the cloud:

• Observe. It watches pages for you: a price drops, stock comes back, terms change — anything moves, you hear about it. No crawlers to write, no cron jobs to configure, no 3 a.m. babysitting.
• Act. It searches, compares, fills forms, and reconciles information from dozens of pages into one conclusion. From intent to result, everything in between is its job.

Everything is recorded; every step can be replayed. What it did and why it did it is always available for review.

One API, instead of a browser-engineering stack of your own

There's no shortage of browser-use style automation options — open source and paid alike. But getting a "library that can drive a browser" is only the starting point: as an agent developer, you still end up building and maintaining a complex browser-engineering stack around it. Headless browser clusters to maintain, proxies and login state to babysit, concurrency scheduling, crash recovery, and observation capture to assemble yourself; 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 hosts the entire execution loop in the cloud — open the page, observe, decide, act, retry on failure. To you, it's one API: your agent states what it wants, and the rest happens in the cloud.

The capabilities are cleanly separated, all exposed as APIs:

• General web operations: log in, fill forms, compare prices, run complete multi-step flows;
• Search and deep research: parallel retrieval across engines, deduplication by normalized URL, cross-checking — producing a conclusion document with a citation list and confidence annotations, not a page of links;
• Track, the standing watch: set a goal and a frequency, and it proactively notifies you when the page changes;
• Login state reuse: sign in once, and later tasks carry on. One login state is one complete browser identity (deliberately not split per site — single sign-on would trap you otherwise), and when it expires, there's a queryable status.

Track and deep research each get a full section below: nothing exposes the gap between "demo" and "production" quite like they do.

Running for hours without falling over takes a four-layer harness, not a wrapper

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 three much duller things: context management, failure recovery, and state persistence.

So the shape of Web Agent isn't "a wrapper around a model." It's a four-layer execution system:

• Orchestration: prompt and context assembly, task memory management, the planning loop, behavioral guardrails. On long tasks, models get lost: context fills with irrelevant material and they forget which step they're on. Orchestration exists so the model always knows where it is, what it has completed, and what remains;
• Browser: sandboxed cloud browsers, one dedicated instance per session. Login state, fingerprints, and caches never bleed between isolated sessions — reusable profiles are carried across sessions explicitly; instances stand by around the clock. 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 — an instance dies, the task doesn't;
• Output: structured artifacts with citations, confidence, and a replayable execution trail. An artifact isn't "the model finished talking" — it's an object downstream programs can consume and humans can audit step by step.

Now for the specific disciplines, one at a time.

One action per step, re-observed after each, squeezes false success to a minimum

Each step performs exactly one action, and every action is followed by a fresh observation. The execution loop is broken into strict micro-steps: observe → decide → act, then back to observe. The agent never chains operations on a stale page snapshot; before executing, it re-verifies that the target element still exists.

This discipline targets the most insidious class of browser-automation accidents: the page changed between two actions. A dialog covered the button, a list re-sorted, an element is still in the DOM but no longer visible. An agent operating on old snapshots "looks successful while clicking somewhere else." The micro-step loop drives that entire class of false success toward zero, mechanically: every action faces a world it has just looked at.

Three observation tiers, escalated on demand: the cleaner the context, the faster the run

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

• Tier one, the accessibility tree: the lightest observation tier, and the default. For most steps, knowing "which interactive elements are on the page" is enough;
• Tier two, targeted queries: fetch only the fragment this step needs. Verifying one price doesn't require a full-page snapshot;
• Tier three, the full page snapshot: the last resort, used only when the lighter tiers genuinely fall short.

Raw page data always lands in artifact storage; what enters the model context is only the observation this one step needs. This isn't just token frugality: the cleaner the context, the steadier the decisions; the lighter the observation, the faster the loop. Subtraction on what the browser feeds the model is where the speed comes from.

No evidence means failure: success must trace to the end state the user sees

"If there is no evidence it succeeded, it failed." This is the system's highest law.

Green lights from intermediate layers don't count — a status flag flipped, a script ran to completion, the model said "done." Success must be traced to the terminal state the user actually sees: the order confirmation page rendered, the report file landed in the workspace, that line on the page really changed to the expected value.

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." A flow can return 200 at every step and still deliver a wrong result; conversely, a test that asserts the terminal state is immune to refactors of everything in between.

Proven paths harden into skills: faster, steadier, self-healing through redesigns

An operation path repeatedly validated on a site hardens into a deterministic action sequence: on a hit, it executes directly, skipping the model call. For high-frequency repetitive tasks this means faster, steadier, cheaper — deterministic code doesn't get creative on the thousandth run.

Skills are not static scripts. When a redesign makes selectors drift, regeneration and revalidation trigger automatically: the model re-scouts the path, validation confirms the new path works, and the new deterministic sequence replaces the old. This is the systemic answer to "scripts shatter everywhere": scripts still shatter, but they grow back on their own.

One boundary: each site's skills are validated independently — a skill is never generalized to another site just because the two look alike. Two e-commerce checkout flows can be identical except for the position of one button, and that button happens to be "confirm payment."

Submit, pay, delete must pass typed gates, never the model's conscience

Submitting forms, paying, deleting — these actions must pass typed gates: actions are explicitly classified, and high-risk categories trigger additional confirmation logic, rather than relying on 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 — not the model's optional conscience. Required means the model cannot silently skip it: at every step, it must answer "is there a wall in front of me?"

On CAPTCHAs and identity checks, our position is: we don't do silent bypasses and we shouldn't — the correct move is to escalate to a human. That's an engineering judgment and a matter of boundaries: CAPTCHAs exist precisely to tell humans from programs, and a production system should not sell bypassing them as a feature.

A resource model preserves the environment across disposable tasks: login state and files keep accumulating

One-off demos don't need a resource model. Production tasks do. Web Agent breaks a long task into three explicit objects:

• The Session is the container: one dedicated browser, one login state, one working directory — the task's entire environment;
• The Run is one complete life of one instruction: from entering the queue to delivering an artifact, with explicit state throughout;
• The event stream is the single source of truth: reasoning, actions, input requests, artifacts — all pushed with sequence numbers, resuming from the exact break point after a disconnect. The stream feeds two mouths at once: live progress display, and after-the-fact step-through replay plus offline decision replay.

The environment carries two persistent assets: the workspace passes files across runs (the report one task downloads, the next task processes), and login profiles carry identity across sessions. Tasks are disposable; the environment accumulates.

Making "awaiting input" one of seven lifecycle states lets a run suspend in place and resume

A run's state machine is fully explicit: pending, running, awaiting input, paused, done, failed, canceled. How the seven states flow and who may trigger each transition is written into the protocol, not agreed on verbally.

The state worth dwelling on is awaiting input: it's first-class, not an anomaly. When a human is needed (login, QR scan, CAPTCHA), the task suspends in place and waits rather than failing and starting over. Suspension is not pause: only the moment a human actually takes the wheel is called pause. When the human finishes, the run resumes from the breakpoint with its accumulated context intact.

Done has a bar to clear, too: only success with evidence counts as done — in the SDK this terminal state surfaces as status: "succeeded" (distinct from the done event on the stream). A run that can't produce evidence of success terminates as failed, not as a vague success.

When a step needs a human, it hands you the browser, then resumes with the context intact

Some steps must be done by a person: logging in, scanning a QR code, solving a CAPTCHA.

Many approaches stall here. Web Agent's answer: it hands you the browser. You take over, finish that one step, and after handback it picks up from the breakpoint — nothing gets thrown away and restarted, and the context doesn't vanish.

There's a carefully designed detail here. When a takeover is initiated, the task does not pause; 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. This design avoids an awkward deadlock: the agent calls for help, the human is in a meeting, and the task hangs forever.

The link can be forwarded straight to your end user — SMS or QR code both work — and only one person can hold control at a time. When the human hands back, the agent forcibly re-observes the page before continuing: it doesn't guess what happened during the takeover, it looks.

Others talk about what agents can do. We talk about how a human can take over at any moment, and hand back.

Letting go and staying in control should never have been a trade-off.

Track watches pages for you: deterministic rules decide what changed, not the model's phrasing

Track is simple to use: set a goal and a frequency, and get notified when the page changes. But "did it change" is precisely the judgment a model should never monopolize.

Model phrasing drifts: the same page is "a price cut" today and "a promotion launch" tomorrow. If the model's wording decides whether to alert, your watch system becomes a random number generator. So Track splits the work: the model only describes what it observed; "did it change, should we alert" is decided by deterministic rules. The model is also not allowed to claim "the alert was already sent" on its own: the verdict belongs to code, not to phrasing.

When the rules say changed, a webhook is delivered to the endpoint you configured, and your existing integrations carry it into the team channel; when they say no change, it returns to patrol.

Deep research can wait for your sign-off before large-scale gathering, before a wrong direction becomes an expensive run

Deep research is an explicit pipeline: brief → plan → outline → gather → cross-check → synthesize. Six explicit stages in sequence — not a black box that spins for ten minutes and emits an essay.

The outline stage can stop and wait for human sign-off: confirm the direction, then run. The placement of this pause is deliberate: it sits before large-scale gathering. When the research direction is wrong, diligence multiplies the waste; a minute spent aligning "what are we researching" is far cheaper than rerunning an hour later.

Gathering retrieves across engines in parallel and deduplicates by normalized URL; cross-checking verifies consistency across sources; the final output is a conclusion document with a citation list and confidence annotations, not a page of links.

Replay real tasks toward a clear target: P90 under two minutes, success rate toward 99%

Between "it runs" and "it delivers" lies engineering.

We set a bar for Web Agent. It is not an achievement already reached but a target we are grinding toward: P90 task completion latency within two minutes, and drive the success rate toward 99%.

The method isn't mysterious: take the real tasks users have handed us over the past few years and test against them relentlessly; locate and fix every scenario that underperforms, then replay to verify; round after round, until it's stable. Improvements that work are distilled into general capability, not one-off patches for a single case.

Ops without night watches, finance without manual exports: two workloads already running in production

First: social media automation and data collection. A real daily routine: 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, let deterministic rules decide whether something changed, push a notification into the team channel when an alert is due. The same capability set runs multi-platform publishing, comment-section monitoring, and public data aggregation. One sentence to delegate, then it's the agent's problem — including the page redesign at 3 a.m.

Second: the systems inside enterprises that "can't be integrated." Not every company has a lakehouse and standardized APIs. Real enterprises are littered with nonstandard, hard-to-maintain legacy systems: no API, but there's a web page. A typical loop: a finance teammate exports a report from a legacy system's 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 the awaiting-input state, 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.

A few lines to integrate: scope the delegation first, then answer "run finished" and "goal achieved" separately

Everything so far has been the machine's insides. Developers care about a different question: how many lines to plug in.

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 of integration 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, answered separately

The last two lines deserve a pause: delivery status and goal achievement are two fields. A run can end normally (succeeded) without achieving its goal; the protocol answers the two questions separately — this is what the "no evidence means failure" discipline looks like 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 inside the interaction, and calling an undeclared method throws. In other words, the "recover" button only exists when recovery actually works — the SDK won't paint you 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 you can runNow() for an immediate patrol, refine() the schedule and notification channel, and manage its lifecycle with pause() / resume() / delete(). After a disconnect, attach() by id returns you to the same monitor or run, resuming the event stream from the break point.

Don't take a vendor's word for it: verify every capability against real tasks

None of the above needs to be taken on a vendor's word — it lands as checkable items on an acceptance sheet:

• Replay real tasks as regressions; assert the final answer, not "the flow completed";
• Sever the event stream and reconnect; events backfill in sequence;
• Issue a control link and let nobody take it: the task keeps moving and the link expires;
• Have someone take over: only one controller at a time, and a forced re-observation after handback;
• Assign a task that cannot possibly produce evidence of success: the verdict must be failure, not vague success;
• Let a login state expire: the status is queryable, the task moves into the awaiting-input state, and resumes from the breakpoint after re-login;
• Track verdicts are reproducible: feed the same set of observations twice and the verdict is identical; when the verdict is changed, the webhook is delivered to the endpoint you configured;
• Trigger a submit / payment / delete action: it must pass a typed gate; hit a CAPTCHA: it escalates to a human instead of silently bypassing.

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

Next: prove it on public benchmarks, then run in your own browser

Two things — no dates promised, both under way:

• Prove ourselves on public industry benchmarks, and publish the real-task test set we've accumulated over the years;
• Let the agent run beyond the cloud: someday, on your own browser and your own computer.

End-state evidence and real-task replay turn "fast and right" from a slogan into an engineering target

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

Web Agent is currently in private build and will open in stages with Qoni. You can join the waitlist on our 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();
}