Natural Language Filters
Let people describe what they want to see and turn it into filters they can inspect and edit.
What it adds
A plain-language input on list views that produces the app's normal filter chips, shown for review before they apply.
What your agent is told to do
5
What your agent is told to do
5-
1
Give the model a machine-readable description of the filterable fields, their types, their allowed operators, and their permitted values, derived from the app's existing filter definitions. It selects from that description and returns a structured filter set; it does not write query syntax.
-
2
Render the result as the app's ordinary filter controls, in the pending state, and require the user to apply them. Do not run the query on the model's output directly, and do not skip the review step even when confidence looks high.
-
3
Resolve relative expressions such as last week or this quarter against the user's time zone and the workspace's week and fiscal-year settings, and show the resolved absolute dates in the chip so the user can see what was assumed.
-
4
Run the resulting filters through the same permission and scoping layer the manual filters use. The natural language path must not be a second, weaker route to the same data.
-
5
This feature produces filters for an existing list. Building a report configuration with metrics, groupings, and aggregations belongs to Natural Language Report Builder, and free-form querying belongs to Natural Language Database Query. Share the field and glossary definitions across all three rather than maintaining three vocabularies.
Edge cases it handles
8
Edge cases it handles
8- A request naming a field or value the app does not support must fail visibly. Map only to declared fields and operators, and tell the user which part of their request could not be interpreted rather than quietly dropping it.
- Filters must always be shown before they are applied, so the user can see that high-value was read as a specific amount threshold and correct it. Applying silently teaches users to trust an interpretation they never saw.
- Relative dates resolved in the server's time zone will be off by a day for much of the world. Resolve in the user's zone and display the absolute range that was chosen.
- When a term maps plausibly to more than one field, ask rather than guess. Present the candidate interpretations and let the user pick.
- Generated filters must pass through row-level permissions exactly as manual ones do. A filter set that widens scope beyond what the user may see is a security defect, not a relevance problem.
- The user must be able to edit or remove any generated filter afterwards, and the chips must behave identically to manually added ones from that point on.
- If the model is unavailable, times out, or returns output that does not validate against the field definitions, the manual filter controls must remain fully usable and the input should say the interpretation failed.
- Free text typed by a user can contain instructions aimed at the model. Treat the input strictly as a filter request and validate the structured result rather than trusting it.
Definition of done
9
Definition of done
9- Generated filters reference only declared fields, operators, and value types, and anything unmappable is reported to the user.
- Filters are always displayed for review and require an explicit apply.
- Relative dates resolve in the user's time zone and the resolved absolute range is visible.
- An ambiguous term produces a clarification prompt rather than a silent choice.
- Generated filters pass through the same row-level permission checks as manual filters.
- Every generated filter can be edited or removed and behaves as a normal filter thereafter.
- Model failure or invalid output leaves the manual filter controls working and states that interpretation failed.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Retrieval-Augmented Generation
Retrieval-Augmented Generation
Ground AI answers in the app's own content by retrieving source passages first.
What it does
A retrieval layer that selects permitted passages from app content and supplies them to the model as cited evidence.
How it works
- 1 Decide which content is answerable from and treat everything else as out of scope. A retrieval feature pointed at the whole database returns confident answers about records nobody meant to expose.
- 2 Apply the requesting user's tenant, record, and field permissions during retrieval, before any passage is assembled into a request. Filtering the answer afterwards is too late — the content has already crossed the boundary.
- 3 Chunk on the content's own structure — sections, headings, rows, message boundaries — and carry enough surrounding context in each chunk that it still means something on its own.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/retrieval-augmented-generation
AI Insight Cards
AI Insight Cards
Turn a report into a few grounded cards, each tied to a number the app calculated.
What it does
A small set of cards summarising notable movements in a report, each linked to the query and figure that produced it.
How it works
- 1 Detect candidate movements in the app first, using the report's own aggregations. The model ranks and phrases the candidates it is given; it does not go looking for them and it does not produce the arithmetic.
- 2 Bind each card to the query, metric, and period that support it, and make the card link through to the filtered view so a reader can check it in one click.
- 3 Set a materiality threshold before generation, in both relative and absolute terms, so a swing on a metric with three events does not outrank a real change on a metric with thousands.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ai-insight-cards
AI Dashboard Insights
AI Dashboard Insights
Explain what actually changed on a dashboard, in the viewer's own filters and period.
What it does
A short generated commentary attached to a dashboard, describing the movements that matter under the filters currently applied.
How it works
- 1 Compute the numbers first, in the app, using the dashboard's existing queries with the viewer's active filters. Pass the model the computed figures and let it write the wording, never the raw rows to add up itself.
- 2 State the period and the comparison period explicitly in every insight. A sentence saying signups are up is meaningless without saying up against what.
- 3 Filter the input to metrics the viewer is permitted to see before it reaches the model. A commentary that mentions revenue to someone whose dashboard hides revenue is a permissions leak.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ai-dashboard-insights
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.