Home / Articles

Causal Inference in Production: Five Stages and Where AI Agents Help

How Pearl's structural causal models can be deployed in regulated industries: five stages, what agents speed up, where they fail and why experts stay in the loop.

Publisher: REACTAPP.TOP8 min read1869 words

This article is published in English.

Sources: How Agentic AI Finally Makes Causal Inference Deployable

Causal inference has long been rigorous and rarely deployed. The argument here is specific: agentic AI makes it tractable at enterprise scale for the first time. That's a technical claim, so it gets technical treatment, which means going through the five stages of putting a causal model into production, seeing why each was a bottleneck before capable AI agents, and spelling out what changes when agents join the pipeline. Their failure modes get equal attention, because the weaknesses of this architecture matter as much as its strengths.

It isn't a tutorial and there's no step-by-step recipe. The value lies in the reasoning, and in understanding why the setup differs and not merely that it does.

What causal inference needs

Before looking at what agents alter, it helps to pin down what the method demands. The framework used is Judea Pearl's Structural Causal Model (SCM), the leading formal approach to causal reasoning in statistics and machine learning. An SCM describes a system through variables and one structural equation per variable, each saying how that variable's causes determine it. The structure is drawn as a Directed Acyclic Graph (DAG), with nodes for variables and directed edges for direct causal links. It's acyclic because no variable is assumed to cause itself within the relevant time window.

The core operation is the do-operator, written do(X = x). It represents an intervention in which variable X is forced to value x, severing it from its normal causes. Pearl's do-calculus, a complete set of inference rules, then computes the effect of such interventions from observational data once the graph is known. That gives the framework its power: "what if we change X?" gets answered without running any experiment.

Production deployment takes five stages, and each has historically been a serious bottleneck.

Stage 1: choosing the variables

Deciding what goes into the model sounds easy and isn't. In a financial system the pool of possibly relevant variables is huge: macroeconomic indicators, company financials, regulatory metrics, ESG scores, market microstructure measures, sentiment signals and more. Too many variables add spurious paths and leave the graph unidentifiable. Too few omit important confounders and bias the effect estimates.

The traditional answer is an expert workshop, with actuaries, risk officers and portfolio managers debating which variables matter and why. It's valuable, but it's slow, costly and dependent on who attends. A variable obvious to one expert may never occur to another.

What agents alter is how wide the first pass can be. One can digest a large body of domain material, such as academic papers, regulatory guidance and industry reports, and propose candidate variables with citations. It can pick out variables the literature keeps naming as drivers of an outcome, mark those usually handled as confounders and bring in knowledge nobody in the room had. The expert goes from compiling a list to reviewing and trimming a researched proposal, which is quicker and depends less on any single person's knowledge.

One limit is essential. Agents can propose but not validate, so domain experts who understand the business must sign off on the final set. Reading the whole ESG-and-performance literature tells a model nothing about which variables sit in your data infrastructure, or which your compliance team would accept in a regulatory filing.

Stage 2: specifying the causal structure

Then the causal structure must be specified: which variables cause which, and in what direction. It's the hardest stage and historically the costliest. There are two broad method families. Constraint-based algorithms, such as the PC algorithm by Spirtes, Glymour and Scheines, infer structure from conditional independence tests on data. Score-based methods search candidate graphs for the best fit under a goodness-of-fit criterion. Each has well-known limits. Constraint-based approaches are sensitive to the faithfulness assumption and sample size, whereas score-based search is a combinatorial problem that becomes intractable as variables multiply. Neither produces one unique graph from observational data. The best attainable result is a Markov equivalence class, meaning graphs that statistics can't tell apart.

So automated discovery can narrow down plausible graphs but can't settle the final structure without domain input. Edge direction, often the most important property, frequently can't be recovered from data alone and has to come from an expert.

What agents change is iteration speed. One can run several discovery algorithms, compare their outputs, mark the edges where methods disagree and hand the expert a structured list of choices: edges all methods agree on, edges that are contested, and edges the data supports but that conflict with particular domain knowledge. The expert no longer runs algorithms and reads raw output, and instead makes well-framed calls. The count of decisions is unchanged, and each one costs less.

The failure mode to watch is an agent that offers a single "best" graph and hides the uncertainty. Data doesn't determine causal graphs uniquely, so any system that presents a structure as fact and not as a hypothesis misstates the epistemics of the problem.

Stage 3: validating the graph

