AI trend-report agent

Prototype, sample data

This is a Scaylar prototype built to show how an AI trend-report agent works, with sample data on screen. It splits a trend report on a product category into steps that can each be checked: scope the questions, gather signals, compute the figures in code, draft the report, and compare every figure in the draft with the data. The findings, figures and sources are made up, and the prototype calls no AI service: each run is replayed on timers in your browser.

Open the prototype
Book a call
The report screen of the trend-report prototype, labeled Sample data: a draft for analyst review on plant-based snacks in the United States, with a headline on which parts of the category are growing and shrinking, tiles for signals gathered, source types, trends found and figures checked, and a note that the report is made up to show the format.
The prototype, with sample data. Everything on the screen is made up to show how the system works.

( USE CASE )

Who it is for and the problem

Market research and consumer-intelligence teams that publish trend reports on product categories: which parts of a category are growing, how fast, and why.

Today an analyst spends days on each report. They pull news coverage, search interest, retail listings and social mentions from separate tools, line the numbers up in a spreadsheet, write the story, then check every figure by hand before it goes out. Much of that time goes to gathering and checking rather than to judgment.

The agent takes on the gathering, the arithmetic and the first draft, and keeps a record of where every number came from. The analyst reviews a draft instead of starting from a blank page.

( STEP BY STEP )

How it works

The steps describe how a production build would work. The prototype plays them back with sample data and timers.

  1. Step 01

    Scope the questions

    An analyst picks a category, a market and a time window. The agent turns that brief into a fixed set of questions: which parts of the category are growing, whether growth is speeding up, which products are taking share and what is driving it. It also lists the sub-segments it will track, so the scope is written down before any data is pulled.

    The New report screen, labeled Sample data: a choice of three categories with plant-based snacks selected, a market menu set to the United States, the time window, signals and output of the run, a Start research button, and a panel listing the four questions the agent answers.

  2. Step 02

    Gather signals

    The agent collects news coverage, search interest, retail listings and social mentions for each sub-segment. Every step and every source goes into a run log with its time, so anyone can see what was read and when. In the prototype the run is replayed from sample data on a timer, and nothing is fetched.

    A research run halfway through, labeled Sample data: a progress bar at step 3 of 6, the steps Scope the questions and Gather signals marked done, Analyze running, and a dark run log listing what the agent read from each kind of source, with the time since the start.

  3. Step 03

    Analyze growth and momentum in code

    In a production build, growth, momentum and share are computed in code from the collected series, not estimated by the model. Year-over-year change, the last two quarters against the two before, and share of new listings come out as numbers with their source attached, and a trend makes the report only when two or more sources back it. In the prototype these figures are sample values, written to show the format.

    The Trends section of the sample report: two trend cards marked Rising, each with a chart of search interest by quarter, three figures tagged with their source and a list of evidence. The pointer rests on the first chart and a tooltip shows the value for one quarter.

  4. Step 04

    Draft the report

    In a production build, the model writes the headline, one card per trend with its chart and evidence, the drivers, the risks and what to watch. It may only use figures from the computed series, and each figure keeps a tag that points to its source. The draft is marked for analyst review, not published.

    Further down the sample report: three cards listing the drivers, the risks and what to watch in the category, written as short bullet points, above the number check and the list of made-up sources.

  5. Step 05

    Check every figure against the data

    Before anyone reads the draft, a production build compares every figure in the text with the data it came from. A figure that does not match is corrected and flagged, so the reviewer sees what changed and why. In the sample run one figure did not match, and the screen shows it crossed out next to the corrected value.

    The number check of the sample report: a green banner saying every figure matches the data, a sentence naming the one figure that was corrected before publishing, a table of figures with the value in the report, the value in the data and the result, one row marked Corrected and the rest Match, and the list of made-up sources.

  6. Step 06

    Publish, after an analyst signs off

    When the checks pass, the run ends with the report ready to open, its sources and the full number check attached. An analyst reads it, edits what needs judgment and publishes it. Every report keeps its run log, so a question about any number can be answered later.

    The finished run, labeled Sample data: all six steps done with the time each took, a green banner saying the run is complete and the figures match the data, an Open the report button, a Replay the run button, and the run log.

( WHAT WE AIM FOR )

Targets for a production build

What a production build would be designed and measured against. They are targets, not results: the prototype runs on sample data.

  • Target: a draft ready for review in under an hour.
  • Target: a few dollars in model costs per report, logged with each run.
  • Target: every figure in the report traced to a source or a computed series.

( THE BUILD )

What we would build it with

A large language model (LLM)

For scoping the questions and writing the draft. The model writes the words; the numbers come from code.

Your own data sources

The news, search, retail and social data your team already licenses, read through their APIs or exports, with your past reports as examples of the house style.

Analysis in code

Scheduled Python jobs that compute growth, momentum and share from the collected series, so every figure can be recomputed and checked.

A review step

Every report lands as a draft for an analyst, with the number check and the sources beside it. Nothing is published until a person signs off.

Logs and cost tracking

Each run keeps its log, its sources and its model cost, so you can see what a report cost and trace any figure back to where it came from.

( OUR WORK )

Built on work we have shipped

  • An executive dashboard that replaced a paid BI tool for a performance marketing agency.
  • About thirty scheduled checks across that agency’s ad accounts, replacing a daily manual sweep.

See our work →

Open the prototype

It runs in your browser on sample data: nothing you click or type is sent anywhere. If you have a process like this one, book a call and we will tell you plainly whether an agent is the right tool for it.

Open the prototype
Book a call

More case studies: AI learning guide · AI interview agent

The sample report on a phone: the Scaylar prototype and Sample data labels, the New report, Run and Report steps, and the start of the report with its headline.