Like Pixie dustfor your agents.
Bring your scattered browser automations and workflows together. Turn what happens in a browser into a service your software can call.
From scattered to connectedWatch your automation
become an enterprise API.
Watch a Hacker News workflow become structured data, with every decision visible along the way.
- Building useful tools for browser agents (example.com)
128 points · 42 comments
- Show HN: A workflow becomes an API (example.com)
96 points · 18 comments
- What makes an automation reliable? (example.com)
74 points · 23 comments
- Typed contracts for a changing web (example.com)
51 points · 12 comments
Read top stories
Return titles, links, points, and comment counts from the page.
/api/hacker-news/storiescurl '/api/hacker-news/stories?limit=3'
Run a test to preview the JSON response.Proposed GET interface. This preview does not call a deployed endpoint.
Select a step to inspect it, or run the sample test.
Simulated decisions and evidence for this product preview.Your next data source
is already in a browser.
A portal with no API. A script on someone’s laptop. A workflow that gets the job done—until the page changes, the session expires, or someone else needs to run it.
Browser automation is becoming part of our data infrastructure. It needs the contracts, lifecycle, and visibility we expect from an API framework.
Show it once.
Build a service around it.
Inspired by LoopBack’s approach to API development, Pixie puts browser workflows behind typed inputs, structured outputs, versioned endpoints, and checks you can inspect.
Record
Demonstrate the task in a dedicated browser through Pixie Studio.
Define
Choose the inputs, outputs, and checkpoints that make the workflow reusable.
Test
Run it with Jev. Inspect the browser actions and check the result.
Publish
Give consumers an immutable revision and an API contract.
Call
Invoke the endpoint from another application and inspect its run evidence.
Jev takes the next step.
Pixie checks where it lands.
Jev UltraFast proposes browser actions from what it observes. Pixie applies the workflow’s policy, executes allowed actions, and independently verifies the outcome before accepting a result.
Published workflow revision
Propose the next action
Execute in the browser
Return data and evidence
The runtime repeats observe, propose, and execute until the task completes or needs review.
See the decisions
Inspect the run’s visual flow, proposed actions, policy decisions, and verification results in Studio.
Keep the evidence
A completion claim is only part of the story. Checkpoints and independent checks determine whether the result is accepted.
Make exceptions explicit
Ambiguous targets and failed checks become reviewable outcomes. Consumers can tell when a run needs attention.
From your terminal.
To everyone’s toolkit.
Explore the developer flow in the new Pixie CLI or the Pixie Developer Studio.
Start with a workspace.
- Initialize
- Check environment
- Open Studio
- Test
- Publish
CLI installed from the repository. Authoring and recording happen in Studio.
Create a Todo
Start a run
Invoke a published automation with an explicit revision, browser account, and typed input.
Request
revision1 · requiredaccountIdtodo-demo · requiredRuns locally in this page. No credentials or external requests.
Select “Try sample request” to see an example response.
Any Website.
Callable operations.
Pixie turns an ordinary browser-based app into an API. A client requests a change, Jev operates the visible browser, and Pixie verifies what actually happened.
- CCreate a taskAdd “pixie-demo groceries” and verify it appears exactly once.
- RRead the listReturn structured task data from the browser app.
- UUpdate a taskChange the intended task and verify the new value.
- DDelete a taskRemove the intended item and check that other tasks remain unchanged.
pixie init ~/pixie-project cd ~/pixie-project pixie doctor pixie dev # Record and define in Studio. # Then test your automation: pixie test <automationId> pixie publish <automationId>
The CLI runs from the repository; it is not published to npm. Live Jev runs require a configured model key.
“Our agents already depend on browser automations, one-off scripts, and workflows scattered across our systems. I built Pixie to turn those dependencies into reliable data sources, using proven API patterns: typed contracts, input validation, versioned endpoints, and verifiable results. We should be able to build on a browser workflow with the same confidence we expect from an API.”
Browser workflows.
Durable service boundaries.
The goal is bigger than running a script: reusable data sources that applications, MCP servers, and agent tools can call through the same explicit contract.
For applications
Consume a versioned API instead of embedding browser-control logic in every integration.
For MCP servers
Use the API contract as a foundation for exposing workflows as tools. MCP packaging is an extension direction.
For agents
Give agents bounded operations with defined inputs and observable outcomes.
We’re building
in the open.
Follow Rick Lopez for updates as Pixie takes shape.