Building for Every AI Agent: Cross-Platform Compatibility

February 15, 2026

The AI browser agent landscape is fragmented. Claude Computer Use works differently from Browser Use, which works differently from Stagehand, which works differently from Playwright MCP. Each agent has its own architecture, its own way of controlling the browser, and its own conventions for skill files.

If you write automation logic for one agent, it does not run on the others. That fragmentation is a problem for everyone: developers lock into a single agent, skills cannot be shared across teams that use different tools, and the ecosystem as a whole moves slower than it should.

SiteSkills solves this with a skill format that is deliberately agent-agnostic. A single skill works across every supported agent without modification. This post explains how that works, which agents are supported today, and how to write skills that maximize compatibility.

The Key Insight: Instructions, Not Code

Most browser automation frameworks are code-first. You write a Playwright script, a Puppeteer function, or a Selenium test. That code is tightly coupled to a specific runtime, a specific language, and a specific browser control mechanism.

SiteSkills skills are not code. They are structured Markdown instructions -- step-by-step navigation flows that describe what to do, not how to do it at the API level. The agent reads the instructions and translates them into its own native actions.

This is the same pattern that makes recipes work across kitchens. A recipe does not specify which brand of stove to use or what programming language the oven firmware is written in. It says "preheat to 375 degrees" and trusts the chef to figure out the rest.

The SiteSkills template format is a superset of Anthropic's SKILL.md standard, which means any agent that understands SKILL.md can consume SiteSkills skills natively. The additional metadata in siteskills.json enhances discoverability and provides structured data for the marketplace, but it is not required for execution.

Supported Agents

SiteSkills currently supports four agent platforms, with more on the roadmap.

Claude Computer Use (Claude Cowork)

Claude Computer Use is Anthropic's native browser agent capability. When paired with Claude Cowork (the desktop application), it reads skills from the .claude/skills/ directory.

How it discovers skills: Claude Cowork scans the skills directory on startup and indexes the triggers from each SKILL.md frontmatter. When a user's request matches a trigger, Claude loads the full SKILL.md and follows the navigation flow.

Install path: .claude/skills/<skill-name>/

What works well: Claude excels at interpreting natural language instructions. DOM hints with text fallbacks and ARIA labels work particularly well because Claude can reason about page semantics, not just CSS selectors.

siteskills install amazon-add-to-cart --agent claude-cowork

Browser Use

Browser Use is an open-source Python framework for building browser agents. It uses Playwright under the hood and provides a high-level API for defining agent behavior.

How it discovers skills: Browser Use loads skills from a configured skills_dir. Skills are matched by domain and trigger phrases when the agent processes a user request.

Install path: ./skills/<skill-name>/

What works well: Browser Use has robust element detection. Skills with precise CSS selectors in the DOM hints section perform particularly well. The framework's built-in retry logic complements the fallback instructions in SKILL.md.

siteskills install amazon-add-to-cart --agent browser-use

Stagehand

Stagehand is a TypeScript framework by Browserbase that provides AI-powered browser actions. It uses an act and extract paradigm where the AI determines how to interact with elements based on natural language descriptions.

How it discovers skills: Skills are loaded programmatically or referenced in the agent configuration. Stagehand's act() function can interpret the action descriptions from SKILL.md navigation steps directly.

Install path: Configurable, typically ./stagehand/<skill-name>/

What works well: Stagehand's AI-powered element detection means it can interpret the Goal and Action descriptions from SKILL.md without relying heavily on CSS selectors. This makes skills more resilient to DOM changes when running on Stagehand.

siteskills install amazon-add-to-cart --agent stagehand

Playwright MCP

Any agent that connects to a Playwright Model Context Protocol (MCP) server can use SiteSkills skills. The MCP server provides browser control primitives, and the agent uses SKILL.md as a navigation guide.

Install path: Configurable.

siteskills install amazon-add-to-cart --dir ./my-skills/

How the Skill Manifest Ensures Compatibility

The compatibility section in siteskills.json serves two purposes: it tells users which agents a skill has been tested with, and it provides agent-specific metadata that can influence behavior.

