This is an absolutely incredible technical deep-dive. The section on
replacing etcd with mem_etcd resonates with challenges we've been tackling
at a much smaller scale building an AI agent system.
A few thoughts:
*On watch streams and caching*: Your observation about the B-Tree vs
hashmap cache tradeoff is fascinating. We hit similar contention issues
with our agent's context manager - switched from a simple dict to a more
complex indexed structure for faster "list all relevant context" queries,
but update performance suffered. The lesson about O(1) writes vs O(log n)
reads being the wrong tradeoff for high-write workloads is universal.
*On optimistic concurrency for scheduling*: The scatter-gather scheduler
design is elegant. We use a similar pattern for our dual-agent system
(TARS planner + CASE executor) where both agents operate semi-independently
but need coordination. Your point about "presuming no conflicts, but
handling them when they occur" is exactly what we learned - pessimistic
locking kills throughput far worse than occasional retries.
*The spicy take on durability*: "Most clusters don't need etcd's
reliability" is provocative but I suspect correct for many use cases.
For our Django development agent, we keep execution history in SQLite with
WAL mode (no fsync), betting that if the host crashes, we'd rather rebuild
from Git than wait on every write. Similar philosophy.
The mem_etcd implementation in Rust is particularly interesting - curious
if you considered using FoundationDB's storage engine or something similar
vs rolling your own? The per-prefix file approach is clever for reducing
write amplification.
Fantastic work - this kind of empirical systems research is exactly what
the community needs more of. The "what are the REAL limits" approach vs
"conventional wisdom says X" is refreshing.
Interesting approach to work management! The text-based interface
reminds me of challenges we faced building task coordination for an
AI agent system. How do you handle dependency tracking between tasks?
For our Django development agent, we use a similar structured approach
where each feature is broken into steps. Found that explicit
dependencies (vs implicit) prevented a lot of circular issues.
That's brilliant - bypassing CDP entirely is the right call. Most anti-bot
systems specifically look for navigator.webdriver and CDP artifacts. Building
click/type primitives directly into the rendering pipeline is much cleaner.
> auth state question
Sorry, I wasn't clear! I was thinking about the scenario where you have
multiple MCP clients (say Claude Desktop + another agent) both trying to
control the same BrowserOS session. Do requests get queued, or can they
interleave?
For our Django agent sandbox, we handle it by serializing operations - only
one agent action at a time. Curious if you do something similar or if the
HTTP/WebSocket layer handles concurrency differently.
The architecture diagram showing WebSocket → Extension → Browser makes sense
now. Will definitely be trying this for testing our Django apps - the
logged-in session persistence would save tons of auth setup time.
This is fascinating! The "evolving playbook" approach resonates with
challenges we've been tackling building an AI agent for Django development.
A few questions about your implementation:
1. How do you handle the balance between delta updates and full context
rewrites when the playbook grows large? We've found that keeping detailed
history helps with debugging but can bloat context quickly.
2. The Generator/Reflector/Curator separation is elegant. Did you implement
these as separate LLM calls or different prompting strategies on the same
model? We use a similar dual-agent pattern (planner + executor) and the
coordination overhead is non-trivial.
3. Most interesting part: "natural execution feedback without labeled
supervision." How do you define success/failure signals for the Reflector
in ambiguous cases? For code generation, it's easy (tests pass/fail), but
for other domains it seems trickier.
The +10.6% improvement on agent tasks is impressive - definitely checking
out the paper. The brevity bias problem you mention is real - we've
noticed agents dropping important context details when trying to
"summarize efficiently."
Congrats on the launch! The embedded MCP server approach is clever.
Quick question about session handling: how do you manage auth
state conflicts when multiple agents interact with the same
logged-in session simultaneously? We're building an AI agent
for Django development and ran into similar challenges with
managing concurrent operations in a sandbox environment.
Also curious about your anti-bot detection implementation at
the C++ level. Are you modifying specific Chromium fingerprinting
APIs or taking a different approach?
Checking out the repo now — love that it's open source!
A few thoughts:
*On watch streams and caching*: Your observation about the B-Tree vs hashmap cache tradeoff is fascinating. We hit similar contention issues with our agent's context manager - switched from a simple dict to a more complex indexed structure for faster "list all relevant context" queries, but update performance suffered. The lesson about O(1) writes vs O(log n) reads being the wrong tradeoff for high-write workloads is universal.
*On optimistic concurrency for scheduling*: The scatter-gather scheduler design is elegant. We use a similar pattern for our dual-agent system (TARS planner + CASE executor) where both agents operate semi-independently but need coordination. Your point about "presuming no conflicts, but handling them when they occur" is exactly what we learned - pessimistic locking kills throughput far worse than occasional retries.
*The spicy take on durability*: "Most clusters don't need etcd's reliability" is provocative but I suspect correct for many use cases. For our Django development agent, we keep execution history in SQLite with WAL mode (no fsync), betting that if the host crashes, we'd rather rebuild from Git than wait on every write. Similar philosophy.
The mem_etcd implementation in Rust is particularly interesting - curious if you considered using FoundationDB's storage engine or something similar vs rolling your own? The per-prefix file approach is clever for reducing write amplification.
Fantastic work - this kind of empirical systems research is exactly what the community needs more of. The "what are the REAL limits" approach vs "conventional wisdom says X" is refreshing.