Analytics as a feed: the agentic shift and the new analyst

Sushrut Ikhar, Co-founder, Matih Labs — 2026-08-12

Analytics as a feed: the agentic shift and the new analyst

TL;DR — Every previous generation of analytics was pull: you had to know what to ask, then go ask it — in SQL, in a dashboard filter, or lately in a chat box. Agentic analytics inverts that: standing analyses run on a schedule — or whenever the source data updates — and push a feed of findings with recommended actions attached: what changed, why it matters, what to do about it. That inversion only works if every card in the feed is grounded and auditable — otherwise you've built a noise machine. And it quietly rewrites the data analyst's job: when agents handle the mechanical query layer, "analyst" stops meaning "person who writes SQL" and starts meaning problem-framer, model-builder, and editor-in-chief of what the business believes.

Why does pull-based analytics miss what matters?

Think about how every analytics interaction you've ever had actually started: someone had to think of the question first.

Dashboards are pre-asked questions, frozen into charts. SQL is a question you compose by hand. Even AI chat over your warehouse — the thing that felt like the frontier eighteen months ago — is still pull: nothing happens until a human wonders something.

The problem is that the most expensive failures in a business are the questions nobody thought to ask. Activation quietly drops 9% after a release. Two suppliers start causing most of your late deliveries. Six accounts show the usage pattern that precedes churn. None of these announce themselves in a dashboard someone built last quarter — they sit in the data, waiting for a query that may never come.

What is an insight feed?

Here's the bet we've made in Matih — and the reason this post exists: the interface that replaces the dashboard isn't a better dashboard. It's a feed — a stream of cards, each one an insight the system produced on its own, with a recommendation attached. It's why routines work the way they do. The doc is literal about the feed being the floor: even "with no destinations, runs still land in your feed" — Slack, Teams, and email are routing on top, not the substitute. And a routine can fire on data, not just time: the scheduler carries an "Also run when source data updates" option, because a feed that only follows the clock misses the moment that mattered.

A good feed card has three parts:

1. The finding — what the data says, stated plainly. "Stage 3 → 4 conversion fell from 46% to 31% after the pricing change."
2. The recommendation — the action the finding supports. "Refresh the pricing narrative and battlecards for stage-3 reps."
3. The receipts — which systems the finding came from, and the queries behind it, one click away.

That third part is not optional garnish — it's the difference between an insight feed and a rumor mill. An unsourced "your churn risk is up" card trains people to ignore the feed within a week. A card that traces back to live systems and shows exactly how the answer was grounded trains people to act on it.

The push layer has to earn its place, though — anyone can threshold a metric and spam a channel. One detail we're opinionated about: a new routine starts as a draft. You test-run it, read exactly what it will produce, and only then put it live on a schedule. The editorial bar is a product mechanic, not a hope — because the point is fewer, better cards: what changed, why it matters, what to do next.

A worked example: an AI shopping assistant, as a feed

This isn't hypothetical for us. Zave — an AI shopping assistant that pops up over the shopping apps you already use — runs its production analytics on Matih. Every query its agent handles lands as analyzable data, no pipeline built. Bhavesh Palekar, from Zave's founder's office, describes the pull side of that: "When we wanted conversion by category, I just asked; it used to mean a week of engineering time."

The feed is the standing version of that exact question. Take the prompt Bhavesh asked once and schedule it: "Summarize yesterday's shopping queries and conversion by category, and call out anything unusual." Daily at 7am, delivered in-app and to the team's Slack; leave "Also run when source data updates" on so a late event backfill re-runs it before anyone reads stale numbers. A good run produces a card like this (figures illustrative):

Shopping queries, Aug 11 — Volume up 9% overall. Electronics recommendation-acceptance fell from 41% to 28% after yesterday's catalog sync. Recommended: check the price-comparison feed for the two retailers that changed SKU formats, before tonight's sync. Verified against live query and catalog data — queries attached.

Notice what the card is not: a dashboard link plus "something looks off." The finding names the driver, the recommendation is a task someone can own by tonight, and the receipts are one click away.

The draft flow is where the editorial bar gets enforced. A vaguer prompt — "tell me anything interesting in our queries" — test-runs into a mushy paragraph nobody would act on. Tightening it to name the breakdown (by category) and the bar (anything unusual) is analyst work, and the test run is where that editing happens: nothing goes live until a human has read a real run and decided it clears the bar.

Why "recommendation" is the load-bearing word

A feed of findings without recommendations is just a smarter status page. The reason recommendations matter is that they force the system to complete the reasoning a human would otherwise have to do at 9pm: given this finding, in this business, what's the move?

That completion step is exactly what separates agentic analytics from retrieval. As we argued in what agentic BI actually means, the difference between a chatbot and an agent is the input: a question gets you an answer, a goal gets you a plan. A feed is what you get when the goal is standing — "watch the business and tell me where to act" — and the agent runs it continuously instead of once.

