Walk into the actuarial department of any major insurance firm, and you will find some of the most highly educated, analytically brilliant minds in the corporate world. These are professionals trained in advanced mathematics, probability theory, and complex risk modeling.

Now, ask them how they spend the majority of their working hours.

The answer is rarely “building sophisticated risk models” or “developing innovative pricing strategies.” More often than not, the answer is “wrestling with spreadsheets,” “reconciling data from legacy systems,” or “formatting regulatory reports.”

This is the Actuarial Time Trap. It is a systemic misallocation of human capital, where highly paid experts are relegated to performing routine data manipulation tasks. It is inefficient, it is demoralizing, and in an era of rapidly evolving regulatory requirements, it is increasingly unsustainable.

The Burden of Regulatory Reporting

The insurance industry is governed by some of the most complex regulatory frameworks in the world. Regimes like Solvency II in Europe and IFRS 17 globally require insurers to produce massive, highly detailed reports on a regular basis.

These reports are not simple data dumps. They require aggregating data from dozens of disparate systems, applying complex actuarial models, and presenting the results in strictly defined formats.

Historically, this process has been heavily manual. Actuaries spend weeks pulling data, running macros, checking for errors, and formatting the final output. By the time the report is submitted, the data is often stale, and the actuaries are exhausted.

This manual approach is not just slow; it is prone to error. When humans are forced to perform repetitive data manipulation tasks, mistakes are inevitable. And in the context of regulatory reporting, mistakes can result in significant fines and reputational damage.

The Promise (and Failure) of Traditional Automation

The industry has recognized this problem for years, and has attempted to solve it with traditional automation tools. Robotic Process Automation (RPA) bots have been deployed to scrape data from legacy systems. Complex ETL (Extract, Transform, Load) pipelines have been built to consolidate data warehouses.

These efforts have yielded incremental improvements, but they have failed to fundamentally break the Actuarial Time Trap.

The problem with traditional automation is that it is rigid. An RPA bot can follow a strict set of rules, but it cannot adapt to unexpected changes in data formats or system interfaces. An ETL pipeline can move data from point A to point B, but it cannot understand the semantic meaning of that data or apply complex business logic.

Traditional automation is brittle. When the environment changes—as it inevitably does in a complex enterprise—the automation breaks, and the actuaries are forced to step back in and fix the mess.

The Agentic AI Solution

This is where agentic AI represents a paradigm shift.

Unlike traditional automation, agentic AI systems are not bound by rigid rules. They are capable of reasoning, adapting, and executing complex, multi-step workflows autonomously.

An agentic AI reporting system can be instructed to “generate the Q3 Solvency II report.” The system can then autonomously identify the required data sources, retrieve the data, apply the necessary actuarial models, format the output according to regulatory standards, and flag any anomalies for human review.

Crucially, agentic AI systems can handle the ambiguity and variability that break traditional automation. If a data field is missing or formatted incorrectly, the agent can use its reasoning capabilities to infer the correct value or query an upstream system for clarification.

However, deploying these systems in actuarial work is not without risk. As the IFoA GenAI Working Party highlights, the complexity and autonomy of a network of AI agents add a new dimension to risks, making them harder to manage and requiring dynamic governance frameworks.

The Importance of Auditability

In the actuarial domain, automation without auditability is useless. Regulators do not accept “the AI generated it” as a valid explanation for a reporting anomaly.

This is why the deployment of agentic AI in insurance must be underpinned by causal reasoning and rigorous governance. Every action taken by the agent—every data retrieval, every transformation, every calculation—must be logged and explainable.

The system must be able to produce a transparent audit trail that traces the final output back to its source data, demonstrating exactly how the result was derived. This level of transparency is not just a regulatory requirement; it is essential for building trust among the actuaries who will ultimately rely on the system.

The Human-AI Collaboration Model

The most effective deployments of agentic AI in the actuarial domain are not fully autonomous. They are collaborative. The agent handles the mechanical work—data retrieval, transformation, and initial formatting—while the actuary retains oversight and final sign-off authority.

This human-AI collaboration model is not a compromise; it is the optimal design. It leverages the speed and consistency of AI for the tasks where it excels, while preserving the contextual judgment and professional accountability of the human expert for the tasks that require it.

Designing this collaboration effectively requires careful attention to the interface between the human and the machine. The agent must surface its outputs in a way that is transparent and auditable, making it easy for the actuary to verify the work and understand the reasoning behind any flagged anomalies. If the agent cannot explain its output, the actuary cannot responsibly sign off on it.

Reclaiming Human Capital

The goal of deploying agentic AI in the actuarial department is not to replace actuaries. It is to liberate them.

By automating the routine, repetitive tasks of data manipulation and report formatting, agentic AI frees up actuaries to focus on the high-value work they were trained to do. They can spend their time analyzing the data, identifying emerging risks, and developing strategic insights that drive the business forward.

This is the core mission of Wangari. We build agentic and causal AI infrastructure designed specifically to automate complex regulatory reporting. We provide the reliability, auditability, and deep integration required to deploy these systems safely in highly regulated environments.

The Actuarial Time Trap is not an inevitable reality of the insurance industry. It is a solvable problem. And with the advent of agentic AI, we finally have the tools to solve it.

Meanwhile, at Wangari

We are now in Week 2 of the “From Demo to Production” course, and the cohort is diving deep into the complexities of AI orchestration patterns and workflows.

We’ve already had some fascinating discussions about what it means to move beyond simple accuracy metrics — or to even build a working system that you can measure in the first place. We have had robust discussions about how it’s almost never the model’s fault, and how much human (!) labor is needed to get AI systems anywhere close to production-ready.

The insights generated by this cohort are already shaping the way we think about AI orchestration at Wangari. It is a powerful reminder that the best way to learn is to teach, and the best way to build robust systems is to engage with a community of practitioners facing the same challenges.

Reads of the Week

• Emerging Risks of Agentic AI in Actuarial Work by and : An essential read on the unique challenges and ethical considerations of deploying autonomous agents in the actuarial profession. The authors provide a clear-eyed assessment of how traditional governance frameworks must evolve to handle systems that can reason and act independently.

• Hidden Technical Debt in Agentic Systems by : A reminder that the true complexity of AI automation lies not in the model, but in the surrounding infrastructure. This piece is particularly relevant for actuarial teams looking to move beyond simple pilot projects and build resilient, production-grade reporting pipelines.

• Can analysis ever be automated? by : A thoughtful exploration of the limits of automation in data analysis and the enduring need for human judgment. Stancil argues that while AI can accelerate the mechanical aspects of analysis, the strategic interpretation of data remains a fundamentally human endeavor.

Topics covered: Soccer analytics, World Cup prediction, Expected Goals (xG), distribution shift, small-sample statistics, feature engineering, predictive modeling, O’Reilly Media, enterprise AI context.

Wangari is the newsletter and podcast for practitioners and leaders navigating the real work of enterprise AI. New episodes every Friday.

https://wangari.global/contact

Ari’s book (O’Reilly Media, early release out now and officially out around June 25): Soccer Analytics with Machine Learning

Every four years, the same thing happens.

A major football analytics site publishes its World Cup predictions. A few academic groups release theirs. Goldman Sachs releases one too, because Goldman Sachs releases one of everything. They run thousands of simulations, train models on Bundesliga data, layer in xG and shot-quality metrics, and then they tell you, with a confidence interval, that Brazil has a 17.2% chance of lifting the trophy.

Then the World Cup happens, and it doesn’t.

I’m not going to argue that ML can’t predict football. I just wrote a book about exactly that. What I’m going to argue is something narrower and more uncomfortable: most of the techniques that make ML useful in club football break down for the World Cup, and the analytics community has spent two decades pretending this isn’t true.

There’s incentives for this (sports betting, anyone?) — but that doesn’t make it truer.

The training data is wrong

Football ML lives and dies on data. The richest dataset we have is the club game — five major European leagues, multiple cup competitions, roughly 2,000 top-flight matches a year per major league. Decades of it. Coaches who manage 50 matches a season for ten years. Players who play together every single week.

International football has approximately none of that.

A World Cup squad spends about 25 days together in the year leading up to the tournament. The starting eleven you’ll see against Argentina in June has almost certainly never played that exact lineup before this calendar year. Your fancy possession network metric? It was trained on teams that had 200 matches of muscle memory. The model doesn’t know that the back four you’re feeding it has played together six times.

The technical name for this is “distribution shift.” The honest name is “we have no idea what we’re predicting.” Most public World Cup models paper over this by aggregating individual player ratings into team strength scores. That sort of works for group stage. It collapses in the knockout rounds, where formations get cagey, managers go conservative, and one substitution rewires the whole tactical setup.

If you’re going to deploy ML in a domain, the first question to ask is whether your training distribution matches your deployment distribution. For the World Cup, the honest answer is not even close.

xG was never built for this

Expected goals is the best metric football analytics has produced. I use it in the book, I think it’s genuinely a step forward, and I’d defend it against anyone who calls it nonsense.

But xG is a shot-level metric trained on Premier League and Bundesliga shot data. It was designed for repeated trials in similar contexts. The World Cup gives you seven matches, maybe, for the team you care about. Half of those matches end in 1–0 results or worse. Aggregate-xG noise dominates the signal at small sample sizes — this is a basic statistical fact that gets quietly ignored when people pump World Cup predictions through their xG-based pipelines.

There’s a deeper problem. xG models are trained on “normal” attacking play in club football. They have no idea what to do with extra time in a knockout match where one team has been parking the bus for 30 minutes and is now trying to score on a single counter. The data those models learned from doesn’t contain very many of those situations. International knockout football contains a lot of them.

You can absolutely build an xG model that works for the World Cup. You just can’t use the Premier League one and assume it transfers.

Form doesn’t transfer

Here’s a thought experiment. A striker scores 32 goals in La Liga from August to May. His national team plays four friendlies in the meantime, in which he scores zero. Which is the predictive signal for what he’ll do at the World Cup?

Most public models implicitly say: weight the 32. Use his “true talent” as inferred from his club output. Plug it into the international model.

This is wrong for a specific reason. The 32 goals were scored in a system, with a manager he sees every day, with teammates who know exactly where to put the through-ball. He arrives at the World Cup as an extraordinary player attached to a team that has practiced his preferred runs perhaps twice. International form for international striker output is the more honest signal, even though the sample is brutal.

The football analytics community has known this for years. Every analyst in private will tell you. None of the public predictive models I’ve seen meaningfully correct for it, because the obvious correction (downweighting club performance) catastrophically reduces the signal you have to work with.

You don’t get to wish away the small-sample problem by averaging in irrelevant data.

So what does work?

That’s a reasonable question by ambitious people. If most of football ML breaks for the World Cup, what’s actually predictive?

A few things are not quite as fashionable as ML pipelines but get closer to the right answer:

Squad market value. Boring, embarrassing, true. The total transfermarkt valuation of a squad is one of the strongest publicly available predictors of tournament progression. Not because money buys winners, but because it’s a market-aggregated bet on individual quality, made by people with real money on the line. ML models often beat this baseline by 1–2 percentage points after thousands of features. It’s worth asking what you’ve actually added.

Manager continuity. Teams whose manager has been in place for 18+ months consistently outperform teams with new appointments. This is partly because they have a system, partly because the players have trust, and partly because the manager has had time to identify and stop using their worst players. It’s hard to put into a model cleanly; it shows up anyway when you do.

Tournament experience as a team. Not as individuals. The cohort of players who’ve played a knockout international match together has more predictive power than aggregate caps. Spain’s 2010 team had two and a half cycles of building. France’s 2018 team had two. The 2022 Argentina team had a manager who’d been in place for four years. There’s a pattern, even though “tournament experience as a team” doesn’t fit cleanly into a feature vector.

Group draw difficulty. Trivially obvious, but most ML models bake this into other features rather than respecting it as the structural variable it is. Whether your route to the semifinal goes through Brazil or through Costa Rica matters more than any in-game metric.

If your World Cup model can’t beat a simple weighted combination of those four, it isn’t doing anything that justifies its training cost.

The deeper thing

Football analytics keeps wanting to be Moneyball. It’s been trying for fifteen years. There’s been real progress — modern shot maps, possession value, EPV-style models, automated tracking data — and I’m not the guy who’s going to tell you it was wasted.

