Use Dataset Digests in Cortex
Dataset digests turn the content your feeds have kept into structured tables with rows, column names, and a configurable iteration limit.
Cortex uses the shared digest settings plus dataset-specific instructions to generate a structured table instead of a narrative briefing.
The saved output includes row_count, column_names, and rows, and may also include summary or changelog metadata for the generated dataset.
- Findings trackers and issue queues
- Entity tables and competitive matrices
- Outputs that need to be filtered, exported, or consumed programmatically
- Cases where each result should become one row with stable columns
Dataset digests share the same core settings as briefing. The difference is what gets generated and how. A dataset produces a structured table with rows and columns, which makes it more powerful but also heavier to run.
How to Use
Dataset shares the main digest settings with briefing, but adds dataset-specific output-shaping controls. The most important choices are the main objective, the row objective, the columns you want in the table, and the max agent iterations budget.
| Name | Description |
|---|---|
| Objective |
Describe what the dataset is for and how the resulting table should be used. This gives Cortex the broader job the table needs to support.
Example
Build a weekly table of competitor launches and feature changes that product marketing can review and update.
|
| Row Objective |
Define what each row represents. This is the most important dataset-specific instruction because it tells Cortex how to break the work into rows.
Example
Each row is one competitor feature launch or update worth tracking this week.
|
| Columns |
Define the stable fields each row should contain. Good column objectives make the dataset easier to review, diff, and reuse later.
Example
company, feature, status, source_url
|
| Max Agent Iterations |
This is a limit on how many steps the agent can take, not a row-count target. Too low can cut the work short; too high can waste effort on a vague task.
Example
200
|
| Feed Scope |
Keep the scope narrow enough that the dataset still represents one coherent table instead of several unrelated tables mixed together.
Example
Competitor Watch, Product Releases
|
| Time Window (days) |
Choose a window that matches the cadence and volume of the table you want. Wider windows can be useful, but they usually demand a tighter row objective.
Example
7
|
For the full config schema, see Create Digest in the API docs.
Examples
These examples show common dataset setups.
Action Queue Dataset
Use this when the reader needs a working queue of recommended actions rather than a prose summary.
- action
- priority
- owner
- source_url
- Model Labs
- Research Papers
Competitor Feature Matrix
Use this when the output should become a durable comparison table that can be reviewed over time.
- company
- feature
- status
- source_url
- Competitor Watch
Research Findings Table
Use this when the consumer needs rows that can be sorted, filtered, and reused in later analysis.
- paper
- finding
- impact
- source_url
- Research Papers
Troubleshooting & FAQ
The dataset rows feel inconsistent or fuzzy.
The row objective is probably too vague.
Rewrite it so it clearly defines what one row is supposed to represent before you change the iteration cap or add more feeds.
The dataset stops too early or misses obvious rows.
The max agent iterations budget may be too low for the breadth of the task.
Raise it only after tightening the row objective and feed scope so the agent spends that budget on one coherent job.
The dataset takes too long or feels overworked.
A high iteration cap cannot rescue a vague dataset task.
If the work is poorly defined, reduce the scope first and treat iterations as a budget, not as a quality setting by itself.
When should I use briefing instead?
Use briefing when the output should explain developments in sections and prose.
Use dataset when each result should become a row in a table that someone will review, filter, export, or reuse programmatically.