How to Track AI Lab Talent Moves (Entries and Exits) as They Happen

Hand-built talent maps go out of date in weeks. See how to monitor talent moves between AI labs with a watcher, tracking known names and catching new movers.

Published

Jun 12, 2026

Written by

Manmohit Grewal

Reviewed by

Nithish

Read time

7

minutes

How to Track AI Lab Talent Moves (Entries and Exits) as They Happen

A senior researcher leaves one frontier lab for another, and the first trace of it is usually a stray repost or a new name on a paper, weeks before any profile or news story catches up. Read that signal early and you can reach out while the seat is still in play, which in a market this fast is most of the advantage.

This guide is about how to monitor talent moves between AI labs as they happen. It is the monitoring companion to mapping who-knows-who in technical talent, which covers building the map itself. The whole focus here is one question. How do you find out about an entry or an exit early enough to do something about it? We will cover what counts as a move worth catching, the two ways to set a watch, how fresh the signal really is, and how to wire one up without exposing your list. You can build a first version on a free Crustdata account with 100 credits.

Why a hand-built map can't keep up

A list of names is a picture of one moment. People move, and the picture is wrong. That is the whole problem in one line, and no refresh schedule fixes it, because the market does not wait for your schedule.

It gets harder with the people you most want to track. The strongest AI researchers often have no real public profile, and the profiles that do exist tend to lag months behind. So the lead we spoke with does what most teams do today, which is comb through people's posts by hand, looking for the small tell that someone has moved. Someone reposts a launch from a lab. They turn up as a minor author on the paper behind it. Piece by piece, you infer that they probably work there now. It is real detective work, and it does not scale past a few dozen names.

The fix is to stop treating the map as a document you periodically rebuild, and start treating it as something that updates itself the moment the underlying facts change. That means watching for the events that signal a move, and letting those events come to you.

What counts as a move worth catching

A move is rarely a tidy job-title change on a profile. For lab talent it shows up first as something smaller. A new affiliation on a paper. A repost of a product launch. A fresh post that reads like a goodbye or a hello. A name that starts appearing in coverage next to a different company. Sometimes the only early signal is that someone quietly drops off one company's page and surfaces around another.

So the first job is to decide which of these signals you trust, and the rule that holds up best is to take the freshest one. People tend to post before they change anything official, so a public post usually surfaces a move long before the profile does.

The honest complication is matching a signal back to the right person. When an unfamiliar account reposts a launch, all you have is a candidate, and you still have to prove it. The way through is the same as it is for sourcing. You treat one signal as a maybe, then confirm with a second, a matching paper, a linked code account, a work history that lines up, before you trust that a move happened. One weak signal is noise. Two that agree is a move.

Two ways to watch: a named list and a set of criteria

Once you know what a move looks like, there are two ways to watch for one, and the difference matters more than it sounds.

The first is a tracking watch. You already have the names, a wish list of researchers you care about, and you want to know the moment anything changes for them. With Crustdata's Watcher API you point a watch at a specific profile and ask for profile updates, new posts, or press mentions. When the title changes or the post lands, you get told. This is the half that sales-focused job-change trackers do well, and it works fine here too, as long as you already know who you are following.

The second is a discovery watch, and this is the one almost nobody builds. Here you do not name the people. You name the criteria, and the watch finds the movers for you. You can ask to be told whenever anyone recently left a given lab, or whenever a new researcher matching a profile turns up. Behind the scenes that is a filter-based watch, for example people whose most recent employer is openai.com and who recently changed jobs, checked on a schedule and reported as the set changes.

That is the answer to the question the lead kept circling, which was whether the tooling could surface people she had missed. A tracking watch can only ever tell you about names you already had. A discovery watch tells you about the ones you did not. One team we spoke with had spent days assembling a list of who worked on an obscure release, only to keep finding stragglers by hand. A discovery watch is how that straggler finds you instead. You can see the watch types here.

How fresh is "as they happen"?

It is worth being straight about what real time means, because the title of every tool in this space promises more than the data can give.

A watch runs on a schedule you set, as often as once a day, and notifies you within hours of detecting a change. That is fast enough to act on a lab move, even if it is not the same-second ping the words real time suggest. Because people usually post before anything official updates, you tend to hear about a move early regardless. Set the cadence to match how closely you follow a given set, daily for the names that matter and slower for the rest.

Wiring up a watcher (and keeping your list private)

The setup is small. You define a watch, point it at a place to receive notifications, and let it run. A discovery watch for exits from a single lab looks like this.

import requests

# Watch for anyone who has recently left a given lab.
# event_filters define the criteria. The watch reports new matches on a schedule.
watch = {
    "event_type_slug": "person-discovery-via-filters",
    "event_filters": [
        {"filter_type": "LAST_COMPANY", "type": "in", "value": "openai.com"},
        {"filter_type": "RECENTLY_CHANGED_JOBS", "type": "in", "value": True},
    ],
    "frequency": 1,  # check daily
    # Omit notification_endpoint to use a Crustdata-managed receiver,
    # or pass your own HTTPS URL to receive the webhook on your backend.
    "notification_endpoint": "https://your-server.example.com/watcher",
}

