Ask Knox

Introduction

"Browser agent" sounds intimidating. It sounds like it requires a team of engineers, a cluster of servers, and months of development. It doesn't. A browser skill is a small, focused unit of work that does exactly three things: navigate to a page, read data from it, and optionally take an action.

That's it. Navigate, read, act. Every browser automation task in existence is some combination of these three .

Understanding this loop changes how you think about what's buildable and what's worth building. Once you see it, you'll start spotting browser skill opportunities everywhere — any time you're manually loading a page to pull data, you're doing a job that a browser skill could do instead.

Core Concept

The Navigate-Read-Act Loop

Navigate means going to a URL. This could be a simple direct URL (https://example.com/pricing), or it could involve a sequence of navigation steps: go to the search page, type a query, click search, wait for results, navigate to the first result. Navigation is stateful — the agent remembers where it is and can move through a site step by step.

Read (Extract) means pulling data from the page's content. This is where the value lives. The agent looks at the page — its text, its HTML structure, the links it contains — and extracts specific data according to the skill's instructions. "Give me the title, author, and publication date of each article on this page" is a read instruction. The result should be structured: a list of objects, not a wall of prose.

Act means doing something on the page: clicking a button, filling a form field, submitting a form, downloading a file. Action steps are used when you need to interact with a site rather than just read it. Logging into an account before scraping, clicking "load more" to surface paginated results, or submitting a search query are all action steps.

Most skills for beginners are navigate-and-read only — no actions required. Start there. Once you're comfortable with extraction, adding action steps is straightforward.

What Structured Output Looks Like

Here's a concrete example. You want to pull recent articles from a blog. A browser skill navigating that site might return something like this:

{
  "source": "competitor-blog.com",
  "extracted_at": "2026-05-30T07:00:00Z",
  "articles": [
    {
      "title": "How We Reduced API Latency by 40%",
      "url": "https://competitor-blog.com/posts/api-latency",
      "published_date": "2026-05-28",
      "excerpt": "We replaced synchronous polling with a webhook-driven approach..."
    },
    {
      "title": "Our Approach to On-Call Engineering",
      "url": "https://competitor-blog.com/posts/on-call",
      "published_date": "2026-05-25",
      "excerpt": "When an alert fires at 2 AM, here's what happens next..."
    }
  ]
}

This is what "structured output" means. Not a paragraph that says "The competitor blog has two recent posts. One is about API latency..." — that requires another AI step to parse, which costs time, tokens, and introduces failure modes. The JSON is directly usable by the next step in your pipeline. It's a .

Installing a Community Browser Skill

Community browser skill libraries publish collections of pre-built skills, each targeting a specific site or task type. The browse.sh project, for example, maintains 274+ skills covering research, news, professional networks, and more. Skills are typically installable via a CLI:

npm install -g browse
browse skills add competitor-blog-extractor

When you run the skill, you pass it the URL and any parameters the skill accepts. It returns structured JSON. No HTML parsing, no CSS selectors, no custom code — the skill handles all of that.

The architecture win: when the site changes its HTML and the skill breaks, the community fixes it. You pull the update and the skill works again. Compare this to a custom scraper you wrote — when the site changes, you're the one debugging CSS selectors at midnight.

Practical Application

Here's a real extraction scenario you can reason through concretely.

Task: You want to pull the job titles and companies from the first page of LinkedIn search results for "AI product manager" — for market research, not spam.

Navigate step: The skill navigates to the LinkedIn jobs search page, types "AI product manager" into the search field, and submits the search.

Read step: The skill extracts the following fields from each result: job title, company name, location, and the relative posting date ("3 days ago").

Output:

{
  "query": "AI product manager",
  "results_count": 25,
  "jobs": [
    {
      "title": "Senior AI Product Manager",
      "company": "Stripe",
      "location": "San Francisco, CA",
      "posted": "2 days ago"
    },
    {
      "title": "Product Manager, AI Platform",
      "company": "Notion",
      "location": "New York, NY",
      "posted": "4 days ago"
    }
  ]
}

From here, you could pass this JSON to a summarization step, store it in a database, compare it to last week's results, or generate a trend report. The data is clean and machine-readable because the skill was designed to produce structured output.

Common Mistakes

Asking the browser skill to summarize or analyze. Browser skills should extract. Analysis is a separate step, using a language model. Mixing extraction and analysis in one skill makes it harder to debug and less reusable. Keep extraction clean and let downstream steps handle interpretation.

Ignoring pagination. Many pages show 10-25 results at a time. If you want comprehensive data, your skill needs to handle "load more" or navigate through multiple pages. Beginners often miss this and wonder why they're only getting a partial picture.

Not checking if a community skill exists first. The instinct is to write a custom scraper. Check the community library first. A maintained skill almost always exists for common sites, and it's better than anything you'll write in 20 minutes.

Extracting text when you need structure. "Pull the articles from this page" returning a block of text is not useful for automation. Every extraction prompt should specify the output schema: what fields, what types, what format. If you're not getting structured JSON, the skill isn't finished.

Summary

Every browser skill is a navigate-read-act loop — the three primitives that compose all browser automation
Structured JSON output is what makes browser skills composable — it's the contract between Layer 3 (skills) and Layer 4 (orchestration)
Community-maintained skill libraries give you pre-built, maintained skills for common sites — use them before building custom
Keep skills focused: extract, don't analyze; analysis is a downstream step
Check for pagination — many sites show partial data on the first page

What's Next

You've seen what a browser skill does and how it returns structured data. In the next lesson, we'll make the case for community skills over custom scrapers — and why the maintenance model of a community library is a structural architectural advantage, not just a convenience.

Your First Browser Skill