Why This Search Exists
Without adapters, teams execute the same browser jobs differently and lose track of which ones are safe to host versus which ones depend on local browser state.
This makes the browser layer harder to discover, document, and improve over time.
Recommended Approach
A site adapter model gives repeated jobs stable names, arguments, and execution mode that can be shared across CLI, MCP, and hosted surfaces.
iatlas-browser already follows this pattern through its site catalog and hosted subset.
Key Takeaways
- Adapters scale better than one-off scripts.
- Execution mode should be explicit in every adapter.
- Hosted adapters are for public remote-safe tasks.
- Session-aware adapters should stay local.
Fast Start
- Inventory the repeatable browser jobs your teams already use.
- Normalize names and arguments for those jobs.
- Separate hosted-safe jobs from local-only ones.
- Publish the resulting adapter catalog clearly.
Next Action
Browse adapters
Move from research to implementation by choosing the correct boundary: local runtime for real-session work, hosted API for public-safe retrieval.