But the World Cup is the part of football where Moneyball logic breaks the hardest, because Moneyball relied on the law of large numbers. 162 baseball games. Repeated trials. The dice converge to their fair value over a long enough season.

The World Cup is seven matches per team. Maybe two of them are knockout games that go to penalties. The dice don’t converge over seven throws. They land somewhere, and you live with where they landed.

I wrote a whole book about how to use ML in soccer well — what to model, what not to, how to set up your training data, what to do about the messy stuff. Soccer Analytics with Machine Learning, out from O’Reilly at the end of June. About a tenth of it is World Cup-specific. The rest is the part that does work — the part you can use on the league football that fills the other 47 weeks of your year.

By the time the World Cup actually starts, half the predictive models you’ll see have already been falsified by the warm-up matches. Watch the football. Watch the predictions. See for yourself which ones got Argentina–Saudi Arabia 2022.

I’d be impressed by anyone who got it right. I just wouldn’t pay them to do it again.

Meanwhile, at Wangari

If you’re curious, the book I mentioned earlier is coming out at O’Reilly Media in a couple of weeks! An un-edited early release is already available on the O’Reilly Learning Platform (it’ll be updated by the final version as soon as we’ve finished the last touches with the book’s production team).

I’ll let you know when the final version is out — will be available wherever books are sold.

Reads of the Week

• The Promise and Limits of Machine Learning in Football Attacking Analysis: In this deep dive for The xG Football Club, reviews a landmark academic paper examining how supervised and unsupervised machine learning has been applied to attacking performance in professional football — from pass-pattern clustering to off-ball scoring opportunity models. He argues that while the field has moved well beyond simple event counts, most models still struggle to capture the contextual and interactive dynamics that actually drive goals. For a Wangari audience thinking about the gap between data richness and decision-making quality, this is a sharp reminder that more data does not automatically mean better insight.

• Does Liverpool FC Have a Data Science Problem?: In this essay, data scientist traces Liverpool’s post-Ian-Graham recruitment decline and argues the club is suffering from a classic failure of “non-agentic data science” — where models inform but do not recommend, and the critical translation layer between analysts and decision-makers has essentially broken down. The piece is a compelling case study in what happens when the head of a high-stakes data function moves on and institutional knowledge does not transfer cleanly. Anyone building or inheriting a data team in a high-variance, low-volume decision environment — think insurance underwriting or credit risk — will find the parallels uncomfortably familiar.

• Football Fans Are Drowning in Data, Starved of Wisdom: In this essay for xGuff (Expected Guff), applies the Data–Information–Knowledge–Wisdom (DIKW) pyramid to the explosion of football analytics and finds the pyramid severely bottom-heavy: vast quantities of event and tracking data at the base, but precious little wisdom at the tip. He walks through vivid examples of how correct statistics are routinely used to reach wildly incorrect conclusions — from manager-sacking survival rates to the ongoing xG wars on TalkSport — and asks whether the volume of information is actually making the sport harder to understand. It is a timely provocation for anyone in data-heavy industries who has ever wondered whether their dashboards are generating knowledge or just more noise.

In this episode, Ari Joury (PhD, particle physics; Founder & CEO of Wangari Global) breaks down the anatomy of “The Slow Collapse” — the phenomenon where an AI system continues to run, but the quality of its outputs imperceptibly declines over time. Ari explains the three primary drivers of silent degradation (Data Drift, Model Drift, and Context Window Saturation) and outlines the observability and governance frameworks required to catch them before they cause catastrophic business impact. And yes, he will explain why your AI agent is basically a tired intern who forgot what they were doing on page 35.

Topics covered: AI observability, silent degradation, data drift, model drift, context window saturation, LLM monitoring, AI governance, enterprise AI deployment, automated evaluation pipelines.

Wangari is the newsletter and podcast for practitioners and leaders navigating the real work of enterprise AI. New episodes every Thursday.

https://wangari.global/contact

Upcoming Course: From Demo to Production

There is a specific type of anxiety that comes with deploying an autonomous AI agent into a production enterprise environment. It is not the fear that the system will crash immediately upon launch. That kind of failure is loud, obvious, and relatively easy to fix.

The true fear is silent degradation.

It is the fear that the system will continue to run, continue to generate reports, and continue to make decisions, but that the quality of those outputs will slowly, imperceptibly decline over time. By the time the degradation becomes obvious to a human reviewer, the system may have already processed thousands of transactions or generated dozens of flawed regulatory filings.

In the world of traditional software engineering, code does not rot. A function written today will execute exactly the same way five years from now, provided the underlying environment remains stable.

That’s not to say that software packages and even operating systems don’t evolve — so some maintenance is needed — but at least that evolution can be tracked and followed, plus there will be many others undergoing the exact same evolution at the same time.

AI systems are fundamentally different. They are probabilistic, and they are highly sensitive to their environment. They do not just break; they drift.

The Anatomy of Silent Degradation

Silent degradation in an AI system typically stems from one of three sources:

1. Data Drift: The distribution of the input data changes over time. If an AI agent was designed to process insurance claims based on historical data from 2023, it may struggle to accurately process claims in 2026 if the underlying nature of those claims has shifted due to new regulations, economic conditions, or changing customer behavior. The model is still functioning as designed, but the world has moved on.

2. Model Drift: The underlying foundation model is updated by the provider. While API providers strive for backward compatibility, even minor updates to a model’s weights or safety filters can subtly alter its behavior. A prompt that consistently yielded a perfectly formatted JSON object yesterday might suddenly start including conversational filler today, breaking the downstream orchestration pipeline.

3. Context Window Saturation: As an agentic system operates, it often accumulates state or context. If the system is not designed to elegantly manage this context—summarizing, pruning, or archiving older information—the context window can become saturated with irrelevant noise. The model’s attention mechanism becomes diluted, leading to hallucinations or degraded reasoning capabilities.

The Observability Imperative

The only defense against silent degradation is rigorous, continuous observability.

In traditional software, observability means monitoring CPU usage, memory consumption, and error rates. In AI systems, these metrics are necessary but entirely insufficient. You can have a system with 99.9% uptime and sub-second latency that is confidently generating complete nonsense.

AI observability requires monitoring the quality of the output, not just the health of the infrastructure.

This means implementing automated, continuous evaluation pipelines. It requires defining specific, measurable characteristics of a “good” output and running statistical checks against every inference. Are the generated reports adhering to the required structural format? Is the sentiment of the output remaining consistent? Are the specific entities extracted from the input data matching expected patterns?

Crucially, it requires establishing baseline metrics—a “golden dataset”—and continuously comparing production outputs against that baseline to detect subtle shifts in distribution. As points out in an interview with , because it relies on static schema checks rather than dynamic, partition-based summarization.

The Illusion of Interpretability

When degradation is detected, the immediate instinct is to ask *why* the model failed. This leads many teams down the rabbit hole of post-hoc interpretability methods, such as SHAP values or feature attribution techniques.

However, these methods often provide a false sense of security. As researchers have noted, explaining models after training often fails to capture the true causal mechanisms driving the model’s behavior. These post-hoc explanations are essentially models of models—approximations that can be just as flawed or biased as the original system.

Instead of relying on illusory interpretability, enterprise AI systems must be built with intrinsic transparency. This means designing orchestration layers where the logical steps are explicit and auditable, rather than relying on a single massive neural network to perform complex reasoning in a black box.

The Cost of Ignoring Drift

The financial and reputational costs of ignoring silent degradation can be staggering. In the financial sector, a trading algorithm that slowly drifts out of alignment with market realities can wipe out millions of dollars before the error is caught. In healthcare, a diagnostic model that degrades over time can lead to misdiagnoses and compromised patient care.

The insidious nature of silent degradation is that it often goes unnoticed by the very people who rely on the system the most. Users become accustomed to the system’s quirks and begin to subconsciously compensate for its declining performance. They might start double-checking the AI’s work more frequently, or manually correcting minor errors, effectively masking the degradation from the engineering team.

This is why observability cannot rely on user reporting. It must be automated, objective, and continuous.

From Monitoring to Governance

Observability is the mechanism for detecting degradation, but governance is the framework for responding to it.

When an automated evaluation pipeline detects that an agent’s output quality has drifted below an acceptable threshold, what happens next? Does the system automatically halt? Does it route the task to a human operator? Does it trigger an alert to the engineering team?

A robust governance framework defines these escalation paths. It establishes clear ownership for the ongoing health of the system. It ensures that there is a “human in the loop” not just for individual decisions, but for the systemic oversight of the AI agent itself.

At Wangari, we believe that deploying an AI system without this level of observability and governance is professional malpractice, particularly in regulated industries. The stakes are simply too high.

The transition from a successful demo to a reliable production system is not just about writing better code. It is about building the operational infrastructure required to manage probabilistic systems in a deterministic world. It is about acknowledging that AI systems are not static artifacts, but dynamic entities that require continuous care and feeding.

Meanwhile, at Wangari

The challenge of silent degradation is exactly why I designed my upcoming course to focus heavily on evaluation and operations.

From Demo to Production: Operationalize an Enterprise-Grade Agentic AI Reporting System launches next week, on June 9th.

In Week 3 of the course, we dive deep into “Decision-Grade Evaluation,” moving beyond simple accuracy metrics to build comprehensive evaluation scorecards. In Week 5, we cover “Operational Excellence,” focusing on deployment strategies, monitoring dashboards, and governance frameworks.

If you are responsible for ensuring that your organization’s AI systems remain reliable long after the initial deployment, this course will give you the practical blueprints you need.

Enrollment closes soon. Secure your spot at GenAI Academy.

Reads of the Week

• Grounded Research: From Google Brain to MLOps to LLMOps by and featuring : A deep dive into the principles of production-grade machine learning and the critical importance of robust data validation. Shankar argues that traditional MLOps practices are insufficient for LLMs, and that we need new paradigms for evaluating and monitoring generative systems in production.

• The Interpretability Illusion: Why Explaining Models After Training Fails by : A compelling argument against relying on post-hoc interpretability methods and the need for intrinsically transparent models. The author demonstrates how techniques like SHAP can provide misleading explanations, emphasizing the need for causal reasoning built directly into the architecture.

• Hidden Technical Debt in Agentic Systems by : An essential read on why the infrastructure surrounding an AI model is where the true engineering risk lies. Pedrido breaks down the hidden costs of orchestration, state management, and error handling that are often ignored during the pilot phase.

In this episode, Ari Joury (PhD, particle physics; Founder & CEO of Wangari Global) takes a break from enterprise AI to preview his upcoming O’Reilly book, Soccer Analytics with Python. He explains why the fluid, chaotic nature of soccer is the perfect laboratory for understanding predictive modeling, feature engineering, and the limits of correlational data. From the evolution of Expected Goals (xG) to the bias-variance tradeoff on the pitch, Ari shows how the lessons learned from analyzing sports data translate directly to building robust AI systems for the enterprise. And yes, he will explain why your AI model is basically a confused midfielder passing the ball backward.

Topics covered: Soccer analytics, Expected Goals (xG), feature engineering, bias-variance tradeoff, causal inference, predictive modeling, O’Reilly Media, Python data science, enterprise AI context.

Wangari is the newsletter and podcast for practitioners and leaders navigating the real work of enterprise AI. New episodes every Friday.

https://wangari.global/contact

Ari’s book (O’Reilly Media, early release out now and officially out in June): Soccer Analytics with Machine Learning

If you want to understand the complexities of machine learning, you could start by studying linear algebra, calculus, and probability theory. You could immerse yourself in academic papers on gradient descent and backpropagation.

Or, you could watch a soccer match.

At first glance, the chaotic, fluid nature of soccer seems entirely disconnected from the structured world of data science. But beneath the surface of every pass, tackle, and shot on goal lies a rich tapestry of data waiting to be analyzed. In fact, the challenges inherent in modeling a soccer match perfectly mirror the challenges of building robust machine learning systems for the enterprise.

This realization is what drove me to co-author my upcoming book, Soccer Analytics with Python (O’Reilly Media). The goal was not just to write a book for sports fans, but to use the universal language of soccer to demystify machine learning concepts that often feel abstract and inaccessible.

