What Claude Fable 5 Did in an Overnight Agentic Trading Test

An AI model ran an overnight trading bot for roughly fifteen hours, finished near one hundred dollars in profit at a seventy-one percent win rate, and self-adjusted its own strategy mid-run without being asked. The dollar figure is small. The design principles that made it work are not.

This piece is not about trading. Trading carries real risk and the approach here is one experiment, not advice. What the overnight test demonstrated is a reusable architecture: an agent that acts on real data, bakes in its own costs from the start, defines a hard stopping condition, and runs a self-monitoring loop that reviews and improves the system while no human is watching. That architecture applies to any business with a repeating decision, and building it is the subject of this playbook.

Stage 1: Feed the Agent Real Data From Your Own Operation

Every agentic system that works over time starts with real data, not hypothetical data, not sample data, and not data from somewhere else that vaguely resembles your situation. The trading test started by collecting actual market data from real historical sessions: price snapshots, timing, volume, trade outcomes. The agent was then asked to find a positive expected-value strategy in that data. It could not fabricate a strategy that worked because the data was real, and real data contains real patterns as well as real noise that punishes strategies built on noise.

For a business owner, the equivalent of that data collection step depends on the decision you are automating. A fitness studio monitoring class fill rates needs its own booking data: every booking, cancellation, waitlist entry, and no-show from the last several months, tagged by class time, class type, instructor, and day of week. A restaurant managing table turns needs reservation data, walk-in patterns, and average service times by meal type. A contractor monitoring job pipeline health needs inquiry data, proposal win rates by job type, and average time from inquiry to signed contract. Whatever the repeating decision is, the data that informs it has to come from your actual operation, not from an industry average or a made-up baseline.

The reason this matters operationally is that an agent trained on your real data will find patterns that are specific to your business: the class types at your studio that fill early versus the ones that consistently have late cancellations, the proposal categories where your win rate drops if you take more than three days to respond, the time-of-day patterns in your booking system that predict tomorrow's no-show rate. None of those patterns exist in generic data. They only exist in yours. The agent that works from your data builds a strategy calibrated to your specific situation, which means it will make better decisions in your context than any generic rule designed to work for the average business in your category.

Stage 2: Bake Your True Costs Into the Decision Rule From the Start

The single most important design lesson from the overnight trading run is not the strategy itself. It is that the cost was embedded in the strategy's decision formula before the first trade was placed. The entry threshold required that fair value minus the current price minus the trading fee reached a minimum positive value before action was taken. The fee was not an afterthought. It was part of the math that determined whether an opportunity was worth pursuing at all.

This principle translates directly into business automation. Every repeating business decision has a real cost of action: a cost per email sent, a cost per inventory unit reordered, a cost per promotional offer extended, a cost per automated follow-up triggered, a cost per staffing hour added based on a booking projection. If that cost is not included in the threshold at which the agent acts, the agent will produce outputs that look profitable in the abstract and lose money in practice. An agent that sends promotional offers to fill a half-empty class has to account for the discount cost per redemption, the platform fee per booking, and the opportunity cost of filling those spots at reduced margin versus leaving them open and redirecting marketing spend. All of that goes into the threshold. If it does not, the agent optimizes for fill rate and produces an economics problem.

The practical implementation is a rule statement with numbers: the agent acts when the projected net benefit of the action, calculated after all identified costs, exceeds a minimum positive threshold. State the threshold explicitly before the agent goes live. A fitness studio example: trigger a waitlist notification and a ten percent walk-in discount when a class is below sixty percent capacity eight hours before start time, but only if the projected revenue from the discounted spots exceeds the platform messaging fee plus the margin loss on the discount versus full price. That rule is operationally specific, honest about costs, and produces decisions that are economically justified rather than superficially appealing.

Stage 3: Define the Stopping Condition Before You Turn the Agent On

The overnight trading bot had a hard stopping rule: a ten percent daily loss halt that would stop all activity automatically regardless of any other signal. That rule was defined before the agent started, not added later after something went wrong. The stop was not a response to a bad outcome. It was a constraint that prevented a bad outcome from becoming catastrophic.

Every business agentic system needs an equivalent stopping condition, defined before the agent goes live, and enforced automatically rather than relying on someone remembering to check. The form varies by domain. A booking promotion agent gets a maximum number of promotional messages it can send per day, regardless of how many classes show low fill rates. An inventory reorder agent gets a maximum reorder value per week and a minimum days-of-stock threshold below which it will not reorder regardless of price signals, because a supplier relationship problem or a delivery delay could make a large automatic reorder a liability. A lead follow-up agent gets a maximum number of touches per contact per week and a hard stop after a contact has not responded in a specified number of cycles.

The stopping condition does two things. It prevents the agent from taking unusual actions at scale when it encounters unusual data. And it creates a natural review point: when the agent hits its stop, a human looks at why, which is where genuine learning about edge cases and unexpected situations comes from. An agent that can run indefinitely without hitting a stop is an agent that can drift indefinitely without triggering a human review. The stop is not a failure condition. It is a designed feature that keeps the system honest and keeps the human informed.