It also changes who can consume analytics. A revenue leader doesn't want a p-value; they want "pull solutions engineering into these three security reviews this week." The recommendation is the translation layer between data work and operating work.

How does this change the data analyst role?

Here's the part that gets discussed least and matters most.

For twenty years, the data analyst's implicit job description was human middleware: translate business questions into SQL, translate result sets back into English, repeat until retirement. Skilled analysts always did more — but the queue of translation requests ate the calendar. Ask any analyst what fraction of their week goes to "can you pull this number for me," and brace yourself.

Agentic analytics eats exactly that layer. When a grounded agent writes and verifies the queries — against a semantic layer that pins down what "active user" and "revenue" actually mean — the translation queue collapses. Business teams self-serve the questions that used to be tickets.

That does not make analysts obsolete. It makes them senior. The work that remains is the work that was always the actual job:

• Problem framing — deciding which questions are worth standing up as routines, and what "worth a human's attention" means for this business.
• Metric and definition design — the semantic layer doesn't govern itself. Someone has to decide what churn is before an agent can watch it.
• Editorial judgment — reviewing what agents surface, killing the plausible-but-wrong, promoting the genuinely load-bearing. The feed needs an editor-in-chief.

And the demand curve runs the other way from the layoff headlines: every new self-serve consumer of the feed raises the cost of a bad definition — which is exactly the analyst's territory.

Do analysts become data scientists?

The most interesting consequence: the wall between "analyst" and "data scientist" starts to look like an artifact of the tooling era that built it.

When the mechanical query layer automates, the natural next step up the stack for an analyst is modeling — and agentic tooling is dissolving the barriers there too:

• Root-cause analysis is collapsing from a week of manual cohort slicing into a describe-and-judge loop: state the outcome that moved, review the candidate drivers the tooling proposes, and apply the causal judgment no agent has. Writing the GROUP BYs was never the skill; deciding which decomposition makes causal sense is.
• Forecasting and propensity questions — will we hit the quarter, which accounts are likely to churn, which trials will convert — are heading the same direction: framed and critiqued by the analyst closest to the business, rather than queued as next sprint's DS project. The scarce skill becomes knowing when a model is lying, not fitting it.
• Feature thinking becomes definition work. The features that make churn models good — usage trajectories, ticket sentiment, engagement depth — are the same governed definitions the semantic layer holds for everyone. Curating them well improves both the executive's feed card and the model behind it. One investment, two payoffs.

None of this demotes SQL — the receipts on every card are SQL, and reading them critically is how an analyst audits the machine. What changes is the ceiling: with the mechanical floor of the job automated, modeling, causal reasoning, and editorial judgment stop being the work you never got to and start being the job.

What should you look for in an insight feed?

If you're evaluating tools that promise proactive insights, four questions separate the real thing from a notification generator:

1. Is every card grounded? Can you get from the claim to the queries and rows behind it in one click? If not, the feed will die of distrust.
2. Does it recommend, or just report? "Churn risk up 12%" is a fact. "Run save plays on these six accounts" is a decision. Only one of them changes your Monday.
3. Can you tune the editorial bar? A feed you can't quiet becomes noise; a feed you can't sharpen misses the one card that mattered.
4. Does it respect autonomy boundaries? Watching and recommending is one thing; acting is another. The autonomy dial should be yours to set.

That's the wager behind Matih's feed: routines that must pass a test run before they go live, cards that carry their receipts, and an autonomy dial that stays yours. A feed gets judged card by card — was this worth being told, and would I have caught it by asking? — which is a higher bar than any dashboard ever faced, and the right one. The teams that clear it will be the ones whose analysts stopped being the query layer and started being the editors, modelers, and skeptics the feed actually needs.

FAQ

Is an insight feed just alerting with better branding? No. Alerting fires when a metric crosses a threshold someone hard-coded. A feed card is the output of a standing analysis: it detects the change, diagnoses the driver, and attaches a recommended action — with the queries behind all three inspectable. Thresholds tell you that; a feed tells you why and what now.

Does agentic analytics replace data analysts? It replaces a layer of the job — the human-middleware work of translating questions into SQL and results back into English. The rest of the role gets bigger: framing the standing questions, governing definitions, validating model output, and editing what the business sees. The more people self-serve from the feed, the more expensive a bad definition becomes — and definitions, framing, and validation are analyst work.

Do analysts still need SQL? Yes — but as a verification skill, not a production bottleneck. When an agent shows its work, someone has to be able to read that work critically. SQL literacy is how you audit the machine; it just stops being the job's entire surface area.

Where does data science fit in a feed-first world? Closer to the analyst than before. Root-cause decomposition, forecasting, and propensity scoring are increasingly analyses that analysts frame and critique rather than multi-sprint DS projects — while the governed definitions that power the feed double as the feature layer models consume. The DS team's scarce time moves to the problems that genuinely need novel modeling.