The main tasks in building advanced analytics
Turning an idea into a working model involves a set of tasks. In traditional analytics, people do these step by step; in agentic analytics, AI agents can do many of them (or assist) so the same work happens faster or with less manual effort.
1. Defining the problem and success
What it is: Being clear about what you're predicting or deciding, for whom, and how you'll measure success (e.g. accuracy, profit, fairness).
Why it matters: A model built for the wrong question or the wrong metric will disappoint in the real world.
2. Getting and preparing data
What it is: Pulling the right data from the right sources, cleaning it (missing values, duplicates, errors), and aligning it so it's ready for modelling. Often the slowest and messiest part of the process.
Why it matters: Models are only as good as the data they're trained and run on.
Concrete steps:
| Step | What to do | Examples |
|---|---|---|
| Missing values | Decide per column: drop rows, impute (mean/median/mode), or use "missing" as a category. | Drop if >50% missing and not informative; impute numeric with median; for categorical, add a "missing" level if absence is meaningful (e.g. "no previous claim"). |
| Duplicates | Identify and remove or collapse. | Same customer twice (keep one); same transaction duplicated (drop); same entity across sources (dedupe with a key). |
| Outliers | Decide whether they are errors or real. | Cap or winsorise if measurement error; keep and use robust methods if real (e.g. fraud, one-off deals). |
| Types and formats | Align types (numeric, date, categorical) and units. | Dates in one timezone; amounts in one currency; IDs as string so leading zeros aren't lost. |
| Joining sources | Match keys and check coverage. | Join customer to transactions on customer_id; flag rows with no match; document how you handled many-to-many. |
| Train vs production | Ensure the same cleaning can be applied to new data. | Document and automate (scripts, pipelines) so production data is treated the same way as training data. |
3. Feature engineering
What it is: Creating the inputs the algorithm will use. Raw data (e.g. "date of first purchase") is turned into features (e.g. "days since first purchase," "month of year," "is weekend?") that are more useful for the model.
Why it matters: Good features often matter more than choosing the fanciest algorithm. This step is where domain knowledge (how the business works) meets the data.
Concrete patterns:
| Raw data | Feature ideas | Why they help |
|---|---|---|
| Date | Days since event, month, quarter, is_weekend, is_month_end | Captures recency, seasonality, and calendar effects. |
| Amounts | Raw value, log(value), buckets (e.g. low/med/high), ratio to another amount | Reduces skew; gives the model structure; ratios are comparable across segments. |
| Categories | One-hot encoding, "top N + other", target encoding (mean outcome by category) | Turns categories into numbers; target encoding injects signal when the category is predictive. |
| Counts | Raw count, count per time window, rate (e.g. per month) | Normalises for exposure so different time windows are comparable. |
| Text | Length, word count, sentiment score, topic or category from a simple rule or model | Summarises text so it can be used alongside other features. |
| Interactions | Product or ratio of two features, segment × metric | Surfaces "for segment A, X matters; for segment B, Y matters." |
Domain experts (e.g. operations, risk, marketing) are often the best source of feature ideas — they know which levers and conditions actually matter. Running a short feature workshop with stakeholders (see Change management) is a practical way to generate and prioritise features.
4. Model training (and selection)
What it is: Using historical data to train the algorithm — i.e. to set its internal parameters so it fits the patterns in that data. Often you try several algorithms or configurations and pick the one that performs best on held-out data.
Why it matters: Training is where the algorithm "learns." The choice of algorithm and how you train it (e.g. how much data, what you optimise for) drives performance and behaviour.
Bias and variance (in plain language). When you train a model, you care about two kinds of error:
- Bias is error from the model being too simple — it misses real patterns in the data (e.g. a straight line when the relationship is curved). The model underfits: it's not using the data well. You see this when performance is poor on both the training set and on new data.
- Variance is error from the model being too reactive to the training data — it memorises noise and quirks. The model overfits: it looks great on training data but does worse on new data.
There is a tradeoff: simpler models tend to have higher bias and lower variance; more complex models tend to have lower bias and higher variance. The goal is to find the sweet spot (e.g. via validation, regularisation, or cross-validation) where the model captures real structure without fitting noise. If your model does well on training data but poorly on held-out or production data, you're likely overfitting — try a simpler model, more data, or stronger regularisation.
5. Validation and testing
What it is: Checking that the model works as intended: accuracy on unseen data, fairness across groups, robustness to bad inputs, and behaviour at the edges (e.g. extreme values, rare events).
Why it matters: A model that looks great on the data it was trained on can fail or behave badly in production if it wasn't properly validated.
6. Deployment and monitoring
What it is: Putting the model into the systems people use (dashboards, apps, workflows) and then monitoring its performance and inputs over time so you can detect drift or degradation.
Why it matters: A model that isn't used doesn't create value; one that isn't monitored can silently become wrong or unfair.
7. Iteration and maintenance
What it is: Retraining, adjusting, or replacing the model when the business, data, or performance requirements change.
Why it matters: The world changes; models that aren't updated eventually become obsolete.
In traditional analytics, analysts and data scientists do most of these tasks by hand (writing code, running experiments, deploying pipelines). In agentic analytics, many of these steps can be partially or fully carried out by AI agents, with humans setting direction and checking results.