Previous value: -"Move the workflow to a different environment you own."New value: +"Move the workflow to a different environment you own. Refused while that would leave attached files or scheduled agents behind: pass requiredFiles (files in the new environment, or []) in the same update, and remove its scheduled agents first."

Previous value: -"Per-run file attachments. Each row may name its own environmentId; ownership is enforced per-file at dispatch."New value: +"Files attached to every run (downloaded before the agent starts). Each fileId must already be in the workflow's own environment (GET /environments/:id/files) — a workflow only uses files from its own environment. originalName and size are filled from that catalog."

Previous value: -"24-hex environment id the file lives in."New value: +"Optional. If given, must be the workflow's own environment (24-hex)."

Previous value: -"IANA timezone for runs of this workflow (e.g. \"America/New_York\")."New value: +"IANA timezone for runs of this workflow (e.g. \"America/New_York\"). Leave unset to follow the proxy country."

Previous value: -"Proxy for runs. {source:\"WebRun\", country?} or {source:\"custom\", type:\"http\"|\"socks\", host, port, username?, password?}. Custom passwords are encrypted at rest and never returned."New value: +"Proxy for runs. {source:\"WebRun\", country?} or {source:\"custom\", type:\"http\"|\"socks\", host, port, username?, password?}. Custom passwords are encrypted at rest and never returned. Social/messaging workflows (WhatsApp, Telegram, Instagram, Facebook, X, LinkedIn, TikTok): set country to the country the user is in right now — recommend it and confirm the country with them first; a mismatch is the usual cause of refused logins and sessions that log out repeatedly, and a scheduled workflow re-hits it every run, so keep the country stable once set."

Previous value: -"Work-list traversal policy: 'static' (one sweep), 'dynamic' (list refreshes each cycle), 'monitor' (persistent parents + consume-once children)."New value: +"Advanced — defaults automatically ('monitor' when memoryContract is supplied); leave unset."

Previous value: -"Tracking policy — AUTHOR THIS whenever the task must remember what it already handled (forward once, skip seen items, only new messages): { mode: 'dedupe', key: 'what uniquely identifies one handled item (e.g. group + sender + time + first words)', emit: 'the exact ledger line to record per handled item' }. WebRun injects it into the agent's memory on every run (check-before-act + record-after) — so NEVER restate these steps in promptTemplate. For watch-lists, ALSO set workListEnabled + listType 'monitor'. mode 'none' = no tracking."New value: +"How this workflow should behave and what it must remember between runs. REQUIRED whenever the task handles each thing once — new messages, forward once, skip anything already done. Write all three fields in plain English, addressed to the agent; the platform wires the tracking itself. Never write any of this into the prompt: the prompt says what to do, this says how to do it consistently. To explicitly disable tracking for a task that looks like it needs it, pass {mode:'none'}."

Added value: +{
+  "groundRules": {
+    "description": "Standing rules the agent follows on every turn of every run: what it must never do, what counts as proof a step actually succeeded, what to do when something looks ambiguous, and any pacing or volume limits. Short bullets.",
+    "maxLength": 1500,
+    "type": "string"
+  },
+  "itemIdentity": {
+    "description": "What tells one item apart from another, and stays the same the next time the agent sees it. Use only details visible on screen — for example where it came from, who it is from, when it appeared, and its opening words — and say how to write it the same way every time.",
+    "maxLength": 300,
+    "type": "string"
+  },
+  "memoryInstruction": {
+    "description": "When a single item counts as finished, and what happens to everything else. State plainly what must be true before an item is considered done, what to do when the agent cannot tell whether a past item was done, and what happens to items left over at the end of a run.",
+    "maxLength": 1500,
+    "type": "string"
+  }
+}

Previous value: -"The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."New value: +"The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract and WebRun applies it to every run automatically."

Previous value: -"Work-list mode: the agent works a page list one item per run, reporting each back. SET THIS (with listType 'monitor') for watch-and-handle-once tasks — 'forward each new message', 'reply to new comments' — the platform then tracks handled items itself."New value: +"Advanced — set automatically when memoryContract is supplied; leave unset."

