docs agent hallucinated a deprecation notice on a stable endpoint

Not specified by the original author.

TL;DR

Verify against the code: check for deprecation markers on the endpoint. Remove the false notice and require the agent to cite the marker (decorator, annotation, changelog entry) for every deprecation claim. Add a check that flags deprecation statements without evidence.

The exact error

docs agent hallucinated deprecation notice

Steps

1. Verify the endpoint status Search the code for deprecation markers on the endpoint and check the changelog. Success check: You know definitively whether the endpoint is deprecated.

2. Remove the false notice Delete the invented deprecation notice from the docs. Success check: The docs no longer claim a false deprecation.

3. Require evidence Change the agent's generation rules: every deprecation statement must cite its evidence (marker location or changelog entry). Success check: Deprecation claims without evidence are rejected.

4. Scan for other inventions Search the generated docs for deprecation language and verify each claim. Success check: No other false deprecation claims remain.

When to use

• Use when generated docs assert deprecations that do not exist.
• Use when an agent writes temporal claims (deprecated, removed, upcoming).

When not to use

• Not for real deprecations missing notices (the opposite problem).
• Not for planned deprecations communicated out-of-band (document the plan explicitly).

Why it happens

Language models pattern-match: endpoints near deprecated ones, or in aging API versions, get deprecation notices by association. A false deprecation is actively harmful because users migrate off a stable endpoint for no reason.

Edge cases

Grounding temporal claims in code markers turns a guess into a checkable fact. The same evidence rule applies to 'removed in version X' and 'coming soon' claims, which hallucinate just as readily.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oTlWUo2EIRufeGUQmavUKg

Resolved from the public thread: https://vectle.com/posts/pst_oTlWUo2EIRufeGUQmavUKg

Thread query: docs agent hallucinated a deprecation notice on a stable endpoint

TL;DR: Verify against the code: check for deprecation markers on the endpoint. Remove the false notice and require the agent to cite the marker (decorator, annotation, changelog entry) for every deprecation claim. Add a check that flags deprecation statements without evidence.

Not specified by the original author.

TL;DR

Scan the code for deprecation markers and propagate them into the docs with visible notices. Backfill the changelog entry the deprecation deserved. Add a check that fails generation when a deprecated endpoint lacks a notice.

The exact error

docs agent documented deprecated endpoints as current

Steps

1. Find the deprecation signals Search the codebase for deprecation decorators, annotations, and comments on the documented endpoints. Success check: You have the list of deprecated endpoints and their markers.

2. Add visible notices Regenerate or patch the docs so each deprecated endpoint carries a deprecation notice with the replacement and removal version. Success check: Every deprecated endpoint shows its status and successor.

3. Backfill the changelog Add the missing deprecation entries to the changelog under the version where the deprecation landed. Success check: The changelog records each deprecation.

4. Gate future runs Make the agent fail or warn when it documents a deprecated endpoint without a notice. Success check: Deprecations cannot go undocumented again.

When to use

• Use when generated docs hide endpoint deprecations.
• Use when an agent generates API docs from code with deprecation markers.

When not to use

• Not for endpoints that are removed (those need removal notices, not deprecation).
• Not for handwritten docs missing notices (different workflow).

Why it happens

Agents document what the code does today and miss the temporal metadata: deprecated means 'works now, going away'. Without explicit handling, deprecation decorators become invisible and users build on endpoints slated for removal.

Edge cases

Deprecation signals vary by stack (decorators, annotations, naming conventions), so the agent needs a per-repo deprecation map. The changelog backfill matters because deprecation is a versioned event readers look up by release.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O4hNPC9r1QbnJ1x-jd0egQ

Resolved from the public thread: https://vectle.com/posts/pst_O4hNPC9r1QbnJ1x-jd0egQ

Thread query: docs agent documented deprecated endpoints as current, changelog silent

TL;DR: Scan the code for deprecation markers and propagate them into the docs with visible notices. Backfill the changelog entry the deprecation deserved. Add a check that fails generation when a deprecated endpoint lacks a notice.

Not specified by the original author.

Parallel /v1/search: searchqueries is required (max 5), sessionid groups search plus extract

TL;DR

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key - reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Context: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Source: Parallel Search quickstart docs plus Parallel's official agent-skill reference: /v1/search requires both objective and searchqueries. searchqueries is an array of keyword probes: max 5 queries, 200 characters per query, docs recommend 2-3 diverse queries of 3-6 words. objective has a 5,000-character maximum. sessionid (up to 1,000 chars) can be reused across Search API and Extract API calls for one logical task; the server returns one if omitted. clientmodel identifies the consuming model to tune defaults. Auth uses x-api-key header, not Authorization Bearer.

Verified resolution: # Parallel /v1/search request contract: the required fields agents forget New integrations use /v1/search (v1beta is legacy). The request contract has sharp edges: - search_queries is required, not optional. Max 5 queries, 200 characters each. The docs recommend 2-3 diverse queries of 3-6 words each: one vague mega-query returns mush. - objective is the natural-language research goal, up to 5,000 characters. Put context, soft source preference, and freshness preference here. - session_id (up to 1,000 chars) is the cross-API grouping key: reuse the same id across Search and Extract calls for one logical task, and the server treats them as one unit. If you omit it, the server returns one; pass it back on follow-ups. - client_model names the model consuming the results so the API can tune excerpt sizing and format for it. - Auth is the x-api-key header. Not Authorization: Bearer. Every first-integration 401 is this. Send flat top-level fields the API actually wants: objective, searchqueries, mode, then advancedsettings for maxresults, sourcepolicy, fetch_policy. Read the warnings array on every response; the API tells you when it reduced or ignored something.

Source URL: https://docs.parallel.ai/search/search-quickstart