Skip to main content

Documentation Index

Fetch the complete documentation index at: https://intunedhq.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

This page explains what happens when you call the Web Tasks API—how the agent decides between AI and code, how reuseKey evolves over time, and the rules that govern concurrent runs.

​
Execution model

When you submit a task, Intuned spins up a browser on managed infrastructure, then runs an agent that mixes AI exploration with generated code. 
Submit task → load reusable code (if reuseKey)
            → agent explores / runs code
            → write or refine code (if reuseKey)
            → return result
  1. Load — if you provided a reuseKey, the system loads any code previously saved under that key. If you didn’t, the server mints a fresh wtr_-prefixed key and uses it for this run; the key comes back in reuse.key so you can reuse the same automation on later calls.
  2. Execute — the agent runs the task. If saved code exists and works, it is used directly. Otherwise the AI explores the site, decides which parts of the task benefit from being code, and writes that code as it goes.
  3. Save — on success, the improved code is saved under the key (whether you provided it or the server generated it). On failure, the previous code is left untouched so a bad run can’t poison a working automation.
  4. Return — the result is returned inline or as a file, along with reuse, cost, and timing metadata.
The first run for a new key is the “figuring it out” run: slower, more expensive, AI-heavy. Subsequent runs mostly execute saved code—fast, cheap, and consistent. The same applies when the site changes: the AI repairs the code, the next run is back to fast and cheap.

​
Model selection

Every run uses an Anthropic model, controlled by the model request field: haiku (default), sonnet, or opus. Heavier models help on harder tasks—ambiguous instructions, complex multi-step flows, fiddly extraction—at proportionally higher AI cost. Most repeat runs that just execute saved code work well with haiku.

​
Reuse rules

​
Same key, same automation

A reuseKey identifies one reusable automation. Two runs with the same key share code, regardless of startUrl or parameters: 
// Both runs use the same reusable automation: "companies"
{ "task": "Scrape YC companies",       "startUrl": "https://www.ycombinator.com/companies", "reuseKey": "companies" }
{ "task": "Scrape Wellfound companies", "startUrl": "https://wellfound.com/companies",      "reuseKey": "companies" }
If you want separate automations, use separate keys (yc_companies, wellfound_companies). The system does not create hidden per-URL memories.

​
Failed runs do not update code

If outcome is failed, reuse.updated is always false. A failed attempt cannot overwrite a working automation.

​
Same-key runs are serialized

Runs that share a reuseKey execute one at a time. This prevents two concurrent runs from updating the same code and overwriting each other. Runs with different keys—or no key at all—execute in parallel, subject to your workspace’s rate limits.

​
The reuse response

When you provide a reuseKey, the result includes a reuse object describing what happened to the saved code:
FieldMeaning
keyThe reuseKey you sent.
usedtrue if existing saved code was loaded and executed.
createdtrue if this run created the first saved code for this key.
updatedtrue if this run improved or repaired the saved code. Always false on failure.
revision_idID of the Web Task run whose code is currently saved under this key.
revision_timestampWhen the saved code was last updated.
Three common shapes: 
// First successful run for a new key
{ "reuse": { "key": "yc_companies", "used": false, "created": true,  "updated": true } }

// Later run, saved code worked as-is
{ "reuse": { "key": "yc_companies", "used": true,  "created": false, "updated": false } }

// Later run that repaired or improved the saved code
{ "reuse": { "key": "yc_companies", "used": true,  "created": false, "updated": true } }

​
Cost dynamics

Costs are reported per run as aiUsd (model spend) and compute.amount in hours. Expect cost to follow this shape:
  • First run for a key — high AI cost, longer compute.
  • Steady-state runs — low AI cost, short compute.
  • Repair runs — moderate AI cost when the saved code needs updating (for example, after a site change).
This is the central tradeoff Web Tasks make: pay AI cost up front to generate code, then amortize it across many cheap repeat runs.