Griptape Vector Store: Query

This is the node that makes a vector store actually useful. The nine "Vector Store Driver" nodes in this pack are just configuration - they say where vectors live. This one asks the question: given this text, what's already stored that's closest to it? It's the retrieval half of RAG, and in a Griptape workflow it's the piece that turns "the agent knows things" into "the agent knows your things."

How it works

You give it a query string, it embeds that string with the same embedding driver the store was built with, then hunts for the nearest stored chunks and returns them as text. Two things to know about how it gets its store: the node reads the vector store from the agent's own configuration (agent.drivers_config.vector_store_driver under the hood). So the wiring order matters - vector store driver → Structure Config → Create Agent → this node's agent input. No driver, no query; you'll get nothing useful.

The inputs that matter

The required inputs are where the action is:

• agent - the agent whose configured vector store you're querying. The output AGENT passes the same agent through untouched, so you can keep the chain going.
• STRING - your query, the multiline prompt you're searching with.
• namespace (default default) - Griptape stores can be split into namespaces. If you added text under a custom namespace, you must match it here or you'll search an empty shelf and get nothing back.
• count (default 1) - how many chunks to return. Bump it to 3–5 when you want real context, not just the single closest hit.

The optional input_string is a force-input version of the query, handy when the text comes from another node rather than being typed. And key_value_replacement (a DICT) lets you drop values into {{ placeholders }} inside the query text before it runs - useful when you're templating the same search for different subjects.

What you get out

OUTPUT is a STRING - the retrieved chunks joined together. That's the context you feed to a prompt task or agent so it can answer grounded in your data. AGENT passes the agent through for chaining. Note what this node doesn't do: it doesn't answer the question. It fetches the material. The LLM still has to write the answer with that material in front of it.

Common issues

The biggest beginner trap is the embedding mismatch. If the query uses a different embedding driver than the one that indexed the text, retrieval is garbage and you won't immediately know why. Keep one embedding driver across Add Text and Query. Second: forgetting the namespace. Third, and this one stings - if you expected to see your freshly added text in results, check that you actually wired the same store into the agent's config. A default agent with a default store quietly returns nothing. This node is also the classic place people hit the pack-wide torch conflict after install, so if it errors on load, check the Griptape README's torch fix before assuming the node is broken.

Install is the same as the rest of the pack: ComfyUI Manager (search "Griptape") or git clone https://github.com/griptape-ai/ComfyUI-Griptape into custom_nodes, restart, and make sure griptape[all] actually installed.