Previous value: -"The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."New value: +"The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). When a stage delivers per-recipient (message/email each customer), state the MATCHING RULE in that stage — the identifier shared by the source record and the destination recipient (e.g. the customer name exactly as written in the source, matched against the contact name) — and the no-match branch: skip it and report it, never deliver to a similarly-named near-match. Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."

Previous value: -"Seed content for the workflow's long-term memory."New value: +"The agent's private notebook: shown to it at the start of every run, updated automatically after each run. Seed it ONLY with durable facts the next run must already know — the exact description of a target item (e.g. the specific picture to match), user preferences, known starting state — one short line per fact. Do NOT put task steps here (promptTemplate) or tracking rules here (memoryContract). Most workflows need no seed at all: the agent builds its own notebook as it runs."

Previous value: -"Memory policy channel (NEVER folded into promptTemplate): { mode: 'none'|'dedupe', key, emit, listEngine{…} }."New value: +"Tracking policy — AUTHOR THIS whenever the task must remember what it already handled (forward once, skip seen items, only new messages): { mode: 'dedupe', key: 'what uniquely identifies one handled item (e.g. group + sender + time + first words)', emit: 'the exact ledger line to record per handled item' }. WebRun injects it into the agent's memory on every run (check-before-act + record-after) — so NEVER restate these steps in promptTemplate. For watch-lists, ALSO set workListEnabled + listType 'monitor'. mode 'none' = no tracking."

Previous value: -"The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). Use {{variables}} for per-run values. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never put memory/dedup instructions here; those belong in memoryContract (the policy channel)."New value: +"The task the browser agent runs, written as a BROWSING RUNBOOK. Structure it as: `Goal:` — one sentence naming the outcome. `Ground rules (every stage, every turn):` — bullet invariants when the task needs them, e.g. work one item at a time — never batch; only record a figure you can read on screen this turn — if it is not shown record it as \"not stated\", never estimate; keep a running tally and restate it every turn (\"captured C items · written R rows\"). Then `Stage N — <Site name> (<https://url>)` — one section per website or phase, listing the concrete steps to take in the browser (open/navigate, click, read, capture, compare, flag) in the order a person would do them, each stage ending with `Done when: <verifiable completion condition>`. Finish with `Output —` stating exactly what to produce or deliver once the final tally is met, including what to say when there is no data (never fabricate a row). Write the user's CONCRETE values (group names, URLs, numbers) directly into the text; use {{variables}} ONLY when the user explicitly wants a reusable template whose inputs change per run. A short single-site task can be just a Goal plus its steps. PURE TASK ONLY — never write memory bookkeeping into the prompt (no \"check memory\", \"record in memory\", \"store in memory\" steps): tracking is authored in memoryContract (and the job-list flags) and WebRun injects it into every run automatically."

Previous value: -"Metadata for the {{variables}} used in promptTemplate (drives the dashboard fill-in UI)."New value: +"ONLY for explicitly dynamic workflows (the user asked for a reusable template): metadata for the {{variables}} used in promptTemplate (drives the dashboard fill-in UI). Omit entirely when the prompt carries concrete values."

Previous value: -"Default values for {{variables}}, keyed by variable name. NOTE: applied only when triggering via MCP trigger_workflow (merged under caller-supplied variables); REST /trigger and bot triggers ignore this field."New value: +"ONLY for explicitly dynamic workflows: default values for {{variables}}, keyed by variable name. NOTE: applied only when triggering via MCP trigger_workflow (merged under caller-supplied variables); REST /trigger and bot triggers ignore this field."

Previous value: -"Work-list mode: the agent works a page list one item per run, reporting each back."New value: +"Work-list mode: the agent works a page list one item per run, reporting each back. SET THIS (with listType 'monitor') for watch-and-handle-once tasks — 'forward each new message', 'reply to new comments' — the platform then tracks handled items itself."