New AI Skill — The Product Ops Job Finder using Hyperagent
The Practical AI for Product Ops Series
In the last article in this series, I shared how I built an AI skill to sync roadmaps between Miro and Airtable — spatial data turned into structured records, eliminating hours of manual work. That project was built using Claude’s MCP integrations, and it is genuinely transformative for my teams in my day job.
But… MCP integrations are powerful, but they have limitations. They’re local, they’re session-based, and they don’t lend themselves well to scheduled, repeatable automations that just run without you being there (though at the time of writing, I’m starting to explore Claude’s latest scheduling tools). For this project, I needed something that could take the skills and logic I’d built and turn them into proper agents — things that wake up every morning, do their job, and report back.
Hyperagent has this out of the box
Hyperagent is an AI platform built on Claude that takes the concept of ‘skills’ much further. You can build named agents with persistent memory, scheduled invocations, integrated web search and browsing, direct connections to platforms like Airtable, and — critically — the ability to learn from what it does (I really love this bit!). It remembers what worked, what didn’t, and gets better at the job over time. Think of it as the difference between asking a colleague to help you with a task and actually hiring someone to own it. Cough, Product Operations, cough.
I’ve been using it for a few weeks now with my Product Ops Confidential hat on, and one of the first things I built is something I’ve wanted to bring to life for a long time now - an automated Product Operations job finder.
As with all my AI articles:
I affectionately say ‘we’ a lot — Hyperagent and I — because it really does feel like a partnership. The platform is built on Claude, so the collaborative dynamic I described previously continues here, but with significantly more capability around automation and persistence.
In the spirit of that partnership, Hyperagent has helped review and draft the technical details of this article. It honestly knows it better than me, and truthfully, it has saved me a lot of time and cognitive load. I’ve checked and edited, but I’m upfront about the collaboration. I believe such collaborations are valuable, but I also believe in being open about this. If the output is accurate, truthful, informative and useful to the reader — that’s what matters.
The Problem — Tracking Product Ops Jobs at Scale
At Product Ops Confidential, we keep an eye on the Product Operations job market. It’s part of what we do: understanding which companies are hiring, what roles are opening up, where the demand is geographically, what seniority levels are being recruited, and what skills employers are asking for. This data feeds into our annual State of Product Operations report, our career tools, and the advice we give to the community.
The problem? This has been an almost entirely manual effort. One of us ( Antonia Landi or I) would periodically search the major job sites for ‘Product Operations’ roles, open each listing, copy the URL into an Airtable tracker, and then check back periodically to see if listings were still active or had closed.
One good thing I did build within Airtable (in case you didn’t already know, I’m a little bit in love with Airtable!!), using their Field (AI) Agents, is taking those URLs, scanning the page and picking out the key information into structured fields covering the company, role, salary (where listed), role details, benefits and a lot more. Each agent runs independently and focuses on its own task to extract the information it needs. Saves a lot of time!
That said, it’s boring. It’s inconsistent. And most importantly, it’s incomplete. Manual searching catches whatever happens to be visible when you search. Listings get posted and taken down between your check-ins. You miss things. And the data quality suffers, which, for a community resource, is not great.
I needed a system that would:
Search comprehensively for Product Operations listings every single day
Identify whether listings are genuinely active or have expired
Deduplicate against what we already have in our database
Write the results directly to Airtable, letting our existing AI enrichment pipeline do its thing
Check back on existing listings to detect when they go stale
That’s exactly what the Product Ops Job Finder does.
What the Agent Actually Does
The Job Finder is a named agent in Hyperagent that runs on a daily schedule. When it wakes up, it does the following:
1. Dual Search Strategy
It runs two parallel searches using Exa (a semantic web search API):
Keyword search:
hiring "Product Operations" jobscoped to the job sites — this catches listings with the exact title phrase. High precision, very few false positives.Neural search:
Product Operations job listingusing Exa’s job site integrations — this uses AI embeddings to find semantically similar listings, catching variations like ‘Head of Product Ops’, ‘Product Operations & Strategy Lead’, or ‘VP Product Operations’ that a keyword search would miss entirely.
Running both in parallel gives us the best of both worlds: precision and recall.
2. Filtering and Deduplication
The raw search results are a mix of actual job listings, posts about jobs, profile pages, and category search pages. The agent filters to keep only URLs containing, for example, /jobs/view/ — the actual individual listing pages.
It then applies a title filter — the listing title must contain ‘Product Operations’ as a contiguous phrase (case-insensitive). This filters out roles that might mention ‘operations’ and ‘product’ separately but aren’t actually Product Ops roles.
Finally, it deduplicates against every listing already in our Airtable database by extracting the numeric job ID from each URL. No duplicate records, ever (Though it doesn’t pick up on multiple posts or reposting the same role with a new URL… but baby steps!).
3. Active/Inactive Status Classification
This is where it gets clever — and where I invested the most time getting it right.
For each new listing (and during periodic sweeps of existing records), the agent fetches the current state of the posting page using Exa’s live crawl capability. It then classifies each listing into one of three statuses:
Actively Accepting Applications — the page loads with a standard hiring title pattern (e.g., ‘Uber hiring Product Operations Manager in San Francisco’) and contains an ‘Apply’ button or similar.
No Longer Accepting Applications — one of several definitive signals is detected (more on these in the Gotchas section).
Unknown — the signals are ambiguous, so we leave the status as-is rather than making assumptions.
The classification is deliberately conservative. We only mark a listing as inactive when there are clear, definitive signals. False deactivation — telling our community a job is closed when it isn’t — is worse than a slight delay in detecting an expiry. Ultimately, everything listed and written to the database is the best endeavour - it does its best from what it can find, but there is always the chance it doesn’t reflect correctly on specifics like the role still being available, if a salary is mentioned or not.
BUT, it will never guess, interpret or extrapolate. It will copy the information like-for-like, or it will not copy at all. I would rather have gaps in data where it is unsure than display anything untrue. End of the day, the tool is highlighting those roles, always pointing professionals to the actual listing!
4. Writing to Airtable
For each new, validated listing, the agent writes exactly three fields to our Airtable Jobs table:
Job URL — the listing URL
Job Site — i.e. ‘LinkedIn’
Position Status — one of ‘Actively Accepting Applications’, ‘No Longer Accepting Applications’, or ‘Unknown’
That’s it. Just three fields. Why?
Because our Airtable table has 28+ fields — but only these three are both writable, and needed. Everything else — Company, Job Title, Location, Salary, Key Skills, Position Overview, Position Benefits, Company Overview, and more — is automatically extracted by Airtable’s own AI field agents from the Job URL. We supply the URL; Airtable’s AI does the enrichment.
This was a deliberate architectural decision. We could have had the scanning agent extract all that data itself. But Airtable’s AI agents are purpose-built for this kind of structured extraction, they’re reliable, and they mean we don’t have to maintain extraction logic in two places. The scanning agent finds and validates. Airtable enriches. Each system does what it’s best at.
I feel this is an important guideline for everything I have been building with AI of late - AI doesn’t need to do it all. Let tools do what they are best at: storing data, permanent dashboards, large data integrations and syncs. Where the gaps appear, AI tools are perfect to jump in.
5. Staleness Sweep
The agent doesn’t just find new listings. On each run, it also checks existing active records to detect listings that have since expired. It pulls all records currently marked as active, fetches the current state of each listing page, and reclassifies them. If a listing has definitively gone inactive — the page returns a 404, redirects to a generic search results page, or explicitly says ‘no longer accepting applications’ — it updates the status.
This means our database stays current. Listings that close between runs get caught on the next sweep.
How We Built It — The Hyperagent Advantage
This wasn’t a one-shot build. Like all my skills, it was iterative — but the tooling made iteration dramatically faster.
Skills and Memory
Hyperagent has a concept of ‘skills’ just like Claude — reusable knowledge that the platform can draw on across sessions and agents. As we built the Job Finder, every discovery, every gotcha, every tested search pattern got captured as a skill. These skills aren’t just documentation — they’re operational. When the agent runs, it loads these skills and follows them. When we discover a new edge case, we update the skill, and the next run incorporates the improvement. It’s a living system.
On top of skills, Hyperagent has persistent memories (Again, like Claude). It remembers our Airtable schema — which fields are writable, which are computed. It remembers our architectural decisions — like keeping extraction in Airtable rather than doing it in the agent. It remembers the Exa search quirks we’ve discovered. These memories persist across every session and every agent, so the platform never ‘forgets’ and tries something we’ve already learned doesn’t work.
But what I really love about Hyperagent is that when it learns something new along the way, it tells you about it in the Learning section. It makes suggestions to you, and you can just tell it to add more context to its memory or create a new skill. Your choice. The more it runs, the more it learns, the more it suggests to improve. This is more and more like how a child learns, it is scary!
Airtable Integration
Hyperagent connects directly to Airtable through a native integration. No API keys pasted into chat, no manual authentication. It can query existing records (for deduplication), write new records, and update existing ones. This made the Airtable side of the build remarkably smooth — no middleware, no webhook plumbing, just direct read/write access. Though let’s be fair, Hyperagent is built by the Airtable team… so of course it just works!
Scheduled Invocations
The agent is configured to run daily. Not ‘I need to remember to trigger it’. Not ‘I set up a cron job somewhere’. It’s a named agent with a schedule, and it just runs. Each invocation creates a new thread, does its thing, and I can review the results whenever I want. If something goes wrong, I can see exactly what happened in the thread history. The skills I was building before with MCP were powerful, but they needed me present to run them. The Job Finder doesn’t need me at all. It just works.
The Gotchas
A few things caught us out that are absolutely worth sharing — especially if you’re building anything that touches job site data. Lets be honest, the job sites don’t want you crawling their listings…
1. Date filters don’t work for some job site searches in Exa
This one cost us a lot of debugging time. Exa’s search API supports startPublishedDate and endPublishedDate filters — and you’d naturally want to use them to say ‘only find listings posted since yesterday’. The problem?
Many job pages don’t have reliable publication dates in Exa’s index. When you add a date filter:
Keyword search returns zero results (everything gets filtered out)
Neural search sometimes returns posts instead of job listings
The solution? Don’t use date filters. We rely on Exa’s natural recency bias in its ranking and deduplicate against existing records instead. If we’ve already seen a listing, it gets skipped. Simple, reliable, and doesn’t break the search.
2. Sites silently redirects expired listings (a little bit technical this one)
This is the nastiest gotcha. When a job listing expires, some sites do not show a nice ‘this job has expired’ page to unauthenticated crawlers. Instead, it silently redirects the URL to a completely unrelated generic search results page. You request the page for ‘Uber hiring Product Operations Manager’ and you get back a page titled ‘1,000+ Vice President Business Solutions jobs in United States’.
If you’re only checking HTTP status codes, you’ll think the page loaded fine — it returns a 200. The only way to detect this is by analysing the page title and looking for the pattern: a number followed by job titles that don’t match what you expected.
We built specific regex patterns to detect this: ^\d[\d,]*\+?\s+.+\s+jobs?\s+in\s+ — and it catches these redirects reliably.
3. Active-looking titles on expired listings
Some expired listings retain the original '[Company] hiring [Role] in [Location]' title format — which looks perfectly active — but contain ‘No longer accepting applications’ in the body text. If you classify by title alone, you’ll miss these entirely.
This is why our classification system checks inactive signals before active signals. The body text trumps the title. Always.
4. The ‘livecrawl’ isn’t always live
Even when you explicitly request a fresh crawl via Exa’s API, you sometimes get cached content. The solution is straightforward: always analyse whatever content you get back. Don’t assume freshness. Our classification works on the content as received, regardless of whether it’s fresh or cached.
What This Means for Product Ops
I keep coming back to the same theme across these articles: AI’s primary value in product operations isn’t replacing judgment. It’s removing the operational friction that prevents good data from existing in the first place.
The Job Finder doesn’t make decisions about which roles are worth applying to. It doesn’t evaluate company culture or assess compensation competitiveness. Those require human insight (for now) — and that’s exactly what we layer on top of the data.
What the agent does is ensure the data exists. Comprehensively, accurately, and daily. It’s infrastructure. Unsexy, essential infrastructure.
Hyperagent, as a platform, has shifted my thinking about what’s possible with AI tooling. The jump from ‘I can ask AI to help me with a task’ to ‘I can build an agent that owns a task’ is significant. Skills that persist and improve. Memories that prevent repeated mistakes. Schedules that don’t need me more than anything!
For Product Ops practitioners looking to explore this kind of tooling, my advice remains the same: start with a real problem. Something your team does manually, repeatedly, and imperfectly. Don’t start with the tool and look for a problem. Start with the friction and see if the tool can remove it.
And when you find something that works, capture it. Build it so it runs without you. Make it repeatable. Make it reliable. That’s what Product Operations is all about — and it turns out, that’s exactly what good AI agents are about too.
If you are reading this not just to learn how I built this tool, but want to make use of it as a job seeker, then read more about it here:
And don’t forget to get in touch and provide your feedback.
Graham