How Ambitio’s tech finds the PhD labs that’ll take you

How Ambitio turns a four-month manual process into a guided pipeline.

Most PhD applicants apply to the wrong labs and send cold emails the professor skims and ignores. Both failures come from the same gap. Nobody is reading the grant data, the live job postings, or the methodology paragraphs of the professor’s last 18 months of papers. We do. Here’s the pipeline.

The starting point

Talk to any first-time PhD applicant in October. They’re staring at a Google Doc titled schools.docx with 12 universities on it, half of them picked because their friend went there. They have 6 SOPs to write, 10 LORs to coordinate, 100+ cold emails to send. Their deadlines are 8 weeks out.

The information they need to do this well exists somewhere. The right professor for them has a public profile, recent papers, and an active grant. The lab that funds students like them has historical admit rates. The successful SOPs from past applicants to that lab follow specific writing patterns. None of this is in one place.

The asymmetry between what a student knows and what’s actually knowable is the problem we set out to fix.

The three layers

Most “AI for admissions” products are essentially ChatGPT with a system prompt that says “you are an expert PhD admissions counsellor.” That’s a fine demo. It’s not the product.

What we built is closer to a pipeline. Three inference layers with a feedback loop wrapped around them.

Layer 1: Data intelligence. A knowledge graph of around 500K professors, 100K+ programs, 2M+ alumni outcomes, and 400M+ research papers. Built from 15+ public sources, our own crawl agents, and a proprietary outcome dataset (more on that later).

Layer 2: Shortlisting intelligence. A retrieval and ranking pipeline that takes a student profile and returns a balanced shortlist of programs with calibrated admit probabilities.

Layer 3: Application intelligence. A grounded generation system that produces application documents (SOPs, research statements, cold emails) attributable to source nodes in the knowledge graph.

The feedback loop closes the system. Every outcome (an admit, a reject, a reply, an interview invite) becomes a training signal that updates parameters across all three layers.

The PhD student’s journey through Ambitio walks through these layers in order.

Stage 1: Finding the right lab

The most common failure mode of a PhD applicant is applying to the wrong labs.

It looks like this. A student wants to do multi-agent reinforcement learning. They have Stanford and CMU on their list because those are the famous places. They don’t know that the professor at MIT who published the algorithm closest to their undergrad thesis is taking students this cycle. They don’t know that the lab at ETH Zurich publishing on the same problem has guaranteed funding for international students. They don’t know that the professor they emailed at Berkeley moved to industry six months ago and isn’t responding to anyone.

Three signals tell you which lab is actually a fit. None of them live in the program brochure.

The first is money. Whose grants got approved in the last 12 months and how much of the budget is still unspent. A professor publishing brilliantly on your topic but funded only through a grant ending next year is not taking a 5-year PhD student. A less-cited professor with a fresh multi-year award is. We pull active grant data continuously across NSF, NIH, ERC, DFG, EPSRC, JST, and the equivalent national funders in a dozen other countries. For each professor we know whose money is fresh, whose is running out, and which projects have student slots written into the budget.

The second is open positions. Most funded PhD slots in Europe and Canada (and increasingly in Asia and Australia) are advertised as job postings, not quietly embedded in the program brochure. Our crawl agents read the official university job boards, EURAXESS, lab websites, and X every day. When a professor posts a “PhD position available” notice, that professor enters the shortlistable pool for matching profiles within 24 hours. When she fills the slot and takes the notice down, she leaves the pool. The shortlist a student sees on a Tuesday is different from the one she’d have seen the previous Tuesday, because the underlying market shifted.

The third is the paper match. Most matchers compare paper abstracts and topic embeddings. That gets you “this professor works on robotics, the student wants robotics” pairings. Useful but shallow. We read the papers properly. Methodology section, related-work citations, open-problems paragraph in the discussion. If a student’s undergrad thesis built on QMIX-style value decomposition, the right match is the lab also building on QMIX, not the lab that happens to share the umbrella keyword “multi-agent.” The model that scores this match was trained on a corpus of admitted students’ theses paired with the supervisors who actually took them. It’s learned what “fit” looks like at the level of method, not topic.

These three signals fan out as parallel sub-queries against the knowledge graph. Programs and supervisors that surface across more than one path get promoted. A learned ranking model on top assigns a calibrated admit probability to each candidate. Calibrated meaning that when the model predicts 72% admit probability, roughly 72 of 100 similar students actually get in. We validate this against ~13K historical outcomes and re-fit weekly.

The output is a shortlist of 6 to 12 programs, ordered, with reasons. The student spends 30 minutes reviewing it rather than 30 hours building it.

Roughly a third of the strongest matches we surface for a student are programs they would never have found themselves. The fit was real, but it was hidden in the grant data, the job feed, or the methodology graph, not in the program description.

Stage 2: Reaching out

A shortlist is just a list. The next thing the student has to do is actually contact the labs.

This is where most PhD applicants quietly lose the cycle. They write 80 cold emails over the course of a month, get two replies, decide they’re not cut out for it, and lower their ambitions. Or they outsource the emails to a copywriting service and get worse results.

What we built instead is an outreach agent. For each professor on the shortlist:

