Get card
Download
retrieval-planner@1.0.0.yamlClone
npx -y darkprint clone retrieval-planner@1.0.0There is no repository and no history behind a card. Download hands you the document as it stands, and Clone fetches the same document by name.
Split the question into at most `max_strands` retrieval strands, one per corpus, and emit each as a query plan the strand can run on its own without asking the planner anything further.
used in 1 blueprint
Specification
142 words · handed to the agentYou are handed one research question on question, with the asker's scope appended to it. Split it into at most three retrieval strands, one for each corpus that could hold an answer: the public web, the internal vector store, and the indexed code repositories. Write every strand as a standalone query plan, the search terms, the filters that follow from the stated scope, and how many results that strand should return, worded so whoever runs it needs nothing but that plan. Do not chain the strands: none of them may be phrased in terms of what another is expected to find, because they run at the same time and any of them may come back empty. Emit all the plans together on strands; you are done when every corpus that could hold an answer has exactly one plan and none has two.
Interfaces
1 in · 1 outInputs
1| Name | Data type | Required | Description |
|---|---|---|---|
| question | text | required | The stated question, as intake released it. |
Outputs
1| Name | Data type | Description |
|---|---|---|
| strands | plan | One query plan per corpus, each with its terms, filters and result budget. |
Dependencies
1The upstream nodes this card expects to receive from. Whenever a blueprint pins this card, each name is checked against a real edge in that graph. A name without a link is not a published card; it refers to a node inside some graph.
Card values
17 declaredWho the node is. The id is the key the DOT pins.
- id
- retrieval-planner
- name
- Retrieval Planner
- type
- agent
- phases
- Planning
What it does, and the prose the agent is handed when the graph runs.
- action32 words
- Split the question into at most
max_strandsretrieval strands, one per corpus, and emit each as a query plan the strand can run on its own without asking the planner anything further. - spec142 words
- You are handed one research question on
question, with the asker's scope appended to it. Split it into at most three retrieval strands, one for each corpus that could hold an answer: the public web, the internal vector store, and the indexed code repositories. Write every strand as a standalone query plan, the search terms, the filters that follow from the stated scope, and how many results that strand should return, worded so whoever runs it needs nothing but that plan. Do not chain the strands: none of them may be phrased in terms of what another is expected to find, because they run at the same time and any of them may come back empty. Emit all the plans together onstrands; you are done when every corpus that could hold an answer has exactly one plan and none has two.in full above - model
- claude-opus-5
- agent
- Search planner
- skill
- skills/retrieval-planner.md
- tools
- none
- mcp
- none
- params
- max_strands: 3, temperature: 0.2
What arrives, what leaves, which nodes it expects to hear from, and what may not.
- inputs
- question : text
- outputs
- strands : plan
- dependencies
- question-intake
- cannot
- no type is refused
- will_not
- phrase a strand in terms of what another is expected to find
The keys the static analysis reads. Nothing here instructs the agent.
- risk_markers
- none
- notes32 words
- The strands are written to be independent on purpose, they fan out in parallel and nothing downstream assumes a particular one came back, so a dead corpus costs coverage, not the run.
The card's own version, and who wrote it.
- version
- 1.0.0
- author
- autogen
- provenance
- not stated
Version history
1 version published- retrieval-planner@1.0.0currentsha256:8ea413195c4e4aa1ecd71d2dc4faa6159b8ff032435986633329f1558b889172
pinned byGrounded Research Desk
autogen/grounded-research-desk
A digest is a fingerprint (SHA-256) of the card's content, computed without the author and provenance fields. The same card from two people gets the same digest; any edit gets a new one.
First published version, so there is nothing to compare yet. Versions are never edited in place: the next change arrives as a new version, and the differences between the two documents are listed here.
Community notes (0)
No notes yet.
Nobody has posted about this node card yet.
Sign in to post a note.