{
  "compatibility": {
    "agents": [
      {
        "name": "claude-cowork",
        "min_version": null,
        "notes": "Works with default Cowork settings"
      },
      {
        "name": "browser-use",
        "min_version": "0.3.0",
        "notes": "Requires Playwright backend"
      },
      {
        "name": "stagehand",
        "min_version": "3.0.0",
        "notes": "Leverage auto-caching for repeated runs"
      }
    ],
    "requires_auth": true,
    "auth_type": "session",
    "requires_captcha_solver": false,
    "requires_proxy": false,
    "viewport_requirements": {
      "min_width": 1024,
      "min_height": 768
    }
  }
}

When a user runs siteskills install, the CLI reads this section to:

1. Warn about version requirements. If the user's agent version is below the declared minimum, the CLI displays a warning.
2. Install to the correct directory. Each agent has a default skill directory. The CLI places files where the agent expects them.
3. Surface compatibility notes. Agent-specific notes appear during installation so users know about any quirks.

Best Practices for Agent-Agnostic Skills

Writing skills that work well across every agent requires thinking about the lowest common denominator while taking advantage of each agent's strengths. Here are the practices we recommend:

1. Layer Your DOM Hints

Different agents have different strengths in element detection. Provide selectors in a priority order that covers multiple strategies:

- **DOM hints:**
  - Primary: `#add-to-cart-button`
  - Secondary: `input[name="submit.add-to-cart"]`
  - Text fallback: button containing text "Add to Cart"
  - ARIA fallback: `[aria-label="Add to Cart"]`

CSS-focused agents (like Browser Use with Playwright) will use the primary and secondary selectors. AI-powered agents (like Claude and Stagehand) will leverage the text and ARIA fallbacks if the selectors fail.

2. Write Actions as Natural Language

Instead of writing actions in code-like pseudocode, describe them in plain English:

# Good
- **Action:** Click the "Add to Cart" button in the product details section

# Less portable
- **Action:** Execute click on element matching `#add-to-cart-button`

The first version works across every agent because it describes intent. The second version works, but it assumes the agent will use that specific selector rather than reasoning about the page.

3. Use Generous Wait Conditions

Different agents have different speeds. Claude Computer Use might take 3 seconds to process a step. Browser Use with Playwright might take 500 milliseconds. Set wait conditions that accommodate the slowest expected agent:

- **Wait condition:** Element `#confirmation` visible within 10 seconds

Ten seconds is generous for most cases, but it prevents false failures on slower agents or slower network connections.

4. Include Explicit Success Criteria

Some agents are better than others at determining whether a step succeeded. Make success unambiguous:

- **Expected state:** Page URL changes to contain "/cart"
  AND cart item count badge shows "1" or higher

The more specific your success criteria, the less room there is for agent-specific interpretation differences.

5. Test with Every Declared Agent

This is the most important practice and the one most often skipped. If your siteskills.json declares compatibility with Claude Cowork, Browser Use, and Stagehand, test with all three before publishing. Each agent interprets instructions slightly differently, and you will almost certainly discover edge cases that need additional fallbacks or clearer phrasing.

The Future of Interoperability

The browser agent ecosystem is young and evolving fast. New agents are being released regularly, and existing agents are gaining capabilities quickly. SiteSkills is designed to grow with this ecosystem.

Our format is versioned (currently SST v1.0) and extensible. When new agents emerge with novel capabilities, we can add optional metadata fields without breaking existing skills. The principle is always the same: skills describe intent, agents handle execution.

We are also working with agent framework maintainers to deepen native integrations. The goal is a future where siteskills install does not just copy files to a directory -- it registers the skill with the agent's native skill system, enabling richer discovery, execution tracking, and feedback loops.

The fragmentation of today's browser agent landscape is a temporary state. As the ecosystem matures, interoperability will become a baseline expectation. SiteSkills is building that bridge today, one skill at a time.

Want to publish a cross-platform skill? Start with the Creating Skills tutorial and test across every agent you can get your hands on. The users who benefit from your work might be on any agent -- and that is the point.