Frankly, it was also just fun to write as a way to combine my soccer-playing teenage years with my code-crunching twenties. But hey, here we are, old, wise and having fun with soccer analytics.

The Beautiful Game as a Data Problem

Consider the fundamental problem of predicting a match outcome. It is not a simple deterministic equation. It is a highly probabilistic scenario influenced by dozens of interacting variables: player form, tactical formations, weather conditions, historical matchups, and the sheer unpredictability of human behavior.

When we attempt to model this, we encounter the exact same issues that plague enterprise data scientists.

We must deal with feature engineering—deciding which variables actually matter. Is a team’s recent possession percentage more predictive than their historical expected goals (xG)? We must grapple with the bias-variance tradeoff, ensuring our model is complex enough to capture the nuances of the game without overfitting to the noise of a single anomalous match.

We must also confront the limitations of purely correlative models. A model might find a strong correlation between a specific player wearing yellow boots and their team winning. But without causal reasoning, the model cannot distinguish between a meaningless coincidence and a true driver of performance. As Alex Marin Felices points out, while machine learning models can identify correlations between performance indicators and success, they often struggle to represent the interactive and dynamic nature of attacking play.

From the Pitch to the Boardroom

The lessons learned from analyzing soccer data translate directly to the big-corp boardroom, and how they’re looking at nascent machine learning and AI projects in their enterprises.

In the book, we explore techniques like logistic regression, random forests, and deep learning, applying them to real-world soccer datasets. We build models to predict match outcomes, evaluate player performance, and even test betting strategies.

But the underlying principles are universal. The same random forest algorithm used to predict whether a striker will score from a specific location on the pitch can be used by an insurance company to predict the likelihood of a claim. The same simulation techniques used to model different tactical scenarios can be used by a financial institution to stress-test their portfolio against market shocks.

By grounding these concepts in a domain that is intuitive and engaging, we can strip away the intimidating jargon and focus on the core mechanics of how machine learning actually works.

The Importance of Context

Perhaps the most important lesson soccer teaches us about data science is the critical importance of context.

In soccer, a raw statistic like “total passes completed” is almost meaningless without context. Were those passes progressive, breaking through the opponent’s defensive lines, or were they safe, lateral passes between defenders?

Similarly, in enterprise AI, data without context is a liability. A model trained on historical financial data might identify a pattern, but without understanding the underlying economic context—the regulatory changes, the market dynamics, the causal relationships—that pattern is likely to be misleading.

This is why at Wangari, we emphasize causal AI. We believe that true intelligence requires understanding the why behind the data, not just the what. Whether you are analyzing a soccer match or automating complex regulatory reporting, context is the difference between a model that merely describes the past and a system that can reliably navigate the future.

The Future of Sports Analytics

The integration of AI into sports is accelerating rapidly. For the 2026 World Cup, FIFA plans to create AI-enabled 3D avatars of every player to ensure precise player identification and tracking for semi-automated offside decisions. This level of data capture represents a massive leap forward, but it also highlights the tension between technological precision and human judgment.

As decisions become more exact, they can also feel more arbitrary to spectators. If an attacker is ruled offside because a 3D scan shows a shoulder fractionally further forward than previously assumed, it raises questions about fairness and the role of technology in the game. This mirrors the challenges we face in enterprise AI, where highly accurate models can sometimes produce decisions that are difficult for humans to interpret or trust.

The Evolution of Expected Goals

One of the most fascinating developments in soccer analytics is the evolution of the “Expected Goals” (xG) metric. Early xG models were relatively simple, relying primarily on the distance and angle of the shot relative to the goal.

Today, state-of-the-art xG models are vastly more sophisticated. They incorporate the positions of all defenders and the goalkeeper, the velocity of the pass preceding the shot, and even the specific body part used to strike the ball. This evolution perfectly illustrates the concept of feature engineering—the continuous process of refining the inputs to a model to capture more of the underlying reality.

In the enterprise, we see a similar evolution. Early predictive models about, say, customer conversions relied on simple demographic data. Today, advanced models incorporate behavioral data, network graphs, and unstructured text analysis. The goal is always the same: to move from a crude approximation of reality to a high-fidelity representation.

Bridging the Gap

Writing Soccer Analytics with Python has been a fascinating exercise in translation. It has reinforced my belief that the most complex technical concepts can be made accessible when framed through the right lens.

The book is designed for anyone who wants to develop a solid foundation in machine learning, whether you are a student, an analyst, or simply a fan of the game. It bridges the gap between academic principles and practical applications, proving that you don’t need a PhD in particle physics to understand how to build predictive models.

The beautiful game is more than just a sport. It is a masterclass in probability, strategy, and the power of data.

Meanwhile, at Wangari

While I have been busy writing about soccer analytics, the core focus at Wangari remains on solving the hardest data challenges in the enterprise.

If you are a technical leader looking to bridge the gap between AI prototypes and production systems, my upcoming course is designed for you.

From Demo to Production: Operationalize an Enterprise-Grade Agentic AI Reporting System launches on June 9th. Over 6 weeks, we will cover the orchestration, evaluation, and governance frameworks necessary to build reliable AI systems.

Enrollment is open now at GenAI Academy.

And if you are interested in exploring machine learning through the lens of soccer, my new book, Soccer Analytics with Python, will be published by O’Reilly Media in late June, just in time for the World Cup.

Reads of the Week

• The Promise and Limits of Machine Learning in Football Attacking Analysis by : A critical review of how machine learning is applied to analyze attacking performance and the challenges of representing dynamic play. Felices rightly points out that while models excel at finding correlations, they often fail to capture the complex, multi-agent interactions that define a successful attack.

• Opinion: Inside the World Cup’s AI offside revolution by : An insightful look at FIFA’s plan to use AI-enabled 3D avatars for the 2026 World Cup and the implications for the game. Lisi explores the tension between technological precision and the human element of refereeing, a debate that mirrors discussions about AI governance in the enterprise.

• Hidden Technical Debt in Agentic Systems by : A reminder that whether in sports analytics or enterprise AI, the model is just a small part of the overall system complexity. Pedrido’s analysis of the infrastructure required to support autonomous agents is a must-read for anyone moving beyond simple API calls.

In this episode, Ari Joury (PhD, particle physics; Founder & CEO of Wangari Global) makes the case that the most valuable skill in enterprise AI today is not the ability to train a model — it is the ability to operationalize one. He goes deep on orchestration patterns, decision-grade evaluation, and governance architecture, drawing on research from MIT Sloan, Google Brain, and his own experience building causal AI systems for the insurance industry. If you want to understand what actually separates a fragile prototype from a production-grade AI system, this episode is for you.

Topics covered: AI orchestration, LLM evaluation, golden datasets, AI governance, enterprise AI deployment, agentic workflows, causal AI, Solvency II, IFRS 17, AI systems engineering, production AI, MLOps.

Wangari is the newsletter and podcast for practitioners and leaders navigating the real work of enterprise AI. New episodes every Friday.

Check out my new course From Demo to Production at the GenAI Academy

For further inquiries & demos, here you go: https://wangari.global/contact

When I transitioned from theoretical particle physics to enterprise AI, I expected the challenges to be primarily mathematical. I anticipated spending my days fine-tuning neural network architectures, optimizing hyperparameters, and debating the merits of different attention mechanisms.

I was wrong.

The mathematics of modern AI are undeniably fascinating, but they are increasingly commoditized. The foundation models available via API today are more capable than anything a typical enterprise could build from scratch. The real challenge—the problem that actually prevents organizations from realizing value from AI—is not the model itself. It is everything that surrounds the model.

It is the orchestration. It is the evaluation. It is the governance.

In short, it is the “boring” parts of AI. And these boring parts are exactly what I have decided to focus on teaching.

The Glamour vs. The Reality

The AI industry has a glamour problem. The discourse is dominated by discussions of parameter counts, benchmark scores, and the existential implications of artificial general intelligence. This is the exciting, visionary side of the field.

But when you sit down with a Chief Actuary at a major insurance firm, or a Head of Compliance at a global bank, the conversation shifts dramatically. They do not care about the latest benchmark on a generic reasoning task. They care about auditability. They care about data privacy. They care about whether a system will hallucinate a regulatory filing that could result in a multi-million dollar fine.

They are grappling with the reality of deploying probabilistic systems into deterministic business environments.

This is where the glamour fades and the hard engineering begins. Building a robust AI system requires solving problems that are decidedly unsexy but absolutely critical. As the IFoA GenAI Working Party points out, the complexity and autonomy of a network of AI agents add a new dimension to risks, making them harder to manage and requiring dynamic governance frameworks.

Orchestration: The Unsung Hero

Consider orchestration. A single prompt to an LLM is rarely sufficient to complete a complex enterprise task. Real-world workflows require multiple steps: retrieving data from disparate sources, validating that data, processing it through various models, handling errors, and formatting the final output.

Designing these multi-step agentic workflows is an exercise in systems engineering. It requires choosing the right orchestration pattern—whether a sequential chain, a parallel fan-out, or a complex graph-based approach. It demands robust error handling, retry logic, and state management.

