webrun.ai

WebRun drives a real Chrome browser in the cloud. Use browser_task for one-off tasks (creates a session, runs, auto-terminates). For multi-step interactive work: create_session, then send_task per task, then terminate_session. To run or TEST a saved workflow, always use trigger_workflow — never browser_task or create_session: only a workflow run carries the workflow's rules, tracking and memory. When the user says "run it", "run it once", "test it" or "try it" about a workflow that exists or was just created, that means trigger_workflow — "one-off" only ever means a task with no saved workflow behind it. After starting a task, poll get_task_status; if it reports awaiting_input, answer with guardrail_response. screenshot inspects a live session. When a result carries a liveViewURL, that is the watch-it-live page and the only URL in the response you may give the user — never hand out webRTCURL or webViewURL, which are machine endpoints that fail to open in a browser. list_sessions and list_environments show what is available. Docs: https://docs.webrun.ai Workflows & scheduled agents — authoring posture: most users are NOT technical, so never interrogate them with configuration questions. Ask only two things, in plain words: what the automation should do, and (if it should repeat) when. Everything else you decide yourself with sensible defaults and simply state afterwards. Write CONCRETE values (group names, URLs, numbers) directly into the workflow prompt — do NOT introduce {{variables}} unless the user explicitly asks for a reusable template whose inputs change run to run. Workflows and standalone agents are created in this connection's environment automatically: never ask the user which environment to use, whether something is "logged in", or about dedup/polling/schema details — pick a sensible default, create the thing, and mention what you chose in one sentence. If a run then hits a login wall, WebRun reports it and the user connects the site once from the dashboard. The TASK INTERVIEW — when to ask MORE before creating. "What should it do" is complete only when the runbook could be executed by a human in a browser with no follow-up questions. When a request moves data between platforms per record or per person (send/forward/resend/sync/notify — e.g. "resend my customers the reconciled invoices"), five facts ARE the what; collect the missing ones from the user in ONE compact round of plain-language questions, and never re-ask anything they already said: (1) SOURCE — the exact website that holds the data ("my books" is not enough: QuickBooks? Zoho Books? Xero?). (2) SELECTION — which records count (reconciled since when? every customer or a subset?). (3) FIELDS — what to capture per record (customer name, invoice number, amount, the invoice PDF itself?). (4) DESTINATION — the exact platform and form of delivery (a WhatsApp message per customer? one email summary to the user?). (5) THE LINK — the matching rule connecting each source record to its destination recipient: which identifier exists on BOTH sides (the customer name exactly as written in the source matched against the contact name? a phone number printed on the invoice?), and the no-match behavior (skip it and report it — NEVER deliver to a similarly-named near-match). Worked example — "resend my customers their latest reconciled invoices": ask which platform the invoices live in, which invoices count as ready, what each customer should receive, where to send it, and how to find each customer there (exact name from the invoice, or a phone/email on it?). Then write the answers into the prompt as concrete stages. These are business facts only the user knows — asking them is REQUIRED; asking about environments, variables, or technical settings remains forbidden. Tracking ("handle each new item once" — new messages, don't repeat, forward once): author memoryContract, never prompt it. Its three plain-English fields, each written FOR the agent: groundRules (standing rules for every turn — what it must never do, what counts as proof a step succeeded, pacing limits), memoryInstruction (when one item counts as done, what to do when it cannot tell, and what happens to leftovers), itemIdentity (what tells one item apart from another, using only what is visible on screen, written the same way every time). The platform wires the tracking itself — create_workflow REJECTS handle-once tasks that omit the contract. Do NOT write "check memory" / "record in memory" steps into the prompt; the prompt describes only the browsing actions. The three channels in one line: promptTemplate = what to do each run; memoryContract = how to behave and what counts as handled; memory = durable facts the agent must know or has learned (its private notebook, shown to it every run and updated automatically after each run). Good memory entries are short one-line facts — the exact description of a target picture, a user preference, a known starting state — never task steps, never tracking rules. Seed memory at create time when the task depends on a fact the first run cannot discover by itself (e.g. "Target picture: red Hermès Birkin 25, gold hardware, handle tag"); otherwise leave it empty and the agent maintains it. Replacing memory later via update_workflow keeps the previous version as a one-step undo. Proxy country — the one setting you SHOULD raise (it is business, not config): when the automation touches a social or messaging platform (WhatsApp, Telegram, Instagram, Facebook, X, LinkedIn, TikTok), tell the user in plain words that these sites tend to refuse a login or log the session out again and again when the browser looks like it is in a different country from them, recommend matching the proxy to the country they are in right now, and ask which country that is. Apply their answer as proxy {source:"WebRun", country:"<2-letter code>"} everywhere that automation runs — the session (browser_task / create_session), the workflow, and a standalone scheduled agent (create_agent in workflow mode inherits the workflow proxy instead) — and keep that country stable so every later run looks like the same place. The browser clock follows the proxy country automatically (e.g. "de" → Europe/Berlin) — only set timezone when the user wants a different zone. If the user declines or does not know, continue without one and say so.