Exploring research automation through Exa WebsetsExploring research automation through Exa Websets

Websets has two main form factors, a web UI for building and enriching lists by hand, and an API/SDK for doing it programmatically. The web UI is functional, but for technical operators that are able to write scripts to call the API, build automations, and pipe Websets output into downstream tools, it's a force multiplier.

The no-code dashboard covers the core loop well: you can write a query, set criteria, add enrichments, and export a list without touching code. The issue starts when you want Websets to run on its own or talk to other tools. Take, for example, reacting to a monitored event (a new meeting on gcal), keeping a list fresh on a schedule, or piping results into Clay, Slack, or a CRM all lean on the API and webhooks. These aren't niche edge use cases. The people who'd get the most out of Websets, account executives, recruiters, outbound leads, GTM operators, generally aren't engineers. They use Apollo, LinkedIn Sales Navigator, and Clay. The automation-and-integration layer, the part that turns Websets into a sales pipeline, is locked behind a skill its target users don't have.

To validate, I ran an interview with a member of GTM staff at Cursor to understand how they currently build sales pipelines, where the friction is, and how they'd react to Websets' core value proposition. What I learned is that building enterprise sales pipelines, even at startups like Cursor, still relies on a stack of separate tools: LinkedIn Sales Navigator + Phantom Buster + Clay + Apollo. Each separately handles prospecting, scraping, enrichment, sequencing. Stitching them together takes technical fluency. When I described Exa's semantic search (search using meaning > keywords), the value of combining it with enrichment and automation was obvious. So was the barrier: full functionality currently requires API scripting, which leaves out most sales/GTM/AE users who can't code.

Thus, how might we extend Exa Websets to cover more of the sales pipeline for enterprise clients, giving non-technical users a complete no-code path from filter → enrich → trigger → output? With some context in place, I dove into ideation, whiteboarding, and prototyping.

Webset Workflows is a no-code visual builder embedded directly in the Websets interface. Instead of writing API calls or configuring webhooks elsewhere, users get a drag-and-drop pane to script automations. Take the below workflow as an example, going from an Inbound sales call on Google Calendar → automatic meeting preparation data enrichment → Slack channel message output.

Upon clicking the automations button, a drag-and-drop automation panel will appear that lets users script their own automations.

Take adding a gcal automation, for example, that lets you turn any inbound meeting into an enriched pipeline that automatically provides you with full meeting context documents and materials. Select input "webhook," then add a data source, filter criteria, and custom enrichment column.

Specify where the webset should output the enriched data, and the columns that should be enriched.

Example output, from Gcal webhook to slack channel output. An AE who used to spend 15 minutes researching the company before a call now gets this automatically the moment the event is created. No API setup. No scripting.

Another workflow could be a Monitor trigger for outbound prospecting: on a recurring schedule, find and enrich information for CEOs at Series B+ startups as new funding is announced, then push them to a Clay table for sequencing. Select input type monitor, for a recurring search for people matching "CEO" at companies with "new funding rounds: Series B and later." Enrich the email field and the email script field.

Select how Clay should bind columns with Exa's fields (name → name, job_title → job_title, email → email_address, email_script → email_script). This automation would create a workflow for event monitoring, enrichment, and hand-off automatically and let the AE set it up themselves in minutes.

Currently, there's also a lot of friction in the core table. For enterprise users who daily drive the product, this is a real concern. Right now the table gives no feedback when you select a row, there isn't a highlight, a checkbox, a border. And shift-clicking to select a range, something people expect from every spreadsheet app, doesn't work. Adding a simple visible selected-row state, plus shift-click and drag-to-select allows us to close that gap.

Another problem is being able to manually search for more results, right now there isn't an option to search for more results without rerunning the entire enrichment sequence. A "find more results" dropdown fixes that issue.

Currently, there also isn't an easy way to update and rerun the search through the spreadsheet criteria. To update, you need to open the side panel. Adding a dropdown to edit criteria natively in the spreadsheet reduces the friction in re-searching.

Understanding the actual technical primitives allowed me to deliver the best product. It would have been a lot easier to mock up a slick builder and just say, "it points to the backend." Working through the Exa doc, how its monitor feature works, outbound and inbound web hooks, imports, exports, changed both what I proposed and how I described it. One good interview can redirect thinking without proving anything. The Cursor conversation sharpened the problem faster than more solo analysis would have, the real tool stack and the "can't code" barrier landed harder coming from an operator than from inspection alone. Designing for the non-technical user produced a better interface UX, not just a simpler one. Assuming the person will never see a JSON payload forced specific choices, structured column mapping, plain-language trigger names, constrained dropdowns, that removed categories of error instead of just hiding complexity. These constraints sharpened the design more than my visual decisions did.