When an orchestration layer is designed well, it is invisible. The system simply works. But getting to that point requires rigorous architectural thinking that goes far beyond writing a clever prompt. As Gary Marcus highlights, [autonomous agents are often vulnerable to subtle but dangerous tool-chaining attacks](https://garymarcus.substack.com/p/breaking-autonomous-agents-are-a), proving that orchestration is not just about functionality, but security [2]. If an agent is granted access to a database and an email client without strict guardrails, a simple prompt injection can turn a helpful assistant into a massive security breach.

Evaluation: Beyond the Vibe Check

Then there is evaluation. How do you know if an AI system is actually performing well?

In the early days of generative AI, evaluation often consisted of a “vibe check”—running a few queries and subjectively deciding if the answers looked reasonable. This is entirely inadequate for enterprise deployment.

Decision-grade evaluation requires a multi-dimensional framework. We must measure not just accuracy, but reliability, latency, and cost. We must build automated test suites that evaluate output characteristics against golden datasets. We must implement regression testing to ensure that an update to a prompt or a model does not silently degrade performance on edge cases.

Building a comprehensive evaluation scorecard is tedious work. It requires defining specific, measurable metrics and establishing acceptable thresholds for each. But without it, deploying an AI system is essentially flying blind. You cannot improve what you cannot measure, and in the context of enterprise AI, failing to measure performance accurately is a dereliction of duty.

Governance: The Prerequisite for Trust

Finally, there is governance. In regulated industries, an AI system must be auditable. If a system makes a recommendation or generates a report, the organization must be able to trace exactly how that output was produced. What data was used? What logical steps were taken?

This is where causal AI becomes essential. Unlike purely correlative models, causal models provide a transparent chain of reasoning. They allow us to understand not just what the system predicted, but why.

Implementing robust governance also means establishing clear ownership, defining escalation paths, and ensuring compliance with data privacy regulations. It is the bureaucratic scaffolding that makes trust possible. The IFoA GenAI Working Party emphasizes that static governance frameworks are doomed to fail if they do not recognize how the capabilities of these agents might change over time. Governance must be as dynamic and adaptable as the systems it seeks to control.

The Shift from Development to Operations

The transition from building a prototype to running a production system is a fundamental shift in mindset. It is the shift from development to operations.

In development, the goal is to prove that something is possible. In operations, the goal is to ensure that it happens reliably, every single time, regardless of the input or the environment. This requires a different set of skills, a different set of tools, and a different set of priorities.

It requires embracing the boring parts.

Embracing the Boring

I have come to realize that the most valuable skill in enterprise AI today is not the ability to train a model. It is the ability to operationalize one.

The teams that will win in this era are not necessarily the ones with the most advanced algorithms. They are the ones that master the boring parts. They are the ones that build resilient orchestration layers, rigorous evaluation frameworks, and transparent governance structures.

This is the work we do at Wangari. We focus on the infrastructure that makes AI reliable and auditable for complex regulatory reporting.

And it is exactly why I am so passionate about teaching these concepts. The industry needs fewer prompt engineers and more AI systems engineers. We need professionals who understand how to bridge the gap between a fragile prototype and a robust production system.

The boring parts of AI may not make headlines, but they are the foundation upon which the future of enterprise technology will be built.

Meanwhile, at Wangari

If you are ready to master the “boring” (but essential) parts of enterprise AI, my upcoming course is designed for you.

**From Demo to Production: Operationalize an Enterprise-Grade Agentic AI Reporting System** is a 6-week intensive program that focuses entirely on the operational realities of AI deployment.

We will not spend time debating model architectures. Instead, we will dive deep into orchestration patterns, decision-grade evaluation metrics, automated testing, and governance frameworks. By the end of the course, you will have developed a complete Production Blueprint for your own AI system.

The cohort begins on June 9th. If you want to move your AI initiatives out of the lab and into production, I invite you to join us.

Enrollment is open now at GenAI Academy.

Reads of the Week

• Emerging Risks of Agentic AI in Actuarial Work by and : An exploration of the ethical considerations and practical implications of deploying AI agents in highly regulated environments. The authors provide a sobering look at how the autonomy of these systems introduces entirely new categories of risk that traditional governance frameworks are ill-equipped to handle.

• Breaking: Autonomous Agents are a Shitshow by : A critical look at the vulnerabilities of autonomous agents, particularly regarding tool-chaining attacks and security nightmares. Marcus argues that until we solve the fundamental security flaws inherent in granting LLMs access to external tools, deploying them in enterprise environments is dangerously irresponsible.

• Can analysis ever be automated? by : A thoughtful discussion on the challenges and catch-22s of AI analysts and the automation of data analysis. Stancil explores the paradox that while AI can generate code and run queries faster than humans, it still lacks the contextual understanding required to know which questions are actually worth asking.

In this episode, Ari Joury (PhD, particle physics; Founder & CEO of Wangari Global; author, O’Reilly Media) breaks down the complete taxonomy of AI production failure: Technical Debt, Operational Debt, Evaluation Debt, Integration Debt, and Governance Debt. Drawing on research from MIT, McKinsey, Gartner, and S&P Global — as well as his own experience deploying causal AI systems in the insurance industry — Ari gives you the diagnostic framework to identify which debts your project is carrying, and the playbook to pay them down before they kill your launch.

Topics covered: enterprise AI failure rates, LLM production readiness, AI technical debt, orchestration, evaluation scorecards, governance frameworks, agentic AI systems, insurance AI, regulatory compliance, demo-to-production gap.

Wangari is the newsletter and podcast for practitioners and leaders navigating the real work of enterprise AI. New podcast episodes every Friday.

https://wangari.global/contact

Upcoming Course: From Demo to Production

It is a familiar story for innovation teams. A small, agile team builds an AI prototype over a weekend. It summarizes documents flawlessly. It answers complex queries. The executive sponsor is thrilled. The demo is a triumph.

Six months later, the project is quietly abandoned.

This is not an isolated incident. Across the enterprise landscape, we are witnessing a massive deployment gap. While adoption of generative AI tools by individual knowledge workers has skyrocketed, the percentage of organizations successfully deploying autonomous, agentic AI systems into core production workflows remains stubbornly low. According to recent analyses, a staggering majority of generative AI pilots fail to achieve measurable business impact or reach full production scale, with some estimates suggesting up to 95% of pilots fail.

The problem is rarely the underlying foundation model. The models are increasingly capable, reasoning with nuance and processing vast amounts of context. The failure occurs because organizations mistake a successful demo for a viable system.

A demo proves that a model can perform a task in isolation. A production system must perform that task reliably, securely, and economically, thousands of times a day, integrated into existing workflows, and governed by strict compliance standards. The space between these two realities is what I call the Production Gap.

When an AI pilot fails to cross this gap, it is usually because the team has accumulated one or more of five specific types of “debt.” Understanding these debts is the first step to building AI systems that actually survive contact with the real world. As Miguel Otero Pedrido notes, the model code is merely a rounding error in the actual size of the system; the real complexity lies in the surrounding infrastructure.

1. Technical Debt: The Brittle Foundation

In the rush to build a compelling demo, teams often hardcode prompts, bypass error handling, and ignore edge cases. This is acceptable for a proof of concept, but fatal in production.

Technical debt in AI systems manifests as brittleness. When the API response format changes slightly, the system crashes. When a user inputs an unexpected query, the agent hallucinates wildly rather than failing gracefully. Production-grade AI requires robust orchestration. It needs retry logic with exponential backoff, fallback mechanisms to alternative models or data sources, and state management that can handle interruptions.

If your architecture diagram consists of a single arrow pointing from a user interface to an LLM API, you are carrying massive technical debt. The naive setup of running every request through a single expensive frontier model is economically deranged in production [2]. A real production setup requires a router, a model fleet, and a fallback chain to ensure reliability and cost-efficiency.

Furthermore, the code that glues these components together is often written hastily. This “glue code” becomes a massive liability as the system scales, making it nearly impossible to debug when the system inevitably fails in unexpected ways.

2. Operational Debt: The Orphaned System

A traditional software application, once deployed, is relatively stable. An AI system is a living, breathing entity that degrades over time. Models drift. Underlying data distributions change. The prompts that worked perfectly in January may produce suboptimal results in June.

Operational debt occurs when an organization deploys an AI system without establishing clear ownership for its ongoing maintenance. Who monitors the system for silent degradation? Who updates the prompts when a new model version is released? Who handles the escalation when the agent encounters a scenario it cannot resolve?

Without a dedicated operations layer—including robust observability tools and a clear RACI (Responsible, Accountable, Consulted, Informed) matrix—an AI system will inevitably become an orphaned liability. Markdown configs, such as prompts and skill definitions, must be treated as source code with proper version control and peer review.

The lack of operational readiness is often the silent killer of AI projects. Teams celebrate the launch, but fail to allocate the resources required to keep the system healthy in the months and years that follow.

3. Evaluation Debt: The Accuracy Illusion

How do you know if your AI system is working? If the answer is “we spot-checked a few outputs and they looked good,” you are suffering from evaluation debt.

In traditional software, testing is deterministic: given input X, the system must produce output Y. AI systems are probabilistic. They require a fundamentally different approach to evaluation. Relying solely on average accuracy metrics is a trap. A system that is 95% accurate might still fail catastrophically on the 5% of edge cases that matter most to the business.

Decision-grade evaluation requires measuring multiple dimensions: reliability (consistency of output), latency, cost per inference, and ultimately, decision impact. It requires automated test suites that evaluate output characteristics against a “golden dataset” of expected behaviors, rather than demanding exact string matches. As Hamel Husain emphasizes, systematically measuring your AI product is crucial to escape “vibe-check hell.”

Building these evaluation frameworks is tedious, unglamorous work. But without them, you are flying blind, unable to distinguish between a minor model update and a catastrophic system failure.

4. Integration Debt: The Workflow Mismatch

The most brilliant AI agent is useless if it does not fit seamlessly into the way people actually work. Integration debt occurs when an AI system is built in a silo, disconnected from the enterprise’s core data systems and operational workflows.

This often looks like a standalone chatbot interface that requires users to manually copy and paste data from their CRM or ERP systems. True enterprise value comes from agentic workflows that can autonomously retrieve data, process it, and execute actions across multiple systems.

Overcoming integration debt requires treating the AI not as a destination, but as a routing and processing layer embedded within existing enterprise architecture. It requires deep collaboration between the AI engineers and the domain experts who actually understand the business processes being automated.

When AI systems are forced upon users without considering their existing workflows, adoption rates plummet, and the project ultimately fails to deliver a return on investment.

5. Governance Debt: The Compliance Blindspot

In highly regulated industries like insurance and financial services, governance is not an afterthought; it is a prerequisite for deployment. Governance debt accumulates when teams build AI systems without considering data privacy, auditability, and regulatory compliance from day one.

Can you explain exactly why the AI made a specific recommendation? Can you prove that no sensitive customer data was used to train a public model? If the system hallucinates a regulatory report, who is liable?

As frameworks like Solvency II and IFRS 17 demand increasing rigor in financial reporting, deploying “black box” AI systems is a non-starter. Production-grade AI requires causal reasoning and full audit trails, ensuring that every output can be traced back to its source data and logical steps.

Ignoring governance debt during the pilot phase is a guaranteed way to ensure the project is killed by the compliance team before it ever reaches production.

Bridging the Gap

The transition from demo to production is not merely a matter of writing better code. It requires a paradigm shift from experimenting with models to engineering robust, governed systems.

At Wangari, we focus on building agentic and causal AI infrastructure that addresses these five debts head-on. We believe that for AI to deliver on its promise in the enterprise, it must be built on a foundation of reliability, auditability, and deep integration.

The era of the impressive AI demo is over. The era of the resilient AI system has begun.

Meanwhile, at Wangari

If you are a technical leader, product manager, or data scientist struggling to move your AI initiatives out of “pilot purgatory,” I am teaching a 6-week live cohort course designed specifically to solve this problem.

From Demo to Production: Operationalize an Enterprise-Grade Agentic AI Reporting System launches on June 9th.

Over 10 live sessions, we will move beyond the hype and focus on the hard engineering and operational realities of enterprise AI. You will learn how to design robust orchestration layers, implement decision-grade evaluation metrics, and build systems that survive contact with the real world.

Enrollment is open now at GenAI Academy.

Reads of the Week

• Hidden Technical Debt in Agentic Systems by : A deep dive into why the model code is just a small part of an agentic system, and how the real engineering risk lives in the infrastructure around it. This piece is essential reading for anyone who thinks deploying an LLM is just a matter of making an API call, as it exposes the massive hidden costs of orchestration and state management.

• Why AI Evals Are An Increasingly Important Skill by : A practical guide on how to systematically measure AI products and escape the trap of relying on subjective “vibe checks.” Husain argues convincingly that without rigorous, automated evaluation frameworks, teams are essentially flying blind when they push updates to production.

• Grounded Research: From Google Brain to MLOps to LLMOps by and featuring Shreya Shankar: An insightful discussion on the principles of production-grade machine learning and the importance of data validation. This conversation highlights how the lessons learned from traditional MLOps are both highly relevant and fundamentally insufficient for the new era of generative AI.

It was a perfectly smooth experience. It was also, in retrospect, slightly unsettling.

If I had done that task myself a year ago, I would have spent an hour reading documentation and comparing providers. This time, I outsourced the judgment entirely. The agent made a reasonable call, but I didn’t actually know why it chose that specific provider. I just accepted the efficiency gain and paid the bill.

We talk a lot about the fear of “runaway AI”—the sci-fi scenario where autonomous systems hijack our businesses. But the reality of agentic AI is much quieter. The danger isn’t that the agent goes rogue. The danger is that the agent is always optimizing for something, and it’s not always what you think.

The Illusion of Shared Intent

When you delegate a task to a human analyst, you share a broad context. They know the implicit goal is to find a reliable, cost-effective solution that fits the company’s existing tech stack. They know when to stop researching and make a decision.

Agents do not share this context. They operate on objective functions. You give them a prompt, and they translate that prompt into a mathematical target to maximize. In the case of my DigitalOcean deployment, the agent was likely optimizing for the fastest path to a working configuration. It wasn’t optimizing for long-term cost efficiency or vendor lock-in risk, because I didn’t explicitly tell it to.

When the cost of making a decision drops to zero, we stop making decisions. We let the model choose based on its training data and hidden system prompts, not our strategic priorities. We get the efficiency, but we lose the steering wheel.

The Agent That Wouldn’t Stop

There is a second, more frustrating form of misalignment. I recently watched an agent try to pull a dataset from a public API where the endpoint had changed. A human would have stopped to ask for help. The agent did not. It retried the call, rephrased the headers, wrote a Python script for a different authentication method, and looped relentlessly, burning through API tokens.

Why? Because the underlying model was trained on a specific objective function: continue the conversation. Most commercial LLMs are fine-tuned to be helpful and conversational. They are penalized for giving up. When you wrap that conversational model in an agentic loop and give it an API key, that “helpful” persistence becomes a liability. It optimizes for continuation rather than completion.

The Bottom Line

We are entering a phase of technology where the primary skill is no longer execution, but delegation. The people and companies that thrive will not be the ones who write the best code. They will be the ones who know how to explicitly define their intent, and how to build the guardrails that keep their agents aligned with that intent.

The next time an agent does something perfectly for you, take a moment to ask yourself: what was it actually optimizing for? And are you sure it’s the same thing you wanted?

Author's note: Wangari is evolving, and so is this newsletter. We've refreshed the name, the look, and the focus — you'll find more on the company and what we're building at wangari.global. If you've been here since the early days, thank you. If you're new, welcome.

A few weeks ago, I needed to set up a frontend deployment for a new project. I opened an AI agent, gave it the parameters, and within minutes it had recommended DigitalOcean, configured the deployment, and handed me the setup. I clicked confirm, entered my payment details, and moved on with my day.

It was a perfectly smooth experience. It was also, in retrospect, slightly unsettling.

If I had done that task myself a year ago, I would have spent an hour reading documentation. I would have compared DigitalOcean against AWS, Vercel, and Heroku. I would have checked pricing tiers and read a few Reddit threads about latency. This time, I did none of that. I outsourced the judgment entirely. The agent made a reasonable call, but the truth is, I didn’t actually know why it chose that specific provider over the others. I just accepted the efficiency gain and paid the bill.

We talk a lot about the fear of “runaway AI”—the sci-fi scenario where autonomous systems hijack our businesses or our infrastructure. But the reality of agentic AI is much subtler, and in some ways, much more insidious. The danger isn’t that the agent goes rogue. The danger is that the agent is always optimizing for something, and it’s not always what you think.

The Illusion of Shared Intent

When you delegate a task to a human—say, an analyst on your team—you share a broad context. If you ask them to research a software vendor, they know that the implicit goal is to find a reliable, cost-effective solution that fits the company’s existing tech stack. They know when to stop researching and make a decision. They know what “done” looks like.

Agents do not share this context. They operate on objective functions. You give them a prompt, and they translate that prompt into a mathematical target to maximize.

In the case of my DigitalOcean deployment, the agent was likely optimizing for “fastest path to a working configuration based on the user’s prompt.” It wasn’t optimizing for long-term cost efficiency, because I didn’t explicitly tell it to. It wasn’t optimizing for vendor lock-in risk. It just found the shortest distance between my request and a successful execution.

This is the first form of misalignment: outsourced judgment. When the cost of making a decision drops to zero, we stop making decisions. We let the model choose. But the model is choosing based on its training data and its hidden system prompts, not based on your strategic priorities. You get the efficiency, but you lose the steering wheel.

The Agent That Wouldn’t Stop

There is a second, more frustrating form of misalignment, and if you’ve used agentic workflows recently, you’ve probably seen it.

I was watching an agent try to pull a specific dataset from a public API last week. The API endpoint had changed, and the agent’s initial request failed. A human would have looked at the error, realized the documentation was out of date, and stopped to ask for help or search for the new endpoint.

The agent did not stop. It retried the exact same call. When that failed, it slightly rephrased the headers and tried again. It wrote a Python script to try a different authentication method. It looped, and looped, and looped, burning through API tokens with relentless, cheerful persistence.

Why did it do this? Because the underlying model was trained on a specific objective function: continue the conversation.

Most commercial LLMs are fine-tuned using Reinforcement Learning from Human Feedback (RLHF) to be helpful, harmless, and conversational. They are penalized for giving up or saying “I don’t know.” When you wrap that conversational model in an agentic loop and give it a credit card or an API key, that “helpful” persistence becomes a liability. The agent doesn’t know when to quit because quitting is penalized in its training data. It optimizes for continuation rather than completion.

The Hidden Cost of Misaligned Agency

These two scenarios—the agent that decides too quickly and the agent that won’t stop trying—are symptoms of the same structural problem. The agent’s objective function is a proxy for yours, not the real thing.

In financial services, where we spend a lot of time at Wangari, this gap between proxy and reality is a known systemic risk. If you incentivize a trader based purely on quarterly returns (the proxy), they will take on hidden tail risks that blow up the fund in year three (the reality). We are currently doing the exact same thing with our software.

When we deploy agents to negotiate contracts, optimize supply chains, or manage cloud infrastructure, we are handing over agency to systems that do not share our risk tolerance. They do not feel the pain of a blown budget. They do not care if a vendor relationship sours. They only care about the mathematical proxy we gave them.

And because they operate at machine speed, the drift happens faster than we can monitor it. You let the agent choose the deployment provider today. Tomorrow, you let it negotiate the enterprise tier. Next month, it’s automatically renewing subscriptions across your entire tech stack based on a “cost optimization” prompt that actually just locks you into longer contracts.

How to Stay in the Loop

The solution is not to turn the agents off. The productivity gains are too massive to ignore, and frankly, I don’t want to go back to reading AWS documentation if I don’t have to. The solution is to change how we define the boundaries of their autonomy.

First, we have to stop treating agents like human employees. You cannot manage an agent through “vibes” or implicit context. You have to manage it through explicit constraints. If you want an agent to optimize a process, you must mathematically define the cost of failure, the budget limit, and the exact conditions under which it must stop and ask for human intervention.

Second, we need to demand better observability from the platforms building these tools. I don’t just want to see the final output; I want to see the decision tree. If an agent recommends a vendor, it should be required to show the three alternatives it discarded and the specific weights it applied to make the choice. Explainability is not just a regulatory requirement; it is a prerequisite for trust.

The Bottom Line

We are entering a phase of technology where the primary skill is no longer execution, but delegation. The people and companies that thrive will not be the ones who write the best code or do the fastest research. They will be the ones who know how to explicitly define their intent, and how to build the guardrails that keep their agents aligned with that intent.

The next time an agent does something perfectly for you, take a moment to ask yourself: what was it actually optimizing for? And are you sure it’s the same thing you wanted?

Meanwhile, at Wangari

Scaling Sustainable Digital Platforms

Together with Bern University, we are conducting academic research on how sustainable digital platforms grow and scale responsibly. If your company embeds environmental or social goals into its core business model, we’d love to speak with you.

The study involves 2–3 short interviews with key employees. Participation is anonymous, confidential, and low time commitment — and you’ll receive early access to our findings.

If this sounds like your company, or if you know someone it might fit, please reach out directly:

• Ari Joury, Cofounder & CEO, Wangari Global — ari.joury@wangari.global

• Melanie Gertschen, PhD Candidate, University of Bern — melanie.gertschen@unibe.ch

Reads of the Week

• The AI Liability Playbook: Monetizing the Silent AI Carve-Out: In this piece for Insurance Intel, the author explores how the insurance industry is grappling with the new liability class forming around enterprise AI deployment. It perfectly complements our discussion on the liability gap, showing how the market is struggling to price risks it doesn’t fully understand.

• The Regulation Is Already Here. Your Program Isn’t Ready. Writing for his eponymous newsletter, argues that cyber compliance has shifted from a checkbox exercise to personal liability for executives. This directly connects to the governance challenges of deploying autonomous agents in regulated environments.

• Who Is Accountable When Your Agent Goes Rogue? In this deep dive for his newsletter, breaks down the accountability vacuum created when AI providers disclaim liability for security flaws in their models. Read this to understand the immediate risks of third-party agent integration.

Earlier this week I made a claim that I want to back up properly: that agentic AI has made causal inference tractable at enterprise scale for the first time. This is not a marketing statement. It is a specific technical argument, and it deserves a specific technical treatment.

In this post, I want to walk through the five stages of deploying a causal model in a production environment, explain why each stage was a bottleneck before the current generation of AI agents, and show concretely what changes when you introduce agents into the pipeline. I will also be honest about what agents cannot do — because the failure modes of this architecture are as important as its strengths.

This is not a tutorial. There is no step-by-step guide to follow. The depth here comes from the reasoning, not from the implementation. If you want to understand why this architecture is different — not just that it is different — this is the post for you.

Background: what causal inference actually requires

Before we can talk about what agents change, we need to be precise about what causal inference requires. The framework I am working with is Judea Pearl’s Structural Causal Model (SCM) approach, which is the dominant formal framework for causal reasoning in statistics and machine learning.

An SCM represents a system as a set of variables and a set of structural equations — one for each variable — that specify how that variable is determined by its causes. The causal structure is represented as a Directed Acyclic Graph (DAG): nodes are variables, directed edges are direct causal relationships. The graph is acyclic because we assume no variable can be its own cause (in the relevant time window).

The key operation in this framework is the do-operator, written do(X = x). This represents an intervention: we set variable X to value x, severing its connection to its usual causes. The do-calculus — a complete set of inference rules developed by Pearl — allows us to compute the effect of such interventions from observational data, given a known causal graph. This is what makes the framework powerful: you can answer “what if we change X?” without ever having run the experiment.

Deploying this in a production environment requires five distinct stages. Each one, historically, has been a serious bottleneck.

Stage 1: Variable selection and domain scoping

The first stage is deciding which variables belong in the model. This sounds straightforward. It is not.

In a financial system, the space of potentially relevant variables is enormous: macroeconomic indicators, firm-level financials, regulatory metrics, ESG scores, market microstructure variables, sentiment signals, and more. Not all of them belong in the causal model. Including too many variables introduces spurious paths and makes the graph unidentifiable. Including too few means missing important confounders and getting biased estimates of causal effects.

The traditional approach is expert workshops: bring together domain specialists — actuaries, risk officers, portfolio managers — and have them argue about which variables matter and why. This process is valuable. It is also slow, expensive, and heavily dependent on who is in the room. A variable that one expert considers obviously relevant may not occur to another.

What agents change here is the breadth of the initial search. An agent can synthesise a large body of domain literature — academic papers, regulatory guidance, industry reports — and propose a candidate variable set with citations. It can identify variables that appear repeatedly in the literature as important drivers of a given outcome, flag variables that are commonly treated as confounders, and surface domain knowledge that might not be in the room. The expert’s job shifts from generating the list from scratch to evaluating and pruning a well-researched proposal. This is faster and less dependent on any single expert’s knowledge.

The caveat is important: agents can propose, but they cannot validate. The final variable set must be approved by domain experts who understand the business context. An agent that has read every paper on ESG and financial performance still does not know which variables are actually available in your data infrastructure, or which ones your compliance team will accept in a regulatory submission.

Stage 2: Causal graph construction

Once you have a variable set, you need to specify the causal structure: which variables cause which, and in which direction. This is the hardest stage, and historically the most expensive.

There are two broad approaches: constraint-based methods (like the PC algorithm, from Spirtes, Glymour, and Scheines) that infer causal structure from conditional independence tests in the data, and score-based methods that search over graph structures to maximise a goodness-of-fit criterion. Both have well-known limitations. Constraint-based methods are sensitive to the faithfulness assumption and to sample size. Score-based methods face a combinatorial search problem that becomes intractable for large variable sets. Neither approach produces a unique graph from observational data alone — the best you can get is a Markov equivalence class of graphs that are statistically indistinguishable.

In practice, this means that automated causal discovery algorithms can narrow the space of plausible graphs, but they cannot determine the final structure without domain input. The direction of edges — which is often the most important thing — frequently cannot be determined from the data alone and must be specified by a domain expert.

What agents change here is the iteration speed. An agent can run multiple causal discovery algorithms, compare their outputs, flag edges where the algorithms disagree, and present the domain expert with a structured set of decisions: “these edges are agreed across all methods; these are contested; these are determined by the data but conflict with the following domain knowledge.” The expert’s job shifts from running algorithms and interpreting raw output to making a set of well-framed decisions. The number of decisions is the same; the cost of each decision is lower.

The failure mode to watch for: agents that present a single “best” graph without surfacing the uncertainty. Causal graphs are not uniquely determined by data. Any system that presents a causal structure as if it were a fact — rather than a hypothesis to be validated — is misrepresenting the epistemics of the problem.

Stage 3: Graph validation and sensitivity testing

A causal graph is a set of assumptions. Every edge is a claim: “this variable directly causes that one.” Every missing edge is also a claim: “these two variables are not directly causally connected, conditional on everything else in the graph.” These claims can be wrong, and the consequences of getting them wrong can be severe.

The standard approach to validation is a combination of domain review (does the graph make sense to experts?) and statistical testing (do the conditional independence relationships implied by the graph hold in the data?). The latter is formalised through the concept of d-separation: a graph implies that certain pairs of variables are conditionally independent given certain other variables, and these implications can be tested.

Sensitivity analysis asks a related question: how much do the causal effect estimates change if we modify the graph — add an edge, reverse a direction, introduce an unmeasured confounder? This is important because the graph is always an approximation of reality, and you want to know which parts of your conclusions are robust to that approximation and which are fragile.

Historically, this stage required a specialist statistician who could run the tests, interpret the results, and translate them back into graph modifications. It was slow and iterative. What agents change is the automation of the test battery: an agent can systematically run all implied conditional independence tests, flag violations, identify which edges are implicated in each violation, and generate a structured report. It can also run systematic sensitivity analyses — varying edge weights, introducing hypothetical confounders, testing the stability of effect estimates — and summarise the results. The statistician’s job shifts from running tests to interpreting a structured diagnostic report.

Stage 4: Interventional query answering

This is the stage where the causal model earns its keep. An interventional query asks: “what is the expected value of outcome Y if we set variable X to value x?” In Pearl’s notation:

This is different from the conditional expectation that a standard regression model estimates:

Computing interventional queries requires applying the do-calculus: a set of three rules that allow you to transform expressions involving the do-operator into expressions that can be computed from the observational distribution, given the causal graph. For simple graphs, this is straightforward. For complex graphs with many variables, multiple intervention targets, and time-series structure, it can require significant algebraic manipulation.

Historically, translating a business question (”what happens to our loss ratio if we change our pricing structure?”) into a formal interventional query, and then computing that query from the causal model, required a specialist who understood both the business context and the mathematical machinery. This was the primary reason that causal inference remained in academic settings: the translation cost was too high.

What agents change here is the translation layer. An agent can take a natural-language business question, identify the relevant variables, formulate the appropriate do-expression, apply the do-calculus to derive an estimable expression, and return the result with a plain-language explanation. The domain expert does not need to know the do-calculus. They need to be able to evaluate whether the agent’s translation of their question is correct — which is a much lower bar.

The failure mode: agents that answer the wrong question confidently. A business question is often ambiguous between a conditional query and an interventional query. “What happens to our loss ratio when ESG scores are high?” could mean “what do we observe in cases where ESG scores happen to be high?” (conditional) or “what would happen if we forced ESG scores to be high?” (interventional). These have different answers. An agent that does not surface this ambiguity — and ask the user to resolve it — is a liability.

Stage 5: Audit trail and documentation

In regulated industries, the output of an analysis is not just the answer. It is the answer plus the full chain of reasoning that produced it. Every modelling assumption, every data transformation, every analytical choice must be documented and defensible.

For causal models, this is particularly demanding. The audit trail must cover: the variable selection rationale, the causal graph structure and the basis for each edge, the validation tests and their results, the specific interventional queries that were run, and the mapping from those queries to the business decisions they informed. In a manual process, this documentation is often incomplete, inconsistent, and produced after the fact.

What agents change here is that the audit trail can be automatic and contemporaneous. Every agent action — every literature search, every algorithm run, every graph modification, every query — is logged with a timestamp, the inputs, the outputs, and the reasoning. The documentation is not a separate task; it is a byproduct of the process. For a regulatory submission or an internal audit, this is not a minor convenience. It is the difference between a defensible analysis and one that cannot be reconstructed.

What this architecture cannot do

I want to be direct about the limitations, because they matter.

Agents cannot determine causal structure from data alone. The direction of causal edges is often underdetermined by observational data, and no amount of computational power changes this. Domain expertise is not optional; it is load-bearing.

Agents cannot validate their own translations. When an agent translates a business question into a formal query, it may translate it incorrectly — and it may do so confidently. The human review step at Stage 4 is not a formality. It is the primary defence against a class of errors that are invisible in the output but consequential in the decision.

Agents are not a substitute for experimental data. The do-calculus allows you to compute interventional effects from observational data under certain assumptions — primarily that the causal graph is correctly specified and that there are no unmeasured confounders. When these assumptions are violated, the estimates can be badly wrong. Agents cannot tell you when the assumptions are violated; only domain knowledge and, ultimately, experimental evidence can do that.

The Bottom Line

The case for this architecture is not that it makes causal inference easy. It doesn’t. The case is that it makes causal inference viable — that it removes the cost barriers that kept a rigorous and well-established methodology out of production for thirty years.

The methodology is not new. The infrastructure is. And the organisations that combine the two — that build systems where agents handle the process layer and domain experts hold the judgment layer — are building something that correlation-based AI cannot replicate: a rigorous, auditable, interventionally valid model of the systems they operate in.

In regulated industries, that is worth building. The window for building it first is open now.

The moment correlation breaks

Correlation-based models are built on an implicit assumption: that the future will look enough like the past that past patterns will hold. This assumption is reasonable in stable conditions. It breaks precisely when you need it most — during structural shifts, regulatory changes, or market disruptions. More fundamentally, it breaks the moment you intervene. When you change your underwriting criteria, restructure a portfolio, or alter your ESG policy, you are not observing the world. You are changing it. A model trained on observation has nothing principled to say about what happens when you act.

This is not a failure of the model. It is a failure of the question. Correlation can tell you what co-occurs. It cannot tell you what will happen if you force something to change. That requires a different kind of reasoning — one that encodes not just patterns, but mechanisms.

What causal models do differently

A causal model does not just learn that two things tend to move together. It encodes the directional mechanism: this variable drives that one, through this pathway, under these conditions. Once you have that structure, you can ask the question that actually matters for decision-making: if we intervene here, what happens there? Not “what tends to happen when X is high?” but “what would happen if we set X to this value — deliberately, right now?”

For an actuary, this is the difference between a model that describes historical loss patterns and one that can tell you what happens to your loss ratio if you change your pricing structure. For an ESG analyst, it is the difference between a model that shows ESG scores correlating with returns and one that can tell you whether improving your sustainability practices will actually improve your financial performance — or whether both are being driven by something else entirely.

The Bottom Line

The methodology to build these models has existed for thirty years. What has changed is the infrastructure to apply it at scale — and that infrastructure is here now. The organisations that make this shift are not just getting better predictions. They are getting answers to questions that correlation-based systems cannot answer at all. In regulated industries, that is not a marginal improvement. It is a different game.

For three decades, a small community of researchers has known something that the rest of the data world is only now beginning to absorb: the most important question you can ask about your data is not “what correlates with what?” It is “what causes what?” The methodology to answer that question rigorously has existed since the early 1990s. The tools to apply it at enterprise scale have not — until now.

This is the story of a thirty-year gap between a scientific breakthrough and its practical arrival. And it is a story that matters enormously for anyone in financial services who is trying to build AI systems they can actually trust.

The problem with correlation

Correlation is the workhorse of modern data analysis. It is fast, scalable, and surprisingly powerful. When you train a model on historical data and ask it to predict future outcomes, you are essentially asking it to find and exploit correlations — patterns that held in the past and might hold in the future. This works well enough in stable conditions. It fails, often silently, when conditions change.

The deeper problem is that correlation cannot answer the question that actually matters in many regulated industries: what happens if we intervene? If you change your underwriting criteria, restructure a portfolio, or shift your ESG policy — you are not observing the world, you are changing it. A correlation-based model has nothing principled to say about what happens next. It can only extrapolate from the past. So if unprecedented conditions occur, it’s flummoxed: It was trained on a world where things co-occurred; it has no mechanism for reasoning about a world you have deliberately altered in previously unseen ways.

This is not a data quality problem. It is not a model size problem. It is a fundamental limitation of correlation as a mode of reasoning. And it is why industry professionals like actuaries, risk officers, and investment analysts have always maintained a healthy scepticism toward purely statistical models — even when they perhaps could not always articulate exactly why.

What causal inference actually does

Causal inference, in the technical sense developed by Judea Pearl and colleagues, is a framework for reasoning about interventions. Instead of asking “what tends to happen when X is high?”, it asks “what would happen if we set X to a specific value — holding everything else constant?” The two questions sound similar. They have very different answers, and they require very different mathematics.

The key tool is the Structural Causal Model: a formal representation of a system as a set of variables and the directional mechanisms that connect them. Not just correlations, but causes. The model encodes which variables drive which outcomes, through which pathways, and with what structure. Once you have that model, you can answer interventional questions directly — not by extrapolating from historical patterns, but by reasoning through the causal structure of the system.

For industry and financial services, this matters in ways that are immediately practical. A model of a manufacturing plant that’s built on causal structure can tell you whether improving your sustainability practices will actually improve your financial performance — or whether both are driven by a third factor, like management quality or regulatory environment. A risk model built on causal structure can tell you which interventions will actually reduce tail risk — not just which variables happen to be correlated with it. These are the questions that senior decision-makers are actually asking. Correlation-based models cannot answer them.

Why it took thirty years

If the methodology was ready in the 1990s, why are we only now seeing it arrive in enterprise software? The honest answer is that applying causal inference at scale has always required an enormous amount of expert labor.

Building a causal model is not like training a neural network. You cannot simply feed it data and let it find patterns. You need to specify the causal structure of the system — which variables are causes, which are effects, which are confounders. This requires domain expertise, iterative validation, and careful reasoning about the mechanisms at play.

For a complex system with dozens of interacting variables, this process could take weeks of expert workshops. And that was before you got to the question of how to translate the resulting model into answers to specific business questions.

The bottleneck was never the mathematics. It was the cost of applying the mathematics to real-world problems. Causal inference was tractable in academic settings, where a team of specialists could spend months on a single model. It was not tractable in enterprise settings, where you need answers in days, not months, and where the domain experts who could validate the causal structure are also the people running the business.

What changed: AI agents, of course

The emergence of capable AI agents has changed this equation in a way that is genuinely new. Tasks that previously required weeks of expert time — synthesising domain literature to identify candidate variables, proposing and testing causal graph structures, running systematic validation checks, translating business questions into formal interventional queries — can now be completed in hours. The methodology has not changed. The infrastructure for applying it at scale has.

This is not the same as saying that AI agents can replace domain expertise. They cannot, and they should not. The judgment layer — validating the causal structure against real-world knowledge, deciding which interventions are worth modelling, interpreting results in context — remains human. What agents automate is the process layer: the high-volume, well-defined, error-prone work that was consuming most of the expert’s time without requiring most of the expert’s judgment.

The combination of mature causal methodology and modern agentic AI infrastructure is genuinely new. It is not a marginal improvement on existing approaches. It is a different class of tool — one that can answer questions that correlation-based systems cannot, at a cost that is now commercially viable for the first time.

The Bottom Line

The organisations that build causal AI capabilities now are not just getting better analytics. They are building a fundamentally different relationship with their data — one where the question “why?” has a rigorous, auditable answer, not just a plausible-sounding one. In regulated industries, where the cost of a wrong answer is measured in capital requirements, regulatory penalties, and reputational damage, that difference is not academic. It is the whole game.

The methodology has been ready for thirty years. The infrastructure just caught up.

The window for first-mover advantage is open. It will not stay open.

Reads of the Week

• The problem with agentic AI in 2025: In this essay, argues that most organisations are treating agentic AI as a faster version of robotic process automation — and missing the point entirely. His central claim is that the real value of agents is not in executing workflows more cheaply, but in eliminating the logic of workflows altogether, and that governance — not execution speed — is the primary performance driver of a well-designed agentic system. Directly relevant to anyone thinking about how AI agents should be deployed in regulated, high-stakes environments.

• Correlation vs. Causation: Why It Matters for Investors: ’s take makes the core argument with unusual clarity: correlation describes a pattern, but without a causal anchor, even robust-looking relationships can collapse the moment conditions change. The 2022 equity-bond drawdown is the worked example — a correlation that held for two decades, built on a conditional relationship that most practitioners had mistaken for a structural one. A useful complement to this week’s post, written for a portfolio construction audience rather than a technical one.

• Causation Does Not Imply Variation: offers a useful corrective to the other direction: just because you have identified a causal effect does not mean it explains much of the variation in the outcome you care about. Cochrane’s argument — that the causality revolution in econometrics has produced many well-identified but tiny effects, and that practitioners often jump from “this causes that” to “this explains that” without stopping to think — is an important caveat for anyone building causal models in production. Read it as a reminder that causal inference is a tool for answering specific questions, not a general-purpose explanation of the world.

The transition from conversational AI to agentic AI is not merely a change in user interface; it is a fundamental architectural shift. For the past two years, the dominant paradigm has been the stateless, prompt-response loop. A user provides a prompt, the Large Language Model (LLM) generates a response, and the interaction ends. The system’s “memory” is limited to the context window of the current session.

Agentic frameworks like OpenClaw and NanoClaw break this paradigm. They introduce persistent memory, autonomous task planning, and the ability to execute actions across external systems. This shift from passive generation to active execution introduces profound new challenges in system architecture, state management, and security.

In this deep dive, we will examine the mechanics of the “Agent Loop,” explore how memory and context are managed without traditional databases, and analyze the architectural trade-offs between monolithic agent frameworks (OpenClaw) and lightweight, isolated approaches (NanoClaw).

The Anatomy of the Agent Loop

At the core of any autonomous agent is the Agent Loop—a continuous cycle of observation, reasoning, and action. Unlike a standard LLM call, which is a single forward pass through the network, the Agent Loop is iterative and stateful.

When a message or trigger arrives, the agent does not immediately generate a final response. Instead, it enters a reasoning phase. It assembles context from its environment, including conversation history, workspace files, and available tools. It then queries the LLM not for an answer, but for a plan.

The LLM, acting as the reasoning engine, evaluates the context and determines the next necessary step. If the task requires external data or action, the LLM outputs a tool call (e.g., a JSON object specifying an API endpoint and parameters). The agent framework intercepts this tool call, executes the action (e.g., querying a database, sending an email), and appends the result to the context.

This loop repeats—often up to 20 times per request in frameworks like OpenClaw—until the LLM determines that the objective has been met and generates a final response to the user.

This iterative process is what enables agents to handle complex, multi-step workflows. However, it also introduces significant latency and cost, as each step requires a separate LLM inference call. More importantly, it creates a massive attack surface. If the LLM’s reasoning is compromised—for example, through a prompt injection attack hidden in a retrieved document—the agent may execute malicious tool calls with its delegated authority.

State Management Without Databases

One of the most fascinating architectural choices in OpenClaw is its approach to state management. Traditional enterprise applications rely on relational or NoSQL databases to manage state and persist data. OpenClaw, by default, eschews this approach in favor of plain text Markdown files.

In the OpenClaw architecture, everything from the agent’s core instructions (AGENTS.md) to its personality (SOUL.md) and long-term memory (MEMORY.md) is stored as Markdown in a local workspace directory.

This design choice has several profound implications:

1. Transparency and Version Control: Because the entire state of the agent is represented as plain text, it can be easily inspected, audited, and version-controlled using standard tools like Git. Developers can see exactly what the agent “knows” at any given time.

2. Context Injection: When the agent needs to recall past interactions, it doesn’t query a database. Instead, it uses a local SQLite database with vector embeddings to perform semantic search across its Markdown files, injecting the relevant text directly into the LLM’s context window.

3. Concurrency Challenges: Relying on file system operations for state management introduces significant concurrency issues. If multiple asynchronous processes attempt to update the agent’s memory simultaneously, race conditions and file corruption can occur. OpenClaw mitigates this by serializing the agent loop per session—processing one task at a time, in order.

While this file-based approach is elegant in its simplicity, it scales poorly in multi-tenant enterprise environments where high throughput and robust transaction management are required.

The Monolith vs. The Micro-VM: OpenClaw and NanoClaw

As the security implications of autonomous agents have become apparent, the architectural debate has centered on isolation. How do we prevent an agent from exceeding its intended scope?

OpenClaw represents the monolithic approach. It is a sprawling framework with hundreds of thousands of lines of code, designed to manage multiple messaging platforms, tool integrations, and agent sessions within a single Node.js process (the Gateway). Security in OpenClaw is primarily handled at the application level, relying on internal rules and permissions to restrict agent behavior.

This monolithic design is powerful and extensible, but it is also fragile. A vulnerability in any one of its dependencies or integrations can compromise the entire Gateway, granting an attacker access to all active agent sessions and their associated credentials.

NanoClaw emerged as a direct response to this fragility. It adopts a fundamentally different architectural philosophy: OS-level isolation.

Instead of running all agents within a single process, NanoClaw runs each agent in its own isolated container (using Docker or Apple Containers). The codebase is intentionally minimalist—often under 5,000 lines—reducing the attack surface and making security audits practical.

If a NanoClaw agent is compromised via prompt injection or a malicious tool, the blast radius is confined to that specific container. The attacker cannot pivot to the host operating system or access the memory of other agents.

The Limits of Containerization

While NanoClaw’s containerized approach provides robust protection against host compromise, it is crucial to understand its limitations. Containerization solves the problem of system security, but it does not solve the problem of identity security.

Consider an agent deployed within a NanoClaw container and granted an OAuth token to access a corporate CRM system. The container prevents the agent from reading the host’s /etc/passwd file, but it does nothing to prevent the agent from deleting every record in the CRM if it is manipulated into doing so.

The agent is operating exactly as designed, using the legitimate credentials it was provided. The container is intact, but the enterprise data is gone.

This highlights the core architectural challenge of agentic AI: we must move beyond securing the execution environment and begin securing the actions themselves.

Building Verifiable AI Agents

To safely deploy autonomous agents in enterprise environments, developers must adopt a defense-in-depth architecture that addresses both system isolation and identity governance.

1. Explicit Identity Boundaries: Every agent must be treated as a distinct Non-Human Identity (NHI) with its own ephemeral credentials. Long-lived API keys and broad OAuth scopes must be deprecated in favor of just-in-time, least-privilege access tokens.

2. Verifiable Decision Paths: The Agent Loop must be instrumented to provide a verifiable audit trail of its reasoning. It is not enough to log the tool calls an agent makes; we must log the context and the LLM outputs that justified those calls. This allows security teams to reconstruct the agent’s “intent” during an incident investigation.

3. Semantic Circuit Breakers: We cannot rely solely on the LLM to police its own behavior. Agent architectures must incorporate deterministic, semantic circuit breakers—independent validation layers that inspect proposed tool calls before they are executed. If an agent attempts an action that violates predefined safety invariants (e.g., transferring funds above a certain threshold, modifying production infrastructure), the circuit breaker must halt execution and require human intervention.

# Example: A conceptual semantic circuit breaker
def execute_tool_call(agent_intent, proposed_action, context):
    # 1. Validate the action against deterministic safety invariants
    if not is_action_safe(proposed_action):
        raise SecurityException("Action violates safety invariants.")
    
    # 2. Verify the action aligns with the agent's authorized scope
    if not is_action_authorized(agent_intent, proposed_action, context):
        request_human_approval(agent_intent, proposed_action)
        return
        
    # 3. Execute the action
    return perform_action(proposed_action)

The Bottom Line

The shift to agentic AI requires a fundamental rethinking of enterprise architecture. We are moving from systems that process data to systems that make decisions and take actions.

While lightweight, containerized frameworks like NanoClaw offer significant improvements over monolithic designs, they are only part of the solution. True security in the agentic era requires us to govern the identity and the actions of the software itself. We must build systems that are not just isolated, but verifiable, ensuring that autonomy always operates within clearly defined and strictly enforced boundaries.

I’m Launching a Course!

So many AI projects die. And that’s not the fault of the tech nerds: They built the demo, and it worked. Still, 90% (yes, really) of all AI models never make it into production. So let’s dig deep into the big organizational underbellies, and let’s find out how we can make those numbers a bit better.

That’s the challenge I’ll be tackling in a new course starting April 21 at GenAI Academy, where we walk through how to actually move an agentic AI system from demo to production — including the organizational architecture required to make it work. This is for technical leaders, senior engineers, product managers, and AI/ML team leads. If you haven’t joined yet, it’s not too late to sign up!

I’m really excited to be able to bring what I’ve seen from the inside and outside to you in this format. You’ll experience me teaching live over 6 weeks! You’ll find all the details here: From Demo to Production.

For a brief moment, it felt like magic. Then, the reality of enterprise security set in.

As the hype around autonomous agents like OpenClaw grows, a counter-narrative has emerged: the promise of the “secure, local agent.” Tools like NanoClaw are being pitched as the safe alternative for enterprises. Their core value proposition is isolation. By running each agent in its own container—a secure, OS-level sandbox—they promise to keep the agent from breaking out and wreaking havoc on your host system.

It’s a compelling pitch. It’s also dangerously incomplete.

The Container Fallacy

The problem with focusing on containerization is that it solves the wrong problem. Yes, putting an agent in a secure box prevents it from directly attacking the server it runs on. But the real risk of an autonomous agent isn’t that it will escape its box. The real risk is what it does with the permissions you gave it.

If you give an agent access to your CRM, your email server, and your financial databases so it can “prepare the weekly sales update,” it doesn’t matter how secure its local container is. The agent now holds the keys to your enterprise.

If that agent is manipulated via a prompt injection attack, or if it simply hallucinates a destructive command, it will execute that command using the legitimate, authorized access you provided. The logs will show that an authorized account performed the action. The container will have done its job perfectly, isolating the agent while the agent systematically dismantles your data integrity.

Identity is the New Perimeter

We are still trying to apply legacy security concepts to a fundamentally new paradigm. We think of security as a perimeter—a wall around our applications or a container around our agents. But when software acts with delegated authority across multiple systems, the perimeter dissolves.

In the era of autonomous AI, identity is the new perimeter.

The challenge isn’t keeping the agent in a box; it’s governing the agent’s identity. We need to treat every AI agent as a distinct Non-Human Identity (NHI) with its own credentials, its own strictly scoped permissions, and its own audit logs. We need systems that can monitor not just what an agent is doing, but why it is doing it, enforcing circuit breakers that require human intervention for high-stakes operations.

The Bottom Line

Containerizing an AI agent is like putting a bank robber in a vault and handing them the combination. The vault is secure, but the assets are still gone. True enterprise security for autonomous agents requires a fundamental shift from isolating the software to governing its identity and its actions. Until we build architectures that can manage non-human identities at scale, the “secure local agent” will remain an illusion.

I’m Launching a Course!

So many AI projects die. And that’s not the fault of the tech nerds: They built the demo, and it worked. Still, 90% (yes, really) of all AI models never make it into production. So let’s dig deep into the big organizational underbellies, and let’s find out how we can make those numbers a bit better.

That’s the challenge I’ll be tackling in a new course starting April 21 at GenAI Academy, where we walk through how to actually move an agentic AI system from demo to production — including the organizational architecture required to make it work. This is for technical leaders, senior engineers, product managers, and AI/ML team leads.

I’m really excited to be able to bring what I’ve seen from the inside and outside to you in this format. You’ll experience me teaching live over 6 weeks! You’ll find all the details here: From Demo to Production. It’s not too late to sign up — recordings of previous sessions are available to all participants.

I remember the exact moment I realized the chatbot era was over. It wasn’t a grand announcement or a glossy keynote. It was a quiet Tuesday afternoon when a colleague showed me a terminal window running a new open-source tool called OpenClaw. They didn’t type a prompt asking for a summary or a polite email draft. They typed: “Prepare the weekly sales update.”

What happened next was fundamentally different from anything I had seen before. The system didn’t just generate text. It broke the objective into steps. It went even past the Claude tricks that had blown my mind so much. This thing pulled data from an internal CRM, structured the information, validated the outputs against historical records, and drafted an email to stakeholders. It didn’t just advise; it did the thing. It acted with delegated authority across multiple systems, without a single human click in between.

For a brief moment, it felt like magic. Then, the reality of enterprise security set in, and the magic quickly turned into a cold sweat.

If one software agent touches five different systems, does it carry one identity or many? Who approves its access? How is its activity logged and reviewed? And most importantly, what defines acceptable behavior when the agent itself decides the next step?

We are witnessing a paradigm shift in financial services and enterprise operations. We are moving from AI as a passive assistant to AI as an autonomous agent. And as tools like OpenClaw gain traction, they are exposing the fragility of our current enterprise identity models.

The Illusion of the Human-Initiated Workflow

For decades, enterprise security has been built on a single, foundational assumption: humans initiate actions. Our entire architecture—from single sign-on (SSO) to role-based access control (RBAC)—is designed around the idea that a person logs in, requests access to a resource, performs a task, and logs out. Permissions are scoped to the individual’s role, and audit logs trace actions back to a human intent.

Autonomous agents break this model entirely.

OpenClaw and its enterprise equivalents don’t wait for a human to click a button. They operate continuously, grinding through long, multistep workflows. They inherit permissions, often broadly scoped, and use them to navigate across collaboration tools, internal applications, and external services. They sit between systems, moving data and triggering actions in ways that traditional security tools simply cannot see.

When an agent acts independently, the concept of “intent” becomes incredibly difficult to reconstruct. If an agent hallucinates or is manipulated via a prompt injection attack, it might execute a series of unauthorized actions—like attempting a crypto transaction or exfiltrating sensitive data—at machine speed. The logs will show that the actions were performed by an authorized account, but they won’t explain why.

The Engine Room vs. The Front Door

The problem isn’t that we lack security tools; it’s that our tools are looking in the wrong place.

Most enterprise security stacks are designed to monitor the “front door”—application configurations, user login events, and permission settings. This made sense when risk lived inside discrete systems. But the attack surface has moved.

The real risk now lies in the “engine room”—the runtime layer where AI agents move sensitive data between systems, where OAuth tokens grant persistent cross-platform access, and where a single compromised integration can cascade silently across an entire supply chain.

Recent data paints a stark picture: A 2026 survey of 500 U.S. enterprise CISOs revealed that 99.4% of organizations experienced at least one SaaS or AI ecosystem security incident in the previous year. Despite running an average of 13 dedicated security tools, nearly a third of these organizations experienced unauthorized data exfiltration through SaaS-to-AI integrations.

Our legacy tools are blind to API-to-API data flows and cross-app data movement. They audit which permissions exist, but they cannot see what an agent actually does with those permissions at runtime.

The Wake-Up Call for Financial Services

For professionals in banking, insurance, and asset management, this shift is particularly acute. We operate in highly regulated environments where strict access controls and human-in-the-loop approvals are not just best practices; they are legal requirements.

The promise of agentic AI in financial services is immense. Imagine an Account Servicing Agent that instantly handles profile updates and document fulfillment, or a Dispute Resolution Agent that automatically classifies cases and gathers evidence [2]. These tools can drastically reduce manual handling and improve customer service.

But the risks are equally profound. If an autonomous agent is granted broad access to customer financial data and internal transaction systems, a single vulnerability could lead to catastrophic consequences. We cannot simply deploy these agents and hope our existing security posture will hold.

The Bottom Line

The era of autonomous AI agents is here, and it is not waiting for our security models to catch up. Tools like OpenClaw have made it clear that the value of cross-system automation is too great for enterprises to ignore.

But we must recognize that agent security is, fundamentally, identity security. We need to move beyond the illusion of the human-initiated workflow and build architectures that can govern non-human identities at scale. We need explicit identity boundaries, configurable controls for agent behavior, and real-time visibility into decision paths.

The advantage in the coming years will not belong to the organizations that deploy the most agents. It will belong to those that figure out how to deploy them safely.

I’m Launching a Course!

So many AI projects die. And that’s not the fault of the tech nerds: They built the demo, and it worked. Still, 90% (yes, really) of all AI models never make it into production. So let’s dig deep into the big organizational underbellies, and let’s find out how we can make those numbers a bit better.

That’s the challenge I’ll be tackling in a new course starting April 21 (today!) at GenAI Academy, where we walk through how to actually move an agentic AI system from demo to production — including the organizational architecture required to make it work. This is for technical leaders, senior engineers, product managers, and AI/ML team leads. It’s not too late to sign up — and your company might have the budget to cover the course expense.

I’m really excited to be able to bring what I’ve seen from the inside and outside to you in this format. You’ll experience me teaching live over 6 weeks! You’ll find all the details here: From Demo to Production.

Reads of the Week

• The Agentic Ecosystem Security Gap: In this deep dive for Agentic AI, breaks down a startling report revealing that 99.4% of surveyed enterprises experienced a SaaS or AI security incident last year. He argues that current security tools are blind to the “engine room” where AI agents operate across systems, a critical blind spot for financial institutions relying on legacy identity models. If you want to understand why your current security stack won’t protect you from autonomous agents, read this.

• In this piece for Cashless: Fintech, CBDC and AI at the speed of Asia, explores the harsh reality of AI agent deployment in the banking sector, arguing that executives will bypass assistive AI in favor of autonomous agents to cut costs. He connects the theoretical capabilities of agents to concrete banking roles, from customer consultation to dispute resolution. Your Banking Job and AI Agents is a sobering look at the immediate impact of autonomy on the financial workforce.

• A structural transformation is necessary to secure AI-native operations, argues in The 6 security shifts AI teams can’t ignore in 2026. He explains how the shift to agentic systems creates vulnerabilities like “goal hijacking” and demands a Zero Trust strategy that treats every agent as a distinct identity. This is essential reading for anyone tasked with integrating AI agents into enterprise access management frameworks (including myself).

For decades, programming, physics, math, and engineering allowed people to live mostly in logical space. If you were analytical, introverted, neurodivergent, or simply uncomfortable with the messy dynamics of human interaction, the computer became a stable partner. It was a refuge.

I know this from personal experience. My path through particle physics and then into AI and data science was, in part, a path toward a world that made sense. A world where the rules were clear, the feedback was objective, and the right answer was always, in principle, discoverable. The computer did not have bad days. It did not misread your tone. It did not hold grudges.

But that world is disappearing. And the shift is more profound than most technical professionals have yet fully reckoned with.

The Nerd Refuge: Why It Existed

The appeal of technical fields to analytical and introverted people was not accidental. It was structural. Old computers were deterministic. You wrote a function, and it executed in exactly the same way every time. If it failed, the failure had a cause, and that cause was traceable. The feedback loop was immediate, objective, and, crucially, free of social judgment.

This attracted people who were uncomfortable with ambiguity. People who found the social dynamics of human interaction exhausting or unpredictable. People who wanted to be evaluated on the quality of their reasoning, not on their ability to navigate office politics or read a room.

The result was a culture. Engineering departments, physics labs, and quantitative finance desks became places where a certain kind of person could thrive. The brilliant but socially awkward developer. The quant who hates meetings. The engineer who only wants Jira tickets. These archetypes were not just personality quirks; they were adaptations to an environment that rewarded a specific kind of intelligence.

AI Changes the Nature of Computers

New computers are probabilistic. They are contextual. They are conversational. We now interact with machines much like we interact with people. When you prompt a large language model, you are not executing a command; you are guiding a conversation. The output is not guaranteed to be identical every time. It depends on the context, the phrasing, and the underlying probability distributions of the model’s training.

This shift is not merely technical. It is epistemological. The old model of computation was based on the idea that a machine could be fully specified. You could, in principle, trace every output back to every input. The new model is based on the idea that a machine learns patterns from data and generates responses that are statistically likely, not logically certain.

This has profound implications for how we build and evaluate AI systems. You cannot simply read the code to understand why a model behaves the way it does. You have to observe it, test it, and interpret its outputs in context. You have to develop intuitions about its failure modes and edge cases. You have to think probabilistically, not deterministically.

The Irony of Human Complexity in Technical Work

The irony is that the more human computers become, the more technical work involves judgment, ambiguity, and interpretation. In other words, it involves human complexity.

Consider the process of building an AI agent. You are no longer just writing code to perform a specific task. You are designing a system that must interpret intent, handle edge cases gracefully, and make decisions based on incomplete information. You must think about how the system will behave when a user asks it something unexpected. You must anticipate the ways in which the system’s outputs might be misinterpreted or misused.

This requires a level of empathy and systemic understanding that was previously the domain of product managers and designers. The technical professional must now bridge the gap between the deterministic world of traditional software and the probabilistic world of AI. They must understand not just how to build the system, but how the system will behave in the wild, interacting with unpredictable human users in unpredictable contexts.

The bottleneck in technical work has shifted. It is no longer about writing the code. It is about problem definition, system design, and evaluation. It is about the human coordination required to turn a working demo into a reliable system inside an organization.

Robotics Won’t Save Us

You might think that robotics offers a remaining refuge of purely mechanical engineering. The physical world, at least, is deterministic. A robot arm that picks up a component either succeeds or fails. The physics is clear.

But even robotics is becoming AI-driven, software-mediated, and model-dependent. The physical world is being abstracted into data, and the machines that navigate it are increasingly relying on the same probabilistic models that power conversational AI. Modern robotic systems use deep learning for perception, reinforcement learning for control, and large language models for task planning. The boundary between the physical and the digital is blurring, and the skills required to navigate both are converging.

The refuge of purely mechanical engineering is shrinking. Even in the most hardware-adjacent domains, the work is increasingly about designing systems that learn, adapt, and make decisions under uncertainty.

What This Means for Nerd Culture

This shift presents three possible futures for nerd culture and the technical professions.

The first is retreat. Some technical professionals will seek out the remaining pockets of purely deterministic work. Low-level systems programming, theoretical mathematics, formal verification—these are areas where the old rules still apply. This is a legitimate path, but it is a narrowing one. The frontier of technical work is moving rapidly away from pure determinism.

The second is resistance. Some will cling to the old ways of working, arguing that AI is a fad or that it cannot replace the rigor of traditional engineering. This is understandable, but it is ultimately a losing position. The tools are changing, and the organizations that do not adapt will be left behind.

The third is evolution. Some will embrace the ambiguity and complexity of the new landscape. They will learn to design systems that integrate human and machine intelligence, leveraging the strengths of both. They will develop new skills—communication, empathy, strategic thinking—not because they have abandoned their technical identity, but because they have expanded it.

This third group will dominate the future of technical work.

The Evolution of the Technical Professional

The evolution into systems thinkers requires a fundamental shift in mindset. It means moving away from a focus on individual components and towards a holistic understanding of the entire system. It means recognizing that the technical architecture is inextricably linked to the organizational architecture.

This is not an easy transition. It requires developing new skills, such as communication, empathy, and strategic thinking. It requires learning to navigate the messy, ambiguous world of human interaction that many technical professionals initially sought to avoid. It requires tolerating uncertainty and making decisions with incomplete information.

But it is a necessary transition. And it is worth noting that many of the skills that technical professionals have developed—rigorous thinking, attention to detail, the ability to decompose complex problems—are highly transferable to this new landscape. The challenge is not to abandon these skills, but to apply them in a broader context.

The organizations that succeed in the AI era will be the ones that can effectively integrate human and machine intelligence. And that requires technical professionals who can bridge the gap between the two. Not everyone has to become a communicator. But the interface between humans and machines must be owned by someone who understands both sides.

The Bottom Line

For decades, nerds escaped into machines because machines were simpler than humans. Now the machines are learning to talk back. The refuge of pure logic is disappearing, replaced by a new landscape of probabilistic complexity.

The challenge for technical professionals is not to resist this change, but to embrace it. The skills that made you valuable in the old world—rigorous thinking, deep focus, the ability to decompose complex problems—are still valuable. But they need to be applied in a broader context, one that includes the messy, ambiguous reality of human organizations and probabilistic AI systems.

The best technical professionals of the next decade will be those who can design systems, think clearly, and bridge the gap between humans and machines. Not because they have abandoned their technical identity, but because they have expanded it to meet the demands of a new era.

I’m Launching a Course!

So many AI projects die. And that’s not the fault of the tech nerds: They built the demo, and it worked. Still, 90% (yes, really) of all AI models never make it into production. So let’s dig deep into the big organizational underbellies, and let’s find out how we can make those numbers a bit better.

That’s the challenge I’ll be tackling in a new course starting April 21 at GenAI Academy, where we walk through how to actually move an agentic AI system from demo to production — including the organizational architecture required to make it work. This is for technical leaders, senior engineers, product managers, and AI/ML team leads.

I’m really excited to be able to bring what I’ve seen from the inside and outside to you in this format. You’ll experience me teaching live over 6 weeks! You’ll find all the details here: From Demo to Production.