Playwright
The default browser worker for normal automation, QA journeys, screenshots, and cross-browser compatibility.
- Chromium, Firefox, and WebKit are selectable.
- Best first choice for predictable browser work.
- Clean local development baseline.
Technology
Plug-and-play browser tools behind one workflow.
Layer 8 is the control plane for browser work. Playwright, Camoufox, Lightpanda/CDP, hosted browsers, search APIs, and direct fetch tools can be plugged in behind the same workflow without changing what the customer sees.
Stable interface
- Resolve the right page, listing, account, document, or portal surface.
- Operate through the cheapest truthful tool that can complete the job.
- Return screenshots, observations, confidence, run notes, and reusable memory.
Runtime choices
- Playwright for predictable browser automation and QA.
- Camoufox for bot-sensitive retail and marketplace surfaces.
- Remote CDP, hosted browsers, search APIs, and direct fetch for specialized cases.
Plug-and-play tools
The browser engine is a worker choice, not the product.
Layer 8 keeps the workflow contract stable: launch or fetch, navigate, observe, act, screenshot, close, and write evidence. New tools can be added as workers under that contract.
Camoufox
A heavier plug-in worker for harder commerce pages where standard automation gets different page behavior.
- Useful for bot-sensitive Korean retail surfaces.
- Runs separately from the dashboard.
- Used only when the source needs it.
CDP and hosted browsers
Remote CDP endpoints, hosted browsers, and browser APIs can sit behind the same Layer 8 run model.
- Good fit for scaling browser sessions.
- Can be swapped without changing customer workflows.
- Keeps evidence and memory in the Layer 8 layer.
Search and fetch
Not every job needs a full browser. Search, direct fetch, and extraction APIs stay available as lighter tools.
- Cheaper for public discovery and simple reads.
- Useful before escalating to a full browser.
- Still writes source evidence into the run.
Specialized scrapers
Retailer or platform-specific APIs can be plugged in when they are more reliable than browser inspection.
- Naver, marketplace, and retailer-specific access can be routed as tools.
- The product still shows source, confidence, and review state.
- Browser fallback remains available for exceptions.
Future workers
The system is built so the tool layer can change while the customer-facing evidence workflow remains stable.
- Add a worker when a new source requires it.
- Keep product logic above vendor-specific runtime behavior.
- Preserve run history across tool changes.
Architecture
Three layers keep the system practical.
The architecture is intentionally legible. Tooling, product behavior, and evidence storage are separate so the execution layer can improve without distorting the operator surface.
Discovery layer
Resolve the right browser surface before the system tries to act with confidence.
- Search public sources and rank candidate pages.
- Keep domains, listings, and titles visible as evidence.
- Make ambiguity explicit instead of hiding it.
Execution layer
Use the lightest truthful tool first, then escalate only when the source demands more.
- Public-web discovery and extraction for easy cases.
- Configurable browser engines for JavaScript-heavy or bot-sensitive pages.
- Stable application behavior above a changing runtime stack.
Evidence layer
Every meaningful result should point back to the page, the field, and the run that produced it.
- Observations stored with timestamps and provenance.
- Screenshots and run ledgers attached to the answer.
- Memory that compounds across repeated tasks.
Surface 1
Public site
Explains why Layer 8 is the Layer 8 of the OSI model and what computer user agents should do.
Surface 2
Computer user agents
Takes a generic task and runs it with visible actions, logs, and evidence.
Surface 3
Shaped workflows
Price Check, Brand Protection, and Site Diff show how the same agent layer can be packaged in different ways.