AhaInsights.

Agentic Analytics

Foundations: Layers behind an agent your stakeholders can trust.

The Context Playground.

See the layers working on real data: the question travels the stack, and you watch the context do its job.

https://context-playground-33766633183.asia-south1.run.app/

Password: humans_at_play

The IPL AI Playground.

Play with the data directly. Ask it things, break it, see where the gotchas show up.

https://ipl-ai-playground.streamlit.app/

Password: humans at work

It's a scaling of the business analyst that's available 24/7 to all stakeholders.

Technically: It is an LLM with access to a set of data models and documentation Layers. Evaluated on every change.

Today - We learn what each layer achieves.

Each layer handles 1 stage of decision making for the agent.

• System prompthow do I behave?
• Context layerhow do I answer this?
• Semantic modelwhat does this metric mean?
• Data modelwhere is the data?

When the answer is wrong, the layer tells you where the fix belongs.

Wide, pre-calculated tables.

A data model is a table that already holds the answer. We build it wide: dimensions and metrics in one table, already joined.

Each table covers one use case, and only that one.

The agent can't pick the right join.

It writes join syntax fine. It can't reliably decide the right join when relationships and grain aren't documented. A wrong key or an unnoticed one-to-many fan-out silently doubles your numbers.

Wide, pre-joined tables remove the decision. The join was made once, correctly, by someone who knew the grain.

Bonus: shorter queries, lower token use, and answers that come back closer to deterministic than you'd get otherwise. Not truly deterministic. Just far less room to drift.

Many single-purpose models.

One model per use case, shallow enough that the agent can reason about it without getting lost. The redundancy is deliberate, not sloppy. It has two costs, both managed:

• Selection ambiguitythe agent must pick the right table from several similar ones.Handled by routing rules in the context layer.
• Consistency drifta metric defined twice can fall out of sync.Handled by deriving shared metrics once, and by evals that catch the disagreement.

Where the agent learns the language of the business.

A plain-text definition on top of each table. More than column names:

• The other names people use for the same metric."strike rate" and "scoring rate" reach the same column.
• How to read a nuance in the question and turn it into the query.
• The common gotchas for that table, written where the agent will see them.

You don't hand-write these. Draft them from the queries plus business context, then correct what's wrong.

How the agent decides what to do.

Data model = where the data lives. Semantic model = what it means. Context layer = how to act.

For any question: what exactly is being asked, which model answers it, what to clarify first, how to proceed when the answer takes several steps.

It has to be extensive. Which table for which use case, how to join the few that need it, what to answer, what to refuse. This is where most of the real work lives.

Thin. Stable.

What the agent is, how to behave, which files to read for the real logic.

It holds no domain logic. No metric definitions, no table names, no business rules. The line: how the agent behaves belongs here; how the business is measured does not.

The payoff: change how the business is measured without ever touching the prompt.

The output isn't just a table.

Its shape is deliberate: each part exists so a person can trust the answer and act on it.

• Reasoningwhich table, which filters, how it read the question. Auditability. Catch a wrong answer before anyone acts on it.
• Clarificationambiguous question? It asks instead of guessing. Refusing to guess is a feature.
• Datathe result itself.
• Summary + next stepswhat it says, and the obvious follow-up. The analyst move.

How you know it's actually working.

A fixed set of questions with answers you've already verified. Re-run the whole set every time you change the context.

• Catches regressionsthe fix for one question didn't quietly break five others.
• Gives you a number"82% correct, up from 71%." The only honest basis for "it got better."

Without evals, every change is a guess. This is where "analytics your stakeholders can trust" stops being a slogan.

Every gotcha is a line item in the context layer.

Not failure modes to memorize. Things you write down so the agent stops getting them wrong.

• Entity resolution contextIdentify the player, team, metric, and conditions before anything downstream.
• Metric definition semanticHow is it calculated, and what to watch out for.
• Common errors contextWrite the repeated mistakes down next to the right way.
• Output quality contextWhich columns, what sort order, sensible default shape.
• Syntax errors contextName the query patterns to avoid.
• Overreach contextAnswering without looking. "Best batsman = most MOTMs" is a definition nobody agreed to.

Now we build.

Two tools. Access shared in the session.

The way in is the same each time.

1. Understand the data. Look at the rows, read the doc. Simpler than it sounds.
2. Get a question set. AI can generate these for you.
3. Ask, and watch the gotchas appear. They will. Every one is a line you now know how to add.