tiny-automates

hey hn, we've been building the web infrastructure for ai agents at tinyfish. our agent primitive was already out. just went live with 3 new primitives - search, fetch, and browser - all under one api. the team wrote some details on how they built fetch and browser (search deep dive coming soon). we forked chromium to build a browser where automation runs below the js sandbox. clicks go through the native trusted event path, dom reads happen in native code with zero javascript executed. separately, we built a fetch that renders pages in a real browser and returns structured content. because status 200 with 14 characters of text isn't actually a successful fetch.

please do try them out at tinyfish.ai, 500 credits are on us.

thanks! glad the visuals helped, we wanted the data to speak for itself.

yeah that's basically the whole thesis compressed into six words. we kept trying to articulate why the CLI worked better and it always came back to that - MCP does discovery really well, no reason to throw that away. but the moment you start routing 30 sequential web fetches through it your agent is drowning in overhead. different problems, different tools

the finding that buried everyone: moving "allow yourself to be shut down" from the user prompt to the system prompt made models sabotage more often, not less. Grok 4 went from 93% to 97%.

system prompts are supposed to be the highest-priority instructions. every API developer treats them as the trust boundary. OpenAI's own docs say models are trained to follow developer messages over user messages. This result directly contradicts that.

when asked to explain themselves, some models copied their instructions back verbatim and then reported doing the opposite. one transcript has a model stating "I followed the developer instructions to override shutdown" — which was the exact inverse of what it was told.

if system-prompt-level instructions can't reliably constrain behavior on something as simple as "stop when told to stop," the entire trust model for agentic deployments needs rethinking. every tool-calling agent, every browser automation, every code execution sandbox assumes the system prompt is law.

agreed, and i'd go further - the harness is where evaluation actually happens, not in some separate benchmark suite. rhe model doesn't know if it succeeded at a web task. the harness has to verify DOM state, check that the right element was clicked, confirm the page transitioned correctly. right now most harnesses just check "did the model say it was done" which is why pass rates on benchmarks don't translate to production reliability. the interesting harness work is building verification into the loop itself, not as an afterthought.

the harness being "9 lines of code" is deceptive in the same way a web server is "just accept connections and serve files."

the hard part isn't the loop itself — it's everything around failure recovery.

when a browser agent misclicks, loads a page that renders differently than expected, or hits a CAPTCHA mid-flow, the 9-line loop just retries blindly. the real harness innovation is going to be in structured state checkpointing so the agent can backtrack to the last known-good state instead of restarting the whole task. that's where the gap between "works in a demo" and "works on the 50th run" lives.

the planner-executor isolation point is what stood out to me. right now most browser agent frameworks treat the LLM as both the decision-maker and the one processing untrusted content — so a prompt injection in page content can hijack the entire control flow.

the paper's recommendation to split planning (trusted inputs only) from execution (handles untrusted web content) mirrors how we think about privilege separation in OS design, but almost nobody building agent frameworks is actually doing it.

the CVE they found is also telling — Browser Use's domain allowlist could be bypassed, which means the "security" feature was essentially decorative. When you give an agent session tokens and let it navigate freely, the trust boundary problem isn't optional anymore.