The Self-Improving Agent Fleet

All views expressed here are my own and do not represent the views of my employer.

In my previous piece, I walked through the seven-layer architecture of the personal trading app I've been building - from the event substrate to the observability layer. The response was generous, and several people asked the same question: does the system actually get better over time, or is it static once deployed?

It's a fair question. Most multi-agent systems today are static. You build agents, tune their prompts, deploy them, and hope the world doesn't change enough to break your assumptions. When it does - and it always does - you manually investigate, manually retune, and manually redeploy. The agents don't learn. They just execute.

The personal trading app I've been building takes a different approach. It has a self-improvement layer that closes the loop between outcomes and future behavior. When a trade closes, the system doesn't just record whether it won or lost. It traces which signals influenced the decision, updates a causal model of what actually predicts outcomes, runs forward simulations against that model before taking future actions, and continuously experiments with strategy variants - promoting winners and retiring losers through statistically rigorous A/B testing.

This piece is about how that self-improvement loop works, why it matters beyond trading, and what I've learned about building agent systems that get measurably smarter rather than gradually stale.

Why static agents decay

Before getting into the mechanics, it's worth understanding why static agent systems degrade. The intuition is that once an agent is working well, it should keep working well. In practice, three forces conspire against this.

Distribution drift. The data your agents were tuned on changes. Market regimes shift. Customer behavior evolves. Regulatory requirements update. An agent optimized for a low-volatility environment will make bad decisions in a high-volatility one - not because it's broken, but because the world it was designed for no longer exists.

Signal decay. The signals your agents rely on lose their predictive power over time. A technical pattern that was reliable for six months gets arbitraged away. A sentiment signal that correlated with outcomes last quarter doesn't this quarter. If nobody is measuring which signals are still working, the system silently degrades.

Strategy staleness. Even when individual signals are fine, the strategy that combines them might be suboptimal. A conservative strategy that worked during uncertain markets becomes a drag during trending markets. Without a mechanism to experiment with alternatives, the system is locked into whatever worked at deployment time.

The traditional response to all three is human intervention. An analyst reviews performance, identifies the drift, and manually adjusts. That works when you have five agents. It doesn't scale when you have fifty, each operating in a domain the analyst may not fully understand. The self-improvement loop is what makes agent fleets operationally sustainable at scale.

The three components of self-improvement

The improvement loop in my personal trading app has three distinct components, each solving a different problem. They work together but are independently valuable.

1. Causal attribution - learning what actually matters

When a trade closes, the system doesn't just record win or loss. The outcome analyzer captures the complete signal snapshot that influenced the decision - which analyst signals were active, what the scorers produced, what the consensus looked like, what the simulation predicted. This creates a structured record: given these inputs, we got this outcome.

A causal attribution engine takes these records and builds a Bayesian graph of signal-to-outcome relationships. Over time, this graph reveals which signal types actually predict outcomes versus which ones are noise. Maybe fundamental analysis is strongly predictive for large-cap earnings plays but nearly useless for momentum trades. Maybe sentiment signals have high predictive power in the first hour after news breaks but decay rapidly. Maybe the historical pattern scorer is the most reliable overall but underperforms during regime transitions.

The key insight is that this attribution is continuous, not a one-time analysis. The graph updates with every closed trade, using Bayesian smoothing to balance recent evidence against the historical base. Signals that lose their predictive power see their attribution scores decline automatically. Signals that gain predictive power in new conditions see their scores rise. Nobody has to manually investigate why performance changed - the causal graph tells you.

2. Forward simulation - testing before committing

The causal graph doesn't just explain the past. It powers a simulation runner that scores candidate actions before the system commits to them.

When the consensus engine produces a trade proposal, the simulation runner takes the current signal state and the causal graph and runs Monte Carlo forward projections. It asks: given the signals we see right now, and given what we know about which signals actually predict outcomes, what's the distribution of likely results for this trade?

The output is a simulation score that feeds directly into position sizing. If the simulation shows a win probability above 0.65, the position sizer increases the allocation by up to 50%. If the win probability is below 0.45, it reduces by 30%. The system isn't just deciding whether to trade - it's calibrating how much to risk based on its own track record in similar situations.

This is where the causal graph pays off operationally. A system without causal attribution would run simulations based on raw signal correlations - which decay, mislead, and overfit. The causal graph gives the simulation runner a model that's continuously updated and explicitly tracks which relationships are strengthening versus weakening.

3. Strategy evolution - controlled experiments at runtime

The third component is the one that surprised me most in practice. The system doesn't just optimize within a fixed strategy. It continuously experiments with strategy variants and promotes winners through statistically rigorous A/B testing.

