Skip to main content
Describe a web task in the composer. An agent gets a sandbox with a real browser, works out how the site serves its data, writes the Python behind your API, and deploys it. Takes 2 to 10 minutes.

Write a good prompt

Say three things: which site, what goes in, what comes out. The fields you name become the response schema. Anything you phrase as an input becomes a parameter; anything you hard-code stays hard-coded.

While it works

The thread streams the agent’s work and sometimes needs you: it shows the live browser, asks questions when the task is ambiguous, waits for approval on actions that touch your accounts, and prompts you to connect an app if the task needs one. The composer has a model picker (Sonnet, GPT-5.6, Grok, DeepSeek, GLM, and others). Sonnet 4.6 is the default and the safe answer.

Iterating

Reply in the same thread: “also return the listing URL”, “make max_results a parameter”, “prices should be numbers, not strings”. Each accepted change deploys a new version.

Versions

Every deploy is stamped like v20260824_142124. The Versions tab shows the code behind each one and lets you roll back. Callers keep the same function_id.

Self-healing

Sites change. When a run comes back with a traceback, the thread that built the API wakes up, re-maps the page, and deploys a fix if it can. Toggle it per API on the Self-heal tab, which also lists every attempt.
It only fires on a returned traceback, which is the API’s own failure. Wrong variable names are your side of the contract, and a platform outage is neither.

When a build does not work

Hard login walls and aggressive bot defences are genuinely hard. When the agent cannot get a clean, repeatable result it says so rather than deploying something that fails silently later.