Skip to main content
Filters run before ranking. They cut the candidate pool down to only chunks matching the criteria, so ranking works on a focused set.

​
What you can filter on

Every enriched chunk carries metadata. Common filterable fields:
  • Tags — any tag added by the Auto-tag enricher.
  • Source — which document, folder, or database row.
  • Path — heading path or folder location.
  • Language — the chunk’s detected language.
  • Entities — extracted people, orgs, products.
  • Modified date — when the source was last updated.
  • Custom fields — anything an inline enricher wrote.
Add fields via the Enrich stage.

​
Filter expressions

Filters are expressed as JSON-ish predicates. Examples:
Operators: $eq, $ne, $in, $nin, $gt, $gte, $lt, $lte, $contains, $startsWith, $exists, $and, $or, $not.

​
Filters at three levels

Filters compose across levels. Anything set at a higher level applies to all lower ones.
  1. Data source level — attached to a document collection. Applies to every query against it.
  2. Preset level — inside a Retrieval preset. Applies to every Agent using the preset.
  3. Query level — set per-call, at runtime. Set by the Agent via a special tool argument, or by your code.
Runtime filters merge into preset filters (both must match). This lets an Agent narrow further without exposing “you can only search customer-facing docs” as a system rule.

​
Dynamic filters from variables

Filters can reference Flow variables:
Common pattern: per-tenant scoping. Set the variable at run start with the requester’s tenant ID, and every retrieval is automatically scoped.

​
Testing

The preset Test panel lets you set a runtime filter and see how it changes the results. Great for validating access control before shipping.

​
Performance

Filters on indexed fields (tag, source, date) are free — they run at index scan time. Filters on unindexed custom fields degrade to a post-fetch scan and get slower with collection size. Add an index on hot filter fields via the collection settings.