We built a very early prototype: a Browser-Agent/browser-automation runtime using Kotlin/JVM and raw CDP. Before investing further, we’d like advice from anyone who has worked on browser agents, AI browsers, large-scale automation, crawling, browser farms, or who has deep knowledge of Chromium/CDP.
We ourselves suspect many of our design assumptions may be flawed, so sharp criticism is very welcome.
---
TL;DR
We’re building an open-source runtime:
• AI planning/reasoning/logic lives on the JVM
• Browser actions are driven via raw CDP
• High concurrency via Kotlin coroutines
• A small ML agent learns page structure
But we’re not sure any of this is actually meaningful. Feedback—especially negative feedback—is appreciated.
---
1. JVM + CDP: possibly the wrong abstraction layer
AI planning/reasoning/logic is on the JVM; browser actions are sent through CDP.
Some doubts we cannot resolve internally:
• Is the JVM too heavy for this domain? Will GC and scheduling cause tail latency?
• Is CDP inherently unsuitable for high-throughput automation?
• Does nobody actually need a JVM-native browser agent?
• Would Go/Node/Python be more sensible choices?
If the answer is “no, this is the wrong direction,” we’d really like to hear it.
---
2. High-concurrency runtime: likely to fall apart in real workloads
We’re trying to push single-machine throughput on real, complex pages by relying on:
• Kotlin coroutines
• Minimizing DevTools round-trips
• Raw CDP with multi-tab concurrency
But our doubts are even larger:
• Can Chromium realistically survive this scale?
(render-process contention, GPU-thread limits, compositor stalls, etc.)
• Are multi-tab workloads doomed to event interference, reordering, and deadlocks?
• Will CDP scheduling become the true bottleneck?
• Is raw CDP unavoidably more brittle than Playwright?
If you’ve seen similar attempts fail, we’d especially like to know how they failed.
---
3. Non-LLM page-structure learning: probably not generalizable
We built a small ML module to avoid calling an LLM every time we parse HTML.
It works well on e-commerce pages, but we strongly suspect it will break elsewhere.
Concerns:
• Will it fail outright on news, forums, SaaS dashboards, and other domains?
• Has anyone built DOM-structure-learning systems and then abandoned them? Why?
• Is the long tail of the web fundamentally hostile to non-LLM approaches?
Failure stories are particularly valuable.
---
4. Some questions we have zero confidence about
• Does the world actually need yet another browser-automation stack?
• Do “Browser Agents” have long-term practical value at all?
• Do coroutine-style concurrency models provide real benefits under heavy CDP I/O?
• Should we drop the “agent” layer entirely and just build a runtime?
• What fatal issues exist around resource isolation, multi-tenancy, event storms, or long-tail page behaviors?
• Do all high-concurrency browser runtimes eventually die for the same reasons?
If the answer is “yes, stop now,” we’d prefer to know early.
---
Prototype status
We’ll open-source a very early version (missing docs, missing examples, and possibly flawed designs).
Known issues include:
• Deadlocks on certain complex sites that are hard to reproduce
• CDP event reordering under high concurrency
• Worse-than-expected memory behavior
• Structure-learning module is inaccurate on non-e-commerce pages
If you’ve built systems with heavy browser interaction, automation, data extraction, or treating the browser as a runtime, we’d love to hear about the bottlenecks you hit—so we don’t optimize toward the wrong direction.
---
Finally
Any single sentence of criticism may save us months.
We built a very early prototype: a Browser-Agent/browser-automation runtime using Kotlin/JVM and raw CDP. Before investing further, we’d like advice from anyone who has worked on browser agents, AI browsers, large-scale automation, crawling, browser farms, or who has deep knowledge of Chromium/CDP.
We ourselves suspect many of our design assumptions may be flawed, so sharp criticism is very welcome.
---
TL;DR
We’re building an open-source runtime:
• AI planning/reasoning/logic lives on the JVM
• Browser actions are driven via raw CDP
• High concurrency via Kotlin coroutines
• A small ML agent learns page structure
But we’re not sure any of this is actually meaningful. Feedback—especially negative feedback—is appreciated.
---
1. JVM + CDP: possibly the wrong abstraction layer AI planning/reasoning/logic is on the JVM; browser actions are sent through CDP.
Some doubts we cannot resolve internally:
• Is the JVM too heavy for this domain? Will GC and scheduling cause tail latency?
• Is CDP inherently unsuitable for high-throughput automation?
• Does nobody actually need a JVM-native browser agent?
• Would Go/Node/Python be more sensible choices?
If the answer is “no, this is the wrong direction,” we’d really like to hear it.
---
2. High-concurrency runtime: likely to fall apart in real workloads
We’re trying to push single-machine throughput on real, complex pages by relying on:
• Kotlin coroutines
• Minimizing DevTools round-trips
• Raw CDP with multi-tab concurrency
But our doubts are even larger:
• Can Chromium realistically survive this scale?
(render-process contention, GPU-thread limits, compositor stalls, etc.)
• Are multi-tab workloads doomed to event interference, reordering, and deadlocks?
• Will CDP scheduling become the true bottleneck?
• Is raw CDP unavoidably more brittle than Playwright?
If you’ve seen similar attempts fail, we’d especially like to know how they failed.
---
3. Non-LLM page-structure learning: probably not generalizable
We built a small ML module to avoid calling an LLM every time we parse HTML.
It works well on e-commerce pages, but we strongly suspect it will break elsewhere.
Concerns:
• Will it fail outright on news, forums, SaaS dashboards, and other domains?
• Has anyone built DOM-structure-learning systems and then abandoned them? Why?
• Is the long tail of the web fundamentally hostile to non-LLM approaches?
Failure stories are particularly valuable.
---
4. Some questions we have zero confidence about
• Does the world actually need yet another browser-automation stack?
• Do “Browser Agents” have long-term practical value at all?
• Do coroutine-style concurrency models provide real benefits under heavy CDP I/O?
• Should we drop the “agent” layer entirely and just build a runtime?
• What fatal issues exist around resource isolation, multi-tenancy, event storms, or long-tail page behaviors?
• Do all high-concurrency browser runtimes eventually die for the same reasons?
If the answer is “yes, stop now,” we’d prefer to know early.
---
Prototype status
We’ll open-source a very early version (missing docs, missing examples, and possibly flawed designs).
Known issues include:
• Deadlocks on certain complex sites that are hard to reproduce
• CDP event reordering under high concurrency
• Worse-than-expected memory behavior
• Structure-learning module is inaccurate on non-e-commerce pages
If you’ve built systems with heavy browser interaction, automation, data extraction, or treating the browser as a runtime, we’d love to hear about the bottlenecks you hit—so we don’t optimize toward the wrong direction.
---
Finally
Any single sentence of criticism may save us months.
— Browser4 Team