A causal graph is a collection of assumptions. Each edge claims that one variable directly causes another. Each missing edge claims that two variables aren't directly connected once everything else in the graph is accounted for. Those claims can be wrong, and the cost of error can be high.

Validation typically combines domain review, asking whether the graph makes sense to experts, with statistical testing of whether the conditional independencies implied by the graph hold in the data. The second relies on d-separation: a graph implies that certain variable pairs are conditionally independent given certain others, and those implications are testable.

Sensitivity analysis asks a related question: how far do effect estimates move if the graph changes by adding an edge, flipping a direction or introducing an unmeasured confounder? That matters because a graph always approximates reality, and you need to know which conclusions survive the approximation and which are fragile.

In the past this stage needed a specialist statistician to run the tests, read the results and turn them into graph edits, a slow, iterative loop. Agents automate the test battery. One can run every implied conditional independence test, flag the violations, work out which edges each violation implicates and produce a structured report. It can also run sensitivity analyses by varying edge weights, adding hypothetical confounders and checking how stable the estimates are, then summarize the findings. The statistician moves from running tests to interpreting a structured diagnostic report.

Stage 4: interventional queries

This is where the causal model pays off. An interventional query asks for the expected value of outcome Y when variable X is set to value x, which Pearl's notation writes as:

This differs from the conditional expectation a standard regression estimates:

Computing interventional queries means applying the do-calculus, three rules that rewrite expressions containing the do-operator into ones computable from the observational distribution, given the graph. For simple graphs it's direct. With many variables, several intervention targets and time-series structure, it can demand heavy algebra.

Consider a business question like "what happens to our loss ratio if we change our pricing structure?" Before agents, someone had to convert it to a formal interventional query and compute that from the model, and only a specialist who knew both the business and the mathematics could do it. This conversion cost is the main reason causal inference stayed inside universities.

Agents change the translation layer. One can take a plain-language business question, find the variables involved, write the matching do-expression, apply the do-calculus to reach something estimable and return a result with a plain explanation. The domain expert needn't know the do-calculus and only has to judge whether their question was translated correctly, a much lower bar.

The failure mode: an agent that answers the wrong question with confidence. Business wording often fits either a conditional or an interventional reading. "What happens to our loss ratio when ESG scores are high?" can mean what shows up in cases where scores happen to be high (conditional), or what follows if scores are forced high (interventional). Those give different answers, so an agent that doesn't surface the ambiguity and have the user choose is a liability.

Stage 5: the audit trail

In regulated industries the output of an analysis is more than the answer. It's the answer together with the full chain of reasoning behind it, and every modeling assumption, data transformation and analytical choice must be documented and defensible.

Causal models raise the bar. A complete record covers six things: why each variable was chosen, how the graph is laid out and what supports every edge, which validation tests ran and how they came out, exactly which interventional queries were executed, and which business decisions each query fed. Writing this up manually tends to leave gaps and inconsistencies, and it usually happens afterward.

With agents, the trail can be automatic and written as events happen. Each action, whether a literature search, an algorithm run, a graph change or a query, is logged with a timestamp, inputs, outputs and reasoning. Documentation becomes a byproduct of the process and not a separate chore. For a regulatory submission or an internal audit, that isn't a minor convenience. It separates an analysis that can be defended from one that can't be reconstructed.

What agents can't do

The limits deserve to be stated plainly.

  • They can't derive causal structure from data alone. Edge direction is often underdetermined by observational data, and more compute doesn't change that. Domain expertise carries real weight in this design.
  • They can't check their own translations. An agent may convert a business question into a formal query incorrectly, and do it with confidence. The human review in Stage 4 is the main defense against a class of errors that don't show in the output yet affect the decision.
  • They don't replace experimental data. The do-calculus yields interventional effects from observational data only under assumptions, chiefly a correctly specified graph and no unmeasured confounders. When those fail, estimates can be far off. Agents can't tell when the assumptions are violated. Only domain knowledge and, in the end, experimental evidence can.

Why it still matters

The argument for this architecture isn't that causal inference becomes easy. It doesn't. The argument is that it becomes viable, because the cost barriers that kept a rigorous, well-established methodology out of production for thirty years come down.

The methodology isn't new, and the infrastructure is. Organizations that pair the two, with agents handling the process layer and domain experts holding the judgment layer, are building something correlation-based AI can't match: a rigorous, auditable, interventionally valid model of the systems they run. In regulated industries that's worth building, and the opening to build it first is available now.