resp = requests.post(
    "https://api.crustdata.com/watchers/",
    headers={"authorization": "Bearer YOUR_API_KEY", "x-api-version": "2025-11-01"},
    json=watch,
)
# See docs.crustdata.com for the full event-type and filter list

import requests

# Watch for anyone who has recently left a given lab.
# event_filters define the criteria. The watch reports new matches on a schedule.
watch = {
    "event_type_slug": "person-discovery-via-filters",
    "event_filters": [
        {"filter_type": "LAST_COMPANY", "type": "in", "value": "openai.com"},
        {"filter_type": "RECENTLY_CHANGED_JOBS", "type": "in", "value": True},
    ],
    "frequency": 1,  # check daily
    # Omit notification_endpoint to use a Crustdata-managed receiver,
    # or pass your own HTTPS URL to receive the webhook on your backend.
    "notification_endpoint": "https://your-server.example.com/watcher",
}

resp = requests.post(
    "https://api.crustdata.com/watchers/",
    headers={"authorization": "Bearer YOUR_API_KEY", "x-api-version": "2025-11-01"},
    json=watch,
)
# See docs.crustdata.com for the full event-type and filter list

import requests

# Watch for anyone who has recently left a given lab.
# event_filters define the criteria. The watch reports new matches on a schedule.
watch = {
    "event_type_slug": "person-discovery-via-filters",
    "event_filters": [
        {"filter_type": "LAST_COMPANY", "type": "in", "value": "openai.com"},
        {"filter_type": "RECENTLY_CHANGED_JOBS", "type": "in", "value": True},
    ],
    "frequency": 1,  # check daily
    # Omit notification_endpoint to use a Crustdata-managed receiver,
    # or pass your own HTTPS URL to receive the webhook on your backend.
    "notification_endpoint": "https://your-server.example.com/watcher",
}

resp = requests.post(
    "https://api.crustdata.com/watchers/",
    headers={"authorization": "Bearer YOUR_API_KEY", "x-api-version": "2025-11-01"},
    json=watch,
)
# See docs.crustdata.com for the full event-type and filter list

To track named people instead, swap the event type for a person watch pointed at the profiles on your wish list, and you get told when any of them changes. Each notification arrives as a small payload with the person, the event, and the company, which you can route straight into whatever you already use.

The piece worth getting right is privacy, because for a team like this the watch list is the strategy. The list of researchers you most want is some of the most sensitive information you hold. With Crustdata your criteria are not logged beyond a short window kept only for tracing issues, access is limited to a couple of people, and a custom watch you build with us stays yours. You can run the whole thing without exposing who you are following.

Picture the payoff. A researcher with almost no public footprint leaves a lab. There is no profile update for weeks. But the discovery watch sees the employer change the day it surfaces, and the alert is in your inbox while the rest of the market is still guessing. That is the difference between reading about a move and being early to it. Book a demo if you want to see it run against your own target labs.

What to do when the watcher fires

A move event is a starting gun. Once you know someone is on the way out of a lab, the useful question comes right after. Does anyone here already know them? That is where the relationship layer takes over, turning a detected move into a warm introduction instead of a cold note. We walk through how to build that layer in the companion piece on mapping who-knows-who in technical talent. The watcher tells you when. The map tells you who can help.

Stop rebuilding the map

The point of all this is to stop paying the rebuild tax. A hand-kept list will always be a step behind the market, and the people you most want to catch are exactly the ones a list misses. A watch is how you trade the weekly cleanup for a feed of moves as they happen.

So begin small. This week, pick one lab you care about most and set a single discovery watch on who is leaving it. Next, add the handful of named researchers you already track. Within a month you will have a map that maintains itself, and you will hear about the moves that matter while there is still time to act. You can build the first version today on a free Crustdata account, or book a demo to see it against your own labs.

Frequently asked questions

What is the difference between a tracking watch and a discovery watch? A tracking watch follows people you have already named and tells you when something changes for them. A discovery watch follows a set of criteria, like anyone who recently left a given lab, and finds the movers for you, including people you did not know to add. Tracking keeps your known list fresh. Discovery grows it.

Can you detect a job change for someone with no LinkedIn? Often, yes. The strongest researchers tend to have thin profiles, so you lean on other signals, a new paper affiliation, a launch repost, a linked code account, a press mention. No single one is proof. Combine two that agree and confirm before you trust the move.

How fresh are the alerts, is it really real time? A watch runs on a schedule you set, as often as daily, and notifies you within hours of a change. Because people post before they update a profile, you usually hear about a move early. It is fast enough to act on, though it is not a same-second alert.

How do you keep a sensitive watch list confidential? Your watch criteria are not logged beyond a short window kept only for tracing issues, access is limited to a couple of people, and a custom watch built with us stays private to you. You can monitor a target list without exposing who is on it.

How is this different from a sales job-change tracker? Sales tools track named contacts already in your records and trigger outreach when they move. That is the tracking-watch half. This adds the discovery half, watching a set of criteria to surface new movers, and the multi-signal detection needed for talent whose profiles never tell you anything.

Data

Delivery Methods

Use Cases

Solutions