Skip to main content
Resolve any named thing — person, company, place, or other entity — by free-text name in one union search. Each candidate carries a type (person, company, place, or other) and the canonical slug for that type. Use this first whenever you only have a name and don’t know what kind of thing it names. The slug each result hands back is already the right handle for that type’s downstream tools — no second resolve step: If you already know it’s a person, particle_person_resolve ranks people only; for companies with a known ticker, domain, CIK, or QID, particle_company_resolve has more identifier surface. For bulk resolution, pass a comma-separated query — each name is resolved independently in a single call and limit applies per query.

​
Inputs

FieldTypeRequiredDefaultDescription
querystringyes—Free-text name(s) of a person, organization, place, or company (e.g. "sam altman", "nvidia", "davos"). Case-insensitive. Comma-separated for bulk lookup — each query is resolved independently and grouped in the response.
limitinteger (1–10)no5Maximum candidates per query.

​
Output

A markdown document with one section per input query, separated by horizontal rules in multi-query responses.
  • Queries with matches render as a ## Entity matches for "<query>" (N) heading followed by one ### Name section per result. Each result leads with - **Type:** (person / company / place / other), then a type-aware handle row whose label matches the type — - **Person slug:**, - **Company slug:**, or - **Entity slug:**. Person results add - **Title:** and - **Company:** (the person’s current role) when known; company results add - **Ticker:** and - **Domain:**; - **Description:** and - **Wikipedia:** appear when present.
  • Queries with no matches render as a single No entities matched "<query>". ... paragraph (no H2 heading), so the caller can see which input failed without losing the rest.
For person-backed results the handle row is the canonical person slug, not the underlying knowledge-graph entity slug. The KGE handle is suppressed deliberately — the agent must never receive a competing identifier that diverges from the canonical one. Company-backed results expose the entity slug, which is the canonical company slug. Sample (query="Marc Andreessen, nvidia", limit=1): 
## Entity matches for "Marc Andreessen" (1)

### Marc Andreessen

- **Type:** person
- **Person slug:** marc-andreessen
- **Title:** General Partner
- **Company:** Andreessen Horowitz
- **Wikipedia:** https://en.wikipedia.org/wiki/Marc_Andreessen

---

## Entity matches for "nvidia" (1)

### Nvidia

- **Type:** company
- **Company slug:** nvidia
- **Description:** Nvidia is a leading developer of graphics processing units. …
- **Ticker:** NVDA
- **Domain:** nvidia.com
The first result in each block is usually the one you want for unambiguous queries. For ambiguous names read the - **Title:** / - **Description:** / - **Wikipedia:** rows to disambiguate.

​
Example

User: Find every recent podcast where Marc Andreessen is mentioned.

Agent calls: particle_entity_resolve { "query": "Marc Andreessen" }
            → reads "- **Type:** person" + "- **Person slug:**" → "marc-andreessen"

Agent calls: particle_podcast_find_mentions { "person_slug": "marc-andreessen", "limit": 10 }

​
Bulk resolution

User: Pull mentions for Sam Altman, Kara Swisher, and Marc Andreessen.

Agent calls: particle_entity_resolve { "query": "Sam Altman, Kara Swisher, Marc Andreessen" }
            → reads each block's handle row → ["sam-altman", "kara-swisher", "marc-andreessen"]

Agent calls: particle_podcast_find_mentions { "person_slug": "sam-altman", ... }
            (etc., one call per resolved slug)