Automate browser busywork without writing a script
Browser busywork is repetitive web work that is tedious rather than difficult: filling the same form, checking a portal, processing a return, copying data between tabs. Twinly automates it by driving the page's DOM and accessibility tree directly, without recorded selectors or scripts, and stops for approval at every send, pay, or submit.
In short
- No scripts, no recorded selectors, and no brittle XPath to maintain.
- Twinly reads the live DOM, so a redesigned page does not break the task the way a coordinate-based recording does.
- It works in your existing logged-in browser sessions rather than a separate automated one.
- Irreversible controls — Submit, Pay, Send, Delete — are held for explicit approval.
- It refuses to type Social Security numbers, passwords, or card numbers into any field.
What browser busywork looks like
- Filling the same supplier or benefits form for the twentieth time this month.
- Checking a portal every morning to see whether a status changed.
- Starting a return: find the order, pick the reason, print the label.
- Copying rows between a web application and a spreadsheet.
- Comparing prices or availability across several sites and writing up the result.
None of this is hard. All of it is expensive, because it is measured in attention rather than difficulty.
Why screenshot-based agents break, and what Twinly does instead
A screenshot agent sees a picture of a page. To click a button it must infer, from pixels, where that button probably is. This fails in three predictable ways: the page changes and the coordinates are stale; a vision model misreads a small or low-contrast control; and every single step costs a vision model call, which is slow and adds up.
Twinly reads the page's structure instead of its picture. A button in the DOM has a label, a role, and a state, and those do not change when the layout does. Pixels remain available as the last rung of the ladder for surfaces that genuinely expose nothing else — but they are the fallback, not the default.
| Screenshot-driven agents | Twinly | |
|---|---|---|
| What it reads | An image of the page | The DOM and accessibility tree, with pixels as fallback |
| When the layout changes | Coordinates go stale | Labels and roles still resolve |
| Cost per step | A vision model call | No vision call when a structured channel is live |
| Irreversible clicks | Varies by product | Always held for approval |
What it will not do
- It will not click Submit, Pay, or Send on your behalf without approval.
- It will not type a Social Security number, password, or card number into a field.
- It cannot drive text-free 3D or WebGL canvases, such as CAD viewports, where no structured channel and no readable text exist.
- It does not solve CAPTCHAs or work around bot detection.
Common questions
How is this different from a browser automation tool like Selenium or Playwright?
- Those tools execute a script that a developer wrote and maintains, addressing elements by selector. Twinly is given a goal in plain language and works out the steps itself, reading the live DOM and accessibility tree each time rather than replaying fixed selectors. No code is written or maintained.
Does it work on sites that require a login?
- Yes. Twinly works in your existing browser sessions, so anywhere you are already signed in is reachable without granting a separate integration.
What happens when a website changes its layout?
- Because Twinly resolves controls by their label and role in the DOM or accessibility tree rather than by screen position, a visual redesign generally does not break the task the way a coordinate recording or a pixel-based agent does.
Can it check out or pay automatically?
- No. Payment and other irreversible controls are held for explicit approval, and Twinly will not enter card numbers into a field at all.