Vector Store Node

A Vector Store is a knowledge container that an AI agent can read from to answer questions about your own documents — PDFs, Markdown, FAQs, policies, manuals, anything textual. Drop the node, fill it with docs, wire it into an agent, and the agent's answers stay grounded in your material instead of guessing.

Quick start

1. Drag a Store node from the side panel (the database-cylinder icon with three connected nodes, between 2Vec and Sheet).
2. Double-click the node to expand it, then click Edit in the header. A NotebookLM-style tab opens.
3. Click Add files (or drop files onto the editor) — PDFs, Markdown, text. The store chunks and indexes them automatically.
4. Use the chat area on the right to ask questions of just those docs. Answers cite which document each fact came from.
5. Back in the workflow, wire the Store node into an Agent. The agent will use the store's content when answering.

Filling the store with documents

Inside the linked editor, the left column is your source-docs list. Drop in:

• PDF files — text is extracted and chunked.
• Markdown / Text — added as-is.
• Most plain-text formats (CSV, JSON, source code, YAML, etc.) work the same way.

Each doc is broken into chunks (roughly half a page each) and indexed. You'll see the chunk count appear when indexing finishes. The first time you ingest with the Browser runtime, the indexer model downloads (about 25MB, cached after that).

Asking the store directly

The middle column is a chat that knows only about the docs you've added. Use it to verify the store has the knowledge you expect before wiring it up to a real agent. Citation chips below each answer show which doc supplied the information.

This chat is independent of any agent in your workflow — it's a sanity-check tool.

Letting the Prompt Wizard write the agent for you

If you'd rather describe what you want in plain English, click the ✨ Prompt Wizard button on any Agent node. The wizard reads your workflow context — including every store wired to that agent plus your other resolvable stores — and turns intents like "use Product FAQ for product lookups, FCA Regulations for compliance" into a properly-structured agent prompt with the right {{store:…}} template variables already in place.

Add hints like "closed-book" / "only use the store" / "fall back to general knowledge" and the wizard adds matching strictness instructions to the prompt. The output is regular editable text — you can tweak it by hand afterwards.

Three ways to use a store in a workflow

Pick the mode that matches how deterministic you want the behavior to be. They compose: an agent can use one mode for one store and a different mode for another.

1. Wire it directly into an Agent — "let the AI decide when to use it"

Drag a wire from the Store node to an Agent node. When the agent runs, it receives a short awareness block on its system prompt: "You have access to the Product FAQ store (3 docs, 18 chunks). Search it with the search_product_faq tool when relevant." The AI decides on each turn whether to look something up.

You can wire multiple stores into one agent. Each becomes its own search_<store> tool, named after the store. The AI picks the right one per question.

This requires a tool-capable AI (Claude, GPT-4, Apple Foundation Models, etc.). For smaller / local models without tool calling, use one of the other modes below.