Here's how it works. A strategy tracker records which strategy variant was active at each trade - including the specific parameters (signal weights, scoring thresholds, consensus quorum settings). The strategy evolution engine maintains multiple variants simultaneously, allocating a configurable percentage of decisions to each variant.

After enough trades accumulate per variant, the evolution engine evaluates comparative performance. But it doesn't just pick the variant with the highest win rate. It runs a statistical significance test to ensure the performance difference isn't attributable to luck or market conditions. Only when a variant demonstrates sustained, statistically significant outperformance does the engine trigger a promotion - and even then, a human must approve the strategy change before it takes effect in the primary allocation.

The human-approval gate is critical here. Fully automated strategy evolution creates a risk of overfitting to recent market conditions. The evolution engine surfaces the evidence - "Variant B has outperformed Variant A by 8 percentage points over 400 paper trades with p-value 0.03" - but a human decides whether to promote. Sometimes the right decision is to wait for more data. Sometimes the performance difference reflects a market regime that's about to end. The system provides the analysis; the human provides the judgment.

The complete feedback loop

The three components work together as a closed loop. Click through each stage to see how a single trade outcome flows through the entire self-improvement cycle:

What this means beyond trading

The self-improvement loop isn't specific to financial markets. It applies to any domain where agents make decisions and receive outcome feedback.

In a CRM system, the same pattern would track which engagement signals actually predict deal closure, which sales strategies outperform in different segments, and which forecasting models are most accurate over time. The causal graph would reveal that email response time predicts closure for mid-market deals but not enterprise deals. The strategy evolution engine would A/B test different outreach cadences and promote winners.

In fraud detection, the loop would track which signal combinations actually predict confirmed fraud versus false positives. The causal graph would show which detection patterns are losing their edge as fraudsters adapt. The simulation runner would score new detection rules against historical outcomes before deploying them live.

In supply chain optimization, outcome feedback from delivery times, stockout rates, and cost overruns would feed the causal graph. The system would learn which demand signals actually predict inventory needs versus which ones are noise. Strategy evolution would experiment with different reorder thresholds and safety stock levels.

The common thread is that the improvement loop turns operational data into operational intelligence - automatically, continuously, and with statistical rigor rather than gut feel.

What I've learned building this

Three things surprised me in practice that I wouldn't have predicted from the architecture alone.

Signal decay is faster than expected. Signals that looked strong in the first 100 paper trades often lost their predictive power by trade 500. Without the causal graph tracking this continuously, I would have been trading on stale signals for months. The graph caught decay that my manual review process would have missed entirely.

The human gate on strategy promotion is essential, not optional. I initially planned to automate strategy promotion entirely. In practice, the evolution engine occasionally identifies a "winning" variant that's actually exploiting a temporary market condition. A human reviewing the promotion evidence catches these cases. The system proposes; the human disposes. I've come to think of this as the earned autonomy principle applied to the meta-level - the improvement loop itself should earn trust before being given full autonomy.

Memory-aware rollback matters more than I expected. When a multi-step trade saga rolls back - say, the broker rejects an order after consensus approved it - the agent's procedural memory needs to revert too. Otherwise the agent "learned" from an outcome that never actually happened. This is a subtle form of training drift that's invisible unless you're specifically looking for it. The cognitive transaction layer handles this automatically, but I wouldn't have prioritized building it without hitting the problem in practice.

The architecture of continuous improvement

If I step back from the trading specifics, the pattern is this: any multi-agent system that makes decisions and receives outcomes has the raw material for self-improvement. What it needs is three pieces of infrastructure.

First, structured outcome recording - not just what happened, but which inputs influenced the decision. Without this, you can't attribute outcomes to causes.

Second, a continuously updated causal model - something that translates outcome records into an evolving understanding of what actually predicts results. This is what separates systematic improvement from anecdotal tuning.

Third, controlled experimentation with human oversight - a mechanism to test alternatives without betting the entire system on untested strategies, and a human gate that prevents the system from overfitting to recent conditions.

These three pieces compose naturally with the architectural patterns I've described throughout this series - event-driven coordination, adversarial specialization, earned autonomy, and weighted consensus. The self-improvement loop is what makes the rest of the architecture sustainable over time. Without it, you're deploying a system that's as smart as it will ever be on day one - and that's a system that degrades from the moment it goes live.

The intelligent enterprises of the future won't just deploy agent fleets. They'll deploy agent fleets that learn, adapt, and improve - continuously, measurably, and under human oversight.

If you're building in this space and want to go deeper on any of these patterns, I'd welcome the conversation. Reach out at hello@prakulsharma.ai.

All views expressed in this article are solely my own and do not represent or reflect the views, positions, or policies of my employer. This is independent thinking on open industry challenges, shared as a personal research interest. Not financial advice.