Show HN: Libretto – Making AI browser automations deterministic
Hacker News (score: 49)Description
Here’s a demo: https://www.youtube.com/watch?v=0cDpIntmHAM. Docs start at https://libretto.sh/docs/get-started/introduction.
We spent a year building and maintaining browser automations for EHR and payer portal integrations at our healthcare startup. Building these automations and debugging failed ones was incredibly time-consuming.
There’s lots of tools that use runtime AI like Browseruse and Stagehand which we tried, but (1) they’re reliant on custom DOM parsing that's unreliable on older and complicated websites (including all of healthcare). Using a website’s internal network calls is faster and more reliable when possible. (2) They can be expensive since they rely on lots of AI calls and for workflows with complicated logic you can’t always rely on caching actions to make sure it will work. (3) They’re at runtime so it’s not interpretable what the agent is going to do. You kind of hope you prompted it correctly to do the right thing, but legacy workflows are often unintuitive and inconsistent across sites so you can’t trust an agent to just figure it out at runtime. (4) They don’t really help you generate new automations or help you debug automation failures.
We wanted a way to reliably generate and maintain browser automations in messy, high-stakes environments, without relying on fragile runtime agents.
Libretto is different because instead of runtime agents it uses “development-time AI”: scripts are generated ahead of time as actual code you can read and control, not opaque agent behavior at runtime. Instead of a black box, you own the code and can inspect, modify, version, and debug everything.
Rather than relying on runtime DOM parsing, Libretto takes a hybrid approach combining Playwright UI automation with direct network/API requests within the browser session for better reliability and bot detection evasion.
It records manual user actions to help agents generate and update scripts, supports step-through debugging, has an optional read-only mode to prevent agents from accidentally submitting or modifying data, and generates code that follows all the abstractions and conventions you have already in your coding repo.
Would love to hear how others are building and maintaining browser automations in practice, and any feedback on the approach we’ve taken here.
More from Hacker
Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens
Show HN: Lowfat – pluggable CLI filter that saved 91.8% of my LLM tokens Hi HN,<p>Not sure if anyone would be interested.<p>But, just wanted to share that I've been maintaining my small tool called 'lowfat' that helps me filters some of my verbose CLI output.<p>It's a single binary, works as an agent hook or a shell wrapper. It has a plugin system to customize filters per command.<p>The idea is pretty simple: agents don't need the full kubectl get -o yaml or any 10k-line dump to make decisions. So that lowfat sits in between, strips the noise, and passes through what matters.<p>Here's my real report after 2 months of personal use:<p>lowfat history --all<p><pre><code> lowfat plugin candidates ───────────────────────────────────────────────────────── # command runs avg raw cost savings source status 1 kubectl get 101x 14.4K 1.5M 93.9% plugin good 2 grep 103x 13.5K 1.4M 96.2% plugin good 3 git diff 81x 995 80.6K 57.9% built-in good 4 kubectl 90x 485 43.6K 33.6% plugin good 5 docker 127x 5.5K 693.6K 96.1% built-in good 6 ls 489x 117 57.3K 56.2% built-in good 7 find 30x 16.5K 495.0K 95.5% plugin good 8 git show 63x 490 30.9K 38.0% built-in good 9 git 177x 368 65.2K 76.1% built-in good 10 git log 86x 556 47.8K 78.5% built-in good 11 kubectl logs 5x 3.6K 17.8K 43.0% plugin good 12 git status 86x 152 13.1K 58.0% built-in good 13 docker ps 20x 467 9.3K 52.8% plugin good 14 kubectl describe 6x 656 3.9K 1.2% plugin weak 15 docker images 9x 940 8.5K 61.8% built-in good 16 k get 2x 2.1K 4.2K 35.9% plugin good 17 terraform 10x 395 3.9K 32.1% plugin good 18 git commit 32x 77 2.5K 0.0% built-in weak 19 docker build 8x 487 3.9K 37.6% built-in good 20 docker compose 22x 979 21.5K 89.4% built-in good total: 4.4M raw → 4.1M saved (91.8%) </code></pre> My toolset above is kind limited, but it works pretty well for my usecase without any interruption Kinda help me not reaching the token limit for my company Bedrock limit usage and keep optimizing the saving on the go for later usage.<p>But, why not alternatives (<a href="https://github.com/zdk/lowfat#alternatives" rel="nofollow">https://github.com/zdk/lowfat#alternatives</a>) ? The answers are: - My goal is to make the core lightweight but extensible via plugins i.e. not trying to bundle every command in the installed binary so that people own their output filters. - Customizable per usecase via plugin or filter pipelines as I am using my own toolset. - Customizable for non-public CLI tools, for example, some enterprise might have their interal CLI tools that public won't have access. - People should own their data. So the design is local-first, No telemetry forever. - I kinda love UNIX-style composible pipes, so lowfat-filter has implemented this style. - Be able to adjust aggressiveness of the filter, so we can control that we won't strip something the agent needed.<p>GitHub: <a href="https://github.com/zdk/lowfat" rel="nofollow">https://github.com/zdk/lowfat</a><p>Anyway, if anyone is interested, feedbacks and questions are welcome!<p>Thanks!
No other tools from this source yet.