Give each store a clear description (in the editor's settings) — that's the single most important thing for the AI to pick the right tool at the right moment.

2. Inline template variable — "always look it up"

In any node's text field, write:

{{store:my-store-name|q=upstream-question|k=5}}

That gets replaced at run-time with the top-5 retrieval results. Use this when you want retrieval to fire every turn, regardless of what the AI would decide. Common in agent system prompts:

Use these passages to answer:

{{store:Product FAQ|q={{input}}|k=5}}

User question: {{input}}

The q= argument is the query string — typically a template referencing upstream input. Default k is 5.

You can reference any store by name, including ones that aren't wired into the current node — handy when you have shared knowledge bases used across many workflows.

3. As a pipeline step — "always inject the chunks"

Chat → Vector Store → Agent. The chat output becomes the store's query, the store outputs chunks, and the chunks flow into the agent as input data. Useful when you want retrieval to happen every turn AND you want a non-tool-capable model to receive the chunks as graph data (no tool calls required).

Insert a Code node in the middle if you want to rewrite the query before retrieval: Chat → Code (extract keywords) → Vector Store → Agent.

Chat → Agent (driver mode)

When a Chat node is wired straight into an Agent node, typing a message in the chat doesn't just pass text to the agent — the chat borrows the agent's prompt and model for the reply. The setup is: you author the agent's prompt (manually or via the Prompt Wizard) with whatever template variables and store references you want; the chat then becomes a low-friction UI for talking to that configured agent.

In this mode the chat send:

• Resolves {{input}} in the agent's prompt to the message you typed.
• Resolves any {{store:…}} references in the prompt (retrieval fires before the LLM call).
• Gives the LLM access to search_<store> tools for any vector stores wired upstream of the agent — so a tool-capable model can pull more on demand.

You don't have to "Run" the workflow — sending a message triggers the agent automatically.

Closed-book vs open-book — controlling strictness

Independent of the integration mode above, you control whether the AI is constrained to your store's content or augmented by it:

You set strictness by phrasing in the agent's system prompt — for example:

• Closed-book: "Use ONLY the provided context. If the answer isn't there, say so."
• Hybrid: "Use the provided context first. For anything outside its scope, answer from your general knowledge."
• Open-book: "Use the provided context to enhance your answer where relevant."

The store editor's scoped chat has a Closed / Open toggle so you can verify both modes against the same docs before deploying.

Writing good store descriptions

The description (set in the store's settings) is the single most important thing for retrieval quality when stores are wired into agents. The AI reads it to decide whether and how to use the store. Vague descriptions like "FAQ docs" get ignored; specific ones like "UK Financial Conduct Authority regulations on consumer credit. Use for licensing and compliance questions." get used at the right moment.

Picking an embedding runtime

Stores can index using different runtimes. You pick one in the settings panel.

Changing runtime requires re-embedding the existing chunks (the new runtime uses a different embedding space). The editor surfaces a clear "Re-embed required" prompt; documents stay, only the index rebuilds.

Workflow-local vs global stores

By default, a store belongs to the workflow you created it in. Flip the Global toggle in the store's settings to make it available to any of your workflows — useful for shared knowledge bases.

When to use which:

• Workflow-local — domain-specific to one workflow. A shopping bot's product catalog, a single customer's documents, etc. Default. No sharing risk.
• Global — shared across all of your workflows. A company handbook, a regulation set you reference everywhere, customer history common to all your support flows. Promote to global from the editor's settings panel.

Template-variable lookups ({{store:name}}) resolve workflow-local stores first, then your globals — so a workflow-local store can shadow a global of the same name.

Picking a store from another workflow: the store-picker dropdown on the Vector Store node header lists workflow-local stores at the top and your globals below. Selecting a global from one workflow makes the new node a second view of the same store — same docs, same chunks, but with the new node's own retrieval settings (top-K, etc.).

Cross-device & cross-account: stores you create while signed in mirror to cloud storage automatically. Opening the same workflow on another machine pulls the store down without re-ingesting. (Stores created while signed out stay local until you sign in and edit them.)

Per-node tuning

Each Vector Store node has its own retrieval settings, accessible from the right config panel (the gear button on the node):

• Top-K — how many chunks to retrieve per query (default 5). Set 0 to bypass retrieval entirely.
• Max tokens injected — hard cap on total tokens in the retrieval output (default 4000). Low-rank chunks beyond this are dropped.
• Query — a template string used in place of the upstream input. E.g. {{input.value}}.
• Output format — with-titles (chunks separated by source doc), flat (chunks only), or json (structured).

Two nodes referencing the same store can have different retrieval settings — one returns 3 chunks for a summariser, another returns 10 for a detailed researcher.

Multiple Vector Store nodes per workflow

Drop as many as you like. By default, each new node creates a fresh empty store. If you want two nodes to share a store, point both at the same store ID (the right config panel shows the backing store ID).

Renaming the store on the canvas, in the editor, or via the node header all keep in sync — there's one source of truth.

Troubleshooting

• "The store has no relevant content for this question." — Either your docs don't cover this topic, or the indexed chunks are too granular. Try asking the editor's scoped chat the same question to confirm it's a content issue, not a wiring one.
• The AI ignores the store — Wire it directly into the agent (not via an intermediate node), or check the store's description. Vague descriptions don't get used.
• Tab name doesn't update after rename — known limitation; close and reopen the tab.
• Webhook workflow returns empty chunks — Server-side retrieval requires cloud-API embedding (OpenAI). Re-embed the store with the OpenAI runtime to enable headless runs.