• It reads their last 18 months of papers and runs a literature survey around the work (citation network, shared methodology nodes, open research gaps).
• It identifies the specific overlap with the student’s own work.
• It drafts a cold email that names a particular paper, the method behind it, and a specific gap the student could credibly extend.
• It sends from the student’s own Gmail with their CV attached, paced across the day so it doesn’t trip spam filters.

Replies come back to the student’s inbox. A classifier reads each one, tags it positive, negative, or neutral, and surfaces them in a single view ranked by who’s worth replying to first.

Real numbers from an applicant going through this right now. 90 emails sent over three weeks. 15 replies. 2 professors asking for a call. Among the rejections were honest ones we now feed back as signal: a UK professor said international funding was tight; an EPFL professor said no-master’s PhDs are structurally hard there; a 73-year-old professor wrote back that he was too old to take on new students.

On her own she was getting close to zero replies. With the agent running the literature survey before it writes, she’s at 20%+ reply rate. The matching opens the door. The grounded writing walks through it.

Stage 3: Writing the application

The application is where the system has to be most careful. An incorrect claim in an SOP doesn’t just lose the application. It permanently damages the student’s relationship with the lab. So generation here operates under two hard constraints.

First constraint: every factual claim has to trace to a node in the knowledge graph. The drafter doesn’t invent papers, doesn’t invent results, doesn’t invent collaborations. When the SOP says “your factored value decomposition framework scales QMIX-style decomposition to 64 agents,” that’s not generated text. That’s a literal reference to Professor X’s NeurIPS 2025 paper, looked up by ID.

Second constraint: the output has to pass adversarial AI detection. Admissions offices increasingly screen with Turnitin, GPTZero, and Pangram-class classifiers. If your essay scores 80% AI, your file gets flagged regardless of content. So after generation we run a per-token perplexity scan, flag spans that read as too “predictable” (the statistical fingerprint of LLM output), and rewrite them with specific evidence pulled from the citation subgraph. Repeat until the document scores below detection threshold.

The interesting side effect: the rewrites that fix the detection score also fix the writing quality. “I was catalyzed during my undergraduate studies” becomes “My HRT protocol breaks at 16 agents because per-agent value estimation grows O(n²).” One is template language. The other is a real research claim. Both are now indistinguishable from human prose, statistically. But the second one is also a better SOP sentence.

We also extract per-program style fingerprints from admitted SOPs at each lab. Admitted SOPs at MIT CSAIL read different from admitted SOPs at Stanford. The drafter uses these as style targets during generation. What works varies by committee.

The flywheel

The part of the system that doesn’t show up in a demo is the part that improves it.

Three feedback streams flow into the pipeline continuously. Outreach replies from our students’ inboxes, classified. Admit and reject decisions from completed applications. Interview invites from labs that wanted to talk.

When something goes wrong (a reject, a no-reply, a missed match) we run root-cause attribution. The diagnosis usually lands in one of three buckets:

• Data layer error. Outdated info on lab capacity, a stale professor profile, or a missed grant.
• Ranking error. We overweighted research fit and underweighted funding constraints, or vice versa.
• Generation error. The email or essay didn’t land for that specific committee.

Each bucket fires a different parameter update. Stale nodes get re-crawled. Ranking weights nudge in the right direction. Style parameters at the program level get retuned.

A concrete example. Last Tuesday a UK professor told one of our students that international funding was tight. By Friday, every UK lab in our matcher was being weighted differently for international applicants. The system didn’t have a “UK international funding scarcity” feature before that week. Now it does.

A student applying with us today gets recommendations that are quietly better than they would have been three months ago. Same model architecture. Different data. The model sits on a graph that learned in the meantime.

Why this isn’t ChatGPT with a system prompt

A reasonable skeptic will ask: GPT-5 will be very good. Why is this a real business and not a feature?

The honest answer is the moat isn’t the model. It’s the proprietary data layer.

Three things a foundation model can’t reach by ingesting more public data:

• Outcome documents. 100K real SOPs, LORs, and research proposals from applicants whose admit-or-reject outcomes we know. This is the corpus the style fingerprinter and the admit probability calibrator both train on. It exists only because students who came through Ambitio shared it with us.
• Alumni trajectories. 2M alumni career outcomes tied to specific labs and cycles, enriched with their original applications. This is what lets us answer “what happens to people like me five years after admit?”
• Live reply outcomes. Every outreach reply from every student’s inbox, classified and structured, telling us which professors are responsive this cycle, which labs are constrained, and what kinds of pivots get a yes.

Every reply and every outcome feeds back into the matcher and the calibrator. A student running our pipeline today benefits from every student who ran it before her. The model is a wrapper. The data is the moat.

What it adds up to

The PhD application is a four-month, 40-hour-per-week project that students do once in their lives with no feedback loop and no benchmark. They do it badly because no one’s life is structured to do it well.

What we built is a pipeline that walks them through it. Find the right labs. Reach out with something specific to say. Write applications that are factually grounded and statistically indistinguishable from strong human writing. Every outcome feeds back into the system so the next student does it better.

It’s not magic. It’s a knowledge graph, a retrieval pipeline, a generation system with hard constraints, and a feedback loop. Useful technology built on the unglamorous foundation of clean data and patient calibration.

If you’re applying this cycle, we’d like to help.

https://ambitio.club/