Skip to main content
Everything a block knows arrives through exactly one of two mechanisms.

​
Inline vs. Knowledge Source

The two failure modes are mirror images. Inline content that is too long crowds out your instructions. A Knowledge Source searched with a vague prompt returns the wrong extracts. Match the mechanism to the content.

​
Brains vs. Document Uploads

Ask whether the dataset changes with every run.
  • Stable and shared across runs becomes a Brain. Methodology guides, scoring rubrics, product catalogs, regulation texts. The designer attaches it once; every run uses it.
  • Different on every run becomes a Document Upload. The CV to screen, the contract to review, the RFP to answer. The end user provides it at runtime.
A Brain can be attached two ways:
  • Fixed at block level: this block always searches Brain X. This is the normal case.
  • As a user-selectable input: let the user pick one file from dataset X.
Pick fixed unless the user genuinely needs to choose. A fixed Brain keeps the App deterministic; a user-selectable Brain adds a decision the runner has to make correctly on every run.
See Creating Brains to build a stable dataset, and Connectors to keep one synced from a source system.

​
Every search needs context

A block that searches a Knowledge Source retrieves what the prompt asks for, nothing more. A prompt that just says “analyze the document” retrieves arbitrary extracts. Always give the retrieval something to aim at.
The preferred approach uses a short upstream output as the search query: the inline variable acts as the target the retrieval aims at. Use the fallback, descriptive text in the prompt, when no suitable upstream variable exists.
Vague prompts produce vague results here as everywhere else on the platform. See Brains for how retrieval works under the hood.

​
Next

Passing Data Safely Between Blocks

Routing the hand-offs between blocks, and how to get them right.