NewAgents Just Need APIs — Benchmarking three ways to give AI agents web access: read the writeup →
blog/use-cases
Use cases · · 6 min read

OpenClaw Use Case: Automated Job Search

Turn a chat prompt into a recurring job-search assistant. Connect agent-data to OpenClaw, describe the roles you want (and the ones you don't), and schedule the same search to run a few times a day — only alerting you when a posting actually fits.

Posted

If you've asked an AI agent to keep an eye on the job market for you, the results have probably been mixed. Generic job alerts help a little, but they tend to be too literal, too noisy, or too shallow to tell you why a role is actually worth your time. agent-data gives OpenClaw a different starting point: structured job-search results plus on-demand full posting detail that the agent can filter, compare, and summarize without scraping anything itself — see the Job Postings endpoint for the full schema.

This post walks through the pattern end-to-end: writing a natural-language prompt, what OpenClaw returns to you, what it's doing under the hood, and how to put the whole thing on a schedule so the agent only pings you about new roles that actually match your preferences. By the end, you'll have a recurring job watcher and a pattern you can point at other listings in the library.

Setup: install agent-data (if you haven't already)

If you've already got agent-data connected to OpenClaw, skip ahead. If not, the shortest path is one command:

npx -y agent-data init

That installs the CLI and walks you through API-key setup so you can access the Job Postings endpoint. You can also have OpenClaw walk you through the setup flow directly.

What you see: prompts and what OpenClaw returns

From your side, this is a natural-language prompt that describes what you want — and what you don't:

Use agent-data to monitor new AI and ML engineering jobs in the United States. Alert me when a new posting looks genuinely relevant based on title, company, location, and description. Prefer early-stage or product-focused roles, and ignore vague low-signal matches.

A few useful variations:

Founding-role watcher:

Use agent-data to watch for new founding engineer roles in the San Francisco Bay Area. Prioritize AI infrastructure, product engineering, and high-agency startup roles. Only alert me when the posting looks like a strong match.

Company-targeted monitor:

Use agent-data to check for new roles at Notion, Linear, and similar companies I care about. Alert me only when there is a clearly relevant engineering or product role.

When something matches, the response OpenClaw sends back is a shortlist tailored to your preferences rather than a raw or only loosely filtered dump.

What the agent sees: discovery and structured job data

This section is more of an under-the-hood look. You don't need to read it to use the workflow, but it's useful for debugging when something doesn't behave the way you expect.

OpenClaw first searches the library for the right listing and reads its docs:

$ agent-data search "job search and job listing APIs"
$ agent-data docs [Job Postings API UUID]

That returned the Job Postings API. The docs exposed three relevant routes: status, search-jobs, and get-posting.

Unlike some other listings, this workflow is two-step but not asynchronous. search-jobs returns lightweight summary rows synchronously; get-posting fetches the full live detail for one selected row.

With the listing identified, the agent calls search-jobs:

$ agent-data call [Job Postings API UUID] search-jobs \
  --keywords "founding engineer" \
  --location "San Francisco Bay Area" \
  --limit 5

A trimmed sample of the actual response:

{
  "data": {
    "status": "completed",
    "query": {
      "keywords": "founding engineer",
      "location": "San Francisco Bay Area"
    },
    "results": [
      {
        "id": "jp_cf0a58f07e51",
        "title": "Founding Engineer ($120K - $200K + Equity) at YC-backed AI lending startup",
        "company_name": "Jack & Jill",
        "location_display": "San Francisco, CA",
        "posted_at": "2026-05-20T14:23:00Z",
        "detail_available": true,
        "source_url": "https://www.linkedin.com/jobs/view/..."
      },
      {
        "id": "jp_b565bcbee81a",
        "title": "Model Behavior Engineer",
        "company_name": "Notion",
        "location_display": "San Francisco, CA",
        "posted_at": "2026-05-19T09:15:00Z",
        "detail_available": true,
        "source_url": "https://www.linkedin.com/jobs/view/..."
      },
      {
        "id": "jp_5ea20b9fcce9",
        "title": "AI Product Engineer | Founding Team | $250K Base + Equity",
        "company_name": "HUG",
        "location_display": "San Francisco, CA",
        "detail_available": true,
        "source_url": "https://www.linkedin.com/jobs/view/..."
      }
    ]
  }
}

That's already enough for first-pass triage. OpenClaw can rank by title, company, location, freshness, and whether the result looks worth a deeper read at all. For recurring runs, search-jobs also accepts a fields parameter so the agent can request a smaller payload when it only needs lightweight screening:

$ agent-data call [Job Postings API UUID] search-jobs \
  --keywords "AI engineer" \
  --location "United States" \
  --limit 3 \
  --fields id,title,company_name

Once OpenClaw sees a promising summary row, it can fetch the full posting body:

$ agent-data call [Job Postings API UUID] get-posting \
  --posting_id jp_b565bcbee81a \
  --source_url 'https://www.linkedin.com/jobs/view/model-behavior-engineer-at-notion-4377036139?...'

A trimmed sample of the actual response:

{
  "data": {
    "id": "jp_b565bcbee81a",
    "title": "Model Behavior Engineer",
    "company_name": "Notion",
    "location_display": "San Francisco, CA",
    "employment_type": "FULL_TIME",
    "missing_fields": ["application_url"],
    "description_markdown": "... You'll own the quality bar for Notion AI products ... context engineering ... evaluation systems ... work directly with frontier AI labs ... compensation range for SF/NYC: $98,000 - $140,000 ..."
  },
  "meta": {
    "mode": "live_detail"
  }
}

Notice the gap between the title and the description: the summary row's "$120K - $200K + Equity" is recruiter-set headline copy, while the description's "$98,000 - $140,000" is the official posted range — exactly the kind of mismatch get-posting exists to surface.

This is the step that lets OpenClaw reason over real posting text and determine if the posting matches your preferences for role, seniority, compensation, location, and more. The first call usually involves discovery (search → docs → call), but later calls can reuse the path discovery established, so a scheduled job can skip straight to search-jobs.

Run it on a schedule with OpenClaw cron

Scheduling is how this stops being a one-off check and starts running on its own.

Once you know the listing and route, you can schedule a recurring isolated job to rerun the search, compare against the prior result set, fetch detail only for promising new rows, and alert only when something materially relevant appears:

openclaw cron add \
  --name "Watch AI engineer jobs" \
  --cron "0 8,14,20 * * *" \
  --tz "UTC" \
  --session isolated \
  --message 'Search for new AI and ML engineering jobs in the United States. Compare results with previous runs, fetch full detail only for strong new matches, and alert me when a new posting looks genuinely relevant based on title, company, location, and description.' \
  --announce

Two practical notes. First, use an isolated cron job for this kind of recurring workflow. Second, the first run will see a larger pool of "new" results because nothing has been seen yet, so expect more alerts on the initial schedule than during steady state.

A few natural follow-ons:

Every morning, send me the 5 most interesting new founding engineer roles in San Francisco, with one sentence on why each one stands out.
Check for new software engineering roles at Seed to Series A companies that are fully remote. Prioritize companies building games.

Why agent-data instead of browser automation?

Browser automation can be used to access arbitrary web pages, but it's generally slow, expensive, and flaky. The agent pays for a screenshot at every step, which adds up fast when the job is running on a schedule. And it can only act on what the page is currently rendering, so anything below the fold — like the rest of a paginated list of job postings or the detail page that shows what the job actually entails — requires another turn.

Other job-search use cases for OpenClaw

Watch one company's hiring activity

Instead of monitoring the whole market, OpenClaw can watch for new roles at a short list of companies you care about and only ping you when something relevant appears.

Watch for new engineering roles at Notion, Anthropic, and Vercel. Alert me only when a posting looks like a strong fit.

Surface founding-engineer roles

The startup-and-founding-role search is one of the cases where the title alone is misleading and the description matters more.

Monitor new founding engineer and early product engineering roles in San Francisco. Pull detail only for postings that look high-agency.

Track recurring skills from descriptions

Because get-posting returns the description body, OpenClaw can also summarize what skills or responsibilities show up repeatedly across the roles you care about.

Track new AI product roles, then summarize the skills, tools, and evaluation patterns that keep showing up.

Turn OpenClaw into a job-search assistant

Install agent-data, connect it to OpenClaw, and start with one job-search prompt that's narrow enough to be useful. Once the first search is working, put it on a schedule and let OpenClaw do the repetitive checking.

Full docs: docs.agent-data.dev. OpenClaw docs: docs.openclaw.ai.

Frequently asked.

Does this search live job listings or a static database?

It uses live search and live detail fetches rather than a fixed exported jobs table. The responses include current posting metadata, and full detail is fetched on demand.

Why does the workflow use both search-jobs and get-posting?

Separating the two allows agents to better manage their context. Rather than load posting details for jobs that aren't interesting to you, exposing a get-posting route enables the agent to dig deeper only when doing so adds value.

How often should I run a recurring job search alert?

A few times per day is usually a sensible starting point. Job postings don't behave like minute-by-minute market data, and more frequent polling tends to add noise without much benefit.

Why not just use LinkedIn alerts?

Native alerts are fine for simple literal matching, but they're weaker when you want to apply more nuanced filters.

Does agent-data only work with OpenClaw?

No. agent-data is a standalone CLI that provides structured web data to agents. This post focuses on OpenClaw but it can be applied to Hermes Agent, Claude Code, or any other agent with shell access.

Related.