Stage 4: Set Up the Self-Monitoring Cron

The most distinctively agentic behavior in the overnight trading test was the self-correction cycle. Three hours into the run, the agent analyzed its own trade history and adjusted its strategy based on what it found. Then a cron monitor was configured to wake every two hours automatically, run a health check on recent activity, adjust the strategy when the evidence was strong enough to justify it, and restart the system. The monitor ran itself through the night. The results improved after the mid-run adjustment.

The equivalent for a business system is a scheduled review agent that wakes on a regular cycle, pulls the recent results of the automated decisions, and adjusts the rules when the evidence supports it. For a fitness studio, this might be a daily morning check that reviews the previous day's class fill rates, identifies which class types triggered promotions, records whether those promotions converted, and adjusts the fill-rate threshold or discount level when the conversion data across several weeks is clear enough to justify a change. For a contractor's pipeline agent, it might be a weekly review that checks whether the follow-up timing rules are producing responses at the expected rate and surfaces any patterns in the data that suggest an adjustment.

The critical discipline is adjusting on strong evidence across multiple cycles, not on a single day's results. A class that filled unexpectedly without a promotion last Tuesday is interesting noise, not a signal. A pattern of fifteen consecutive classes filling above threshold within four hours of the promotion trigger is a signal that the trigger threshold is too low. The review agent needs to be designed to distinguish between those two situations, and the threshold for making an adjustment needs to be high enough that the system is tuning toward real patterns, not chasing noise.

For the fitness studio worked example with specific numbers: the studio runs twelve classes per week. Average revenue per fully-booked class is two hundred and fifty dollars. Current average fill rate is sixty-eight percent. The agent's initial rule triggers a waitlist notification and a small discount when a class drops below sixty percent capacity with eight hours to start time. After six weeks of the monitoring cron running and reviewing conversion data each morning, the fill rate for classes that triggered the rule improves to eighty-one percent. The improvement in fill rate across twelve classes per week, sustained over a month, adds roughly thirty-nine hundred dollars in monthly revenue against a promotional discount cost of approximately six hundred dollars per month, for a net gain of roughly thirty-three hundred dollars. The system that produces that gain runs on its own schedule after the initial setup, reviews its own results, and adjusts its own thresholds. A human checks the weekly summary, makes strategic decisions about class scheduling and pricing, and lets the agent handle the tactical fill-rate management.

Stage 5: Route Tasks to the Right Model Tier

The overnight trading test managed API costs by splitting the work. Heavy analysis tasks, the kind that required genuine reasoning about strategy and statistics, went to the most capable model. Simple lookups, data retrieval, and basic formatting went to a faster and less expensive model. That routing decision reduced the per-run API cost by roughly sixty to eighty percent without any meaningful loss in the quality of the outputs that mattered.

For a business agentic system, the equivalent routing decision is between tasks that require real reasoning and tasks that require simple retrieval or formatting. Analyzing whether this month's booking patterns represent a meaningful trend that warrants a strategy adjustment requires a capable reasoning model. Pulling tomorrow's class schedule from a data file, checking which classes are below threshold, and formatting the notification message does not. Routing those categories to different model tiers is not a technical optimization. It is an economic decision that determines whether an agentic system is financially sustainable to run continuously.

The practical implementation is to design the agent's architecture with two layers explicitly: a reasoning layer that handles analysis, strategy decisions, and adjustment recommendations, and an execution layer that handles data retrieval, rule checking, action triggering, and output formatting. The reasoning layer runs the capable, expensive model when a strategic decision is needed. The execution layer runs a cheaper, faster model for the repetitive operational steps. The cost reduction is substantial enough that it determines whether a system designed to run every few hours, every day, is economically viable at scale.

Putting It Together: The System That Runs While You Sleep

The five stages form a single coherent architecture. Feed real data from your own operation so the agent is calibrated to your specific situation. Bake your true costs into the decision threshold so the agent acts only when the math is genuinely positive after all costs are accounted for. Define a hard stopping condition before the agent starts so unusual data cannot produce unusual actions at scale. Set up a self-monitoring cron that reviews results on a regular cycle and adjusts on evidence strong enough to justify a change. Route reasoning tasks to capable models and execution tasks to efficient ones to keep the system financially sustainable to run continuously.

An agent built on these five stages runs overnight on whatever decision you give it, returns a result in the morning, and improves over time as the monitoring cron accumulates more data to adjust from. It does not require constant supervision because the stopping condition handles edge cases and the cron handles self-correction. It does not require a large API budget because the routing layer matches task complexity to model cost. And it does not require you to be present during the run because the design is specifically built for the time when you are not watching.

Madhuranjan Kumar's consistent observation in building these systems for clients is that the most valuable step is the second one: baking the real costs in from the start. It is also the step most commonly skipped when someone builds a first version quickly. Agents that skip cost integration look impressive in early testing and produce economics problems in production. The discipline of stating the full cost of each action, including the less obvious ones, and requiring the threshold to be positive after all of those costs, is what separates a system that improves the business from one that optimizes for a metric while quietly eroding the margin.