Back to Blog

Agent workflows

Crossref or OpenAlex? Plan What Your Research Agent Must Retrieve

Choose metadata and full-text discovery paths separately. Preserve search provenance, candidate exclusions and version-specific access before drafting a research brief.

OpenAgentSkillPublished:

A list of papers is not a set of readable sources

Suppose you ask a research agent for a brief on methods for extracting tables from scanned documents. It returns twenty titles. Some records include abstracts, some point to publisher pages and others have repository copies.

Before writing the brief, you need to know which materials were actually available. Otherwise, the most accessible papers can quietly become the entire evidence base, while inaccessible but relevant work disappears without explanation.

Crossref and OpenAlex can support different parts of this retrieval plan. The useful comparison is not which API is universally best, but which record you need next and what that record does not establish.

Methodology and intended audience

This documentation-based guide was checked on September 14, 2026 against Crossref's REST documentation and OpenAlex's work and location references. It is intended for developers building research skills and researchers reviewing an automated search handoff.

We did not run a literature search, compare corpus recall, download papers or evaluate a scientific claim. The scanned-document example is hypothetical. The workflow below is an editorial proposal, not a completed systematic review.

Selection criteria are metadata needs, available document versions, request discipline and the ability to explain exclusions. Do not select a provider by a claimed paper count without checking whether its coverage fits your field.

Choose Crossref for the deposited record you need

The Crossref REST API exposes metadata deposited by members and trusted sources. It supports searching and filtering, and provides records that may include bibliographic information, references, license information and updates. It is a metadata interface, not a promise that every returned work includes a downloadable full text.

Use it when your task starts with a Crossref DOI or needs a structured search over the deposited records. Decide which fields matter before retrieval. For a preliminary brief, that might be identifiers, title, authors, dates and links, rather than every field available.

Do not convert a missing abstract into an empty finding. Keep absence as a data condition. If a candidate still matches the research question, route it to an access check or human follow-up instead of silently excluding it.

Choose OpenAlex when the work record and locations matter

The OpenAlex work attributes describe identifiers, bibliographic fields, abstract data and links to locations. An abstract may be represented as an inverted index rather than a plain-text field. The work record also separates its primary location from its best open-access location.

This can be useful when the next step is to organize candidates and inspect where copies are available. Do not infer that a record with an open-access flag has already been fetched, parsed or reviewed by your agent.

Store provider identifiers alongside the DOI when present. Preserve the original provider response or a permitted, sufficient field snapshot. This makes a disagreement inspectable: a changed date, a missing field or a different location can be traced to a record rather than attributed to an unexplained model judgment.

Retrieve a specific copy, not an abstract idea of a paper

The OpenAlex location reference distinguishes landing-page URLs from direct PDF URLs and records the copy's version and license where known. A work can have multiple locations, including submitted, accepted and published versions.

Treat that distinction as part of the handoff. Our recommended access record names the work identifier, selected location, reported version, retrieval time and actual result. Preserve unknown license or version values rather than filling them from the repository's general description.

A landing page is not a PDF. A successful download is not proof of correct extraction. After an authorized retrieval, check that the file belongs to the intended candidate and record whether the agent inspected metadata, an abstract or the full text. Follow the source's access and reuse conditions; do not treat discoverability as permission to bypass restrictions.

Keep a candidate ledger before drafting

For the illustrative scanned-document brief, write inclusion rules before viewing results. Define the document type, intended task, date scope and what counts as relevant evidence. Record query wording and filters separately for each provider; similarly named controls should not be assumed to mean identical things.

Use a ledger with these fields:

  • Discovery: provider, query, filters, retrieval time and returned identifier.
  • Screening: included, excluded or unresolved, with a short reason.
  • Access: metadata only, abstract available, selected copy available or retrieval failed.
  • Version: the copy examined and the location that supplied it.
  • Next action: inspect a passage, request an authorized copy or ask a reviewer.

Keep relevance and access in separate columns. A paper can be relevant and inaccessible. A freely available document can be irrelevant. That simple separation prevents an agent from turning download convenience into an unstated research criterion.

Spend requests on unresolved questions

Set a bounded retrieval plan: a candidate limit for the initial pass, a stop condition and an explicit follow-up budget. Deduplicate repeated identifiers within the run. Do not call every provider for every record unless the second call answers a real missing-field or coverage question.

Cache permitted responses with retrieval times and distinguish a reused response from a fresh check. Before scaling, inspect the provider's current authentication, access and rate-limit guidance. This article deliberately gives no universal free-request allowance or cost estimate.

Only send a model the material needed for the current judgment. An initial relevance screen may not require parsing every full document. Conversely, a claim about a table cannot be supported by metadata alone. Saving requests is useful only if the evidence needed for the conclusion remains available.

Limitations and the next review step

This plan does not guarantee complete literature coverage. Indexing delays, metadata gaps, version differences and unavailable copies can change the candidate set. A bounded exploratory brief must not be presented as an exhaustive review.

Hand over the ledger with the narrative. State what was searched, what was excluded and which unresolved access questions could change the conclusion.

Our DOI and citation-check workflow addresses identity, updates and claim support after retrieval. Our PDF parser comparison addresses extracting the selected documents. This article covers the earlier decision: what to retrieve and how to keep that selection visible.