ahmadilaiwi

So LLMs are not bad at generating selectors but they always need a loop to test it in + rules to produce the best selectors. When you have an llm write a playwright script for example to scrape a product page on an e-commerce, while the agent is building the script, it will check the DOM and based on that, it will generate selectors that it put inside the "page.locator" calls. In theory the selectors look great but in practice, the agent will not first shot a working selector.. This can be for few reasons like: llms can't see the whole DOM (usually html DOMs are massive), another reason would be that the llm is not running a selector matching algorithm in it's head, very similar to you giving an llm complex math problem without giving it a calculator tool or a coding tool. To fix the selector problem, few things will happen, it will start adding more and more html attributes to match the target element and it will start filling the context with useless error messages that it only needed to fix the broken selectors.

Hi Arjun, our customers use Intuned for a wide range of use cases, the main ones being: govtech and insurance tech. In addition, agencies that specialize in scraping for their customers.

Our Intuned agent and Web Task API always use reverse engineering when possible — the underlying agents have access to the network layer and can reverse engineer APIs when needed. At the end of the day, this comes down to what the user needs. We have seen cases where users need data from the network, and in these cases we skip the browser layer. In some other cases, we saw that users need to authenticate via the browser but then all the automation can be done via the network. We have also seen customers who want to get markdown of the pages in addition to hitting the APIs so a browser layer is a must.

Salam, very interesting. curious why abstracting the code? For us, exposing code gives the user way more control and visibility about what's happening with their automations.