AI Browser Stack
A self-evolving browser-automation stack: feedback kernel + high concurrency + a flywheel (distill → gate → promote → evolve).
- Role
- Architect
- Year
- 2026
- Stack
- PythonPlaywrightLLM
Most browser-automation scripts are built on brittle selectors and fixed wait times: the moment a page redesigns or an anti-bot policy tightens, a batch of tasks fails at once, and it's hard to tell whether the cause was a network blip, a ban, or a structural change. Push concurrency up and dozens or hundreds of instances start competing for resources and dragging down each other's ban rates, with manual triage cost rising almost linearly with concurrency.
At the center is a feedback kernel: before every action it checks a perception cache for page state, and right after acting it runs a state verification — a failed check fails the whole task closed instead of letting it carry on as though the step had succeeded. The orchestration layer splits concurrency into 64 independent workers, each behind its own anti-block proxy pool, with the kernel deciding which workers are healthy and which get pulled and restarted. Experience isn't thrown away after one run: every run's trace is distilled into candidate strategies, and each candidate has to clear a gate — scored against a historical baseline — before it's promoted into the live strategy store, which evolves as a whole. The flywheel lets the system update its own playbook as real sites change, instead of relying on someone to rewrite selectors by hand.
The orchestration layer holds 64 concurrent workers steady through a 24-hour stress test with no abnormal restarts. Feedback-kernel verification paired with the proxy pool brings task survival over that same 24-hour window to 94.6%. Distilled candidates clear the gate and get promoted at an average of 37 strategies a week. After 8 flywheel iterations, task success rate is up 21.4 percentage points over the initial baseline.
Whether the system gets stronger doesn't depend on how many new rules I write — it depends on whether the feedback kernel honestly records every failure and whether the gate actually filters for strategies that work. Proxy-pool coverage and the gate's baseline are both still being expanded; the longer the flywheel turns, the less manual intervention it should need, not more.
Highlights
- High-concurrency, anti-blocking, self-evolving
- Feedback kernel: perception cache + state verification + fail-closed
- Flywheel loop turns each run's experience into reusable strategy

