How a Two-Agent Heartbeat Lets an AI Trade and Adjust on Its Own

# 5 Properties of an AI Monitoring Heartbeat That Make It Reliable

A monitoring system that waits for a human to check it is not a monitoring system. It is a dashboard with extra steps. The value of any monitoring tool is in what it catches when no one is looking, and the frequency at which it looks determines the quality of that catch. The two-agent AI monitoring architecture that has been demonstrated in live trading environments is built around a precise set of design principles, and those principles are not specific to trading. They apply to any business situation where a metric is moving in real time and a slow human response is measurably costly.

Madhuranjan Kumar has been tracking the applied use of multi-agent AI systems in live business environments. The following five properties explain why this particular architecture works and why omitting or approximating any one of them makes the system significantly less reliable in practice.

The Timer Runs Independent of Human Attention, and That Independence Is the Entire Point

The first property that separates a real AI monitoring heartbeat from a reactive AI assistant is that the monitoring interval is governed by a timer, not by a human decision to check in. In the trading implementation, a sub-agent runs every thirty seconds. It does not run when a human thinks to ask for an update. It does not run when the session is active and the operator happens to be watching. It runs at the thirty-second mark regardless of what else is happening.

This sounds obvious when stated directly, but it has a design consequence that is easy to miss. Most AI assistants are conversational by nature. They respond when prompted. When you build a monitoring workflow on top of a conversational AI model, the default behavior is still prompt-and-respond. The model checks when you ask it to check. The timer is not implicit in the model. It has to be built explicitly into the architecture.

The way the thirty-second heartbeat is implemented in the trading setup is through a dedicated loop that calls the sub-agent on a clock interval, separate from any conversational thread. This loop is not controlled by the human operator during a session. It is set up once and runs continuously as long as the session is active.

For any business application, this property translates to a simple architectural requirement: the monitoring interval must be defined in terms of time, not in terms of operator actions. If the system checks ad spend pacing whenever someone on the team looks at it, the benefit of having AI do the checking evaporates. The timer is what makes monitoring autonomous rather than manual with an AI intermediary.

The Cheap Model Handles Raw Data So the Reasoning Model Never Has to Touch It

The second property is the division of labor between the two agents. The architecture uses a small, fast, inexpensive model, in the trading implementation this was GPT-4o mini, as the dedicated data reporter. Its job is to pull raw market data from a websocket feed every thirty seconds, process it into a clean and structured JSON summary, and pass that summary to the main reasoning agent. The reasoning agent never sees the raw data stream.

The reason for this separation is not cost optimization, though cost is a real consideration. The deeper reason is that raw data is almost always the wrong input for a reasoning model. Live trading data, for example, contains redundant fields, transient noise, format inconsistencies, and a high ratio of irrelevant information to actionable signal. Feeding all of that directly to a reasoning model wastes context space, increases inference cost, and, more critically, requires the reasoning model to do data processing work that competes with the reasoning work it is actually there to do.

The sub-agent in this architecture is a specialist. Its only job is to produce the cleanest possible structured digest of the current state at every interval. It is evaluated purely on the quality of that digest, not on any downstream decision. Separating these roles also makes the system easier to debug. If the reasoning model starts making bad decisions, you can inspect the digest it received and determine whether the problem is in the data reporting layer or in the reasoning layer. When the two are combined, this diagnosis is much harder.

For a non-trading application, this principle is equally important. An AI heartbeat monitoring e-commerce ad spend should have one component that pulls raw data from the ad platform API and compresses it into a structured summary of current spend rate, conversion rate, and projected budget exhaustion time. The reasoning component gets only that summary and makes decisions based on it. The separation keeps both components maintainable.

The Digest Must Be Built Around Decisions, Not Around Data Volume

The third property is about what the digest contains and what it explicitly does not contain. In the trading implementation, the digest produced every thirty seconds is not a comprehensive data dump. It is a structured summary with a specific set of fields that correspond directly to the decisions the reasoning agent needs to make: current position, unrealized gain or loss, current price relative to entry, and relevant indicator readings that are decision-relevant. Fields that are technically available but not decision-relevant are excluded.

This is a design constraint, not a compression artifact. The digest is intentionally small because context window space is finite and expensive, and because a reasoning model that receives a shorter, cleaner input makes better decisions than one that receives a longer, noisier input on the same question. In the trading implementation, the caching layer reduces the repeated context from approximately 1,300 tokens to around 214 tokens per interval. That reduction is not just about cost. It is about signal clarity.

Building a good digest format requires knowing in advance what decisions the reasoning agent will be making. This is work that has to happen at the design stage, not at runtime. For a trading application, the decision set is hold, hedge, or exit. For an inventory monitoring application, the decision set might be reorder, hold, or flag for review. For an ad spend monitoring application, it might be continue, throttle, or escalate. The digest format should be built backward from the decision set, including exactly what the reasoning model needs to make those decisions and nothing more.

A Goal Combined With Explicit Limits Prevents the Agent from Optimizing Itself Into a Damaging Outcome

The fourth property is the structure of the instruction given to the reasoning agent. In the trading implementation, the agent is given a goal, specifically a profit target within a time window, alongside explicit limits on position size, drawdown tolerance, and leverage. The goal without the limits would be dangerous. The limits without the goal would produce a passive system that monitors without acting. The combination is what makes the agent both directive and constrained.

The goal-plus-limits structure also establishes a verifiable stopping condition, which is important for multi-turn agent workflows where the model needs to know when its job is done. The slash-goal command in the trading implementation keeps the agent working toward the defined target across conversation turns and across the thirty-second heartbeat cycles, without requiring the human operator to re-specify the objective at each turn.

The behavior this structure produced in the trading example is instructive. Asked to hedge a short position on the S&P 500, the agent did not simply reverse the position. It chose to go long on NVIDIA at approximately a twenty-five percent hedge ratio, reasoning that this provided meaningful downside protection while preserving most of the original trade's thesis. When the signal on the original position strengthened, it exited the NVIDIA hedge and increased the S&P 500 margin. This is not a mechanical rule-following behavior. It is goal-directed reasoning within a constraint set, which is a meaningfully different category of output than a traditional rule-based trading algorithm produces.

For business applications, the goal-plus-limits structure should be explicit in the agent's instruction set. A monitoring agent told only to "watch the ad spend" has no basis for deciding when to escalate or what actions are within scope. An agent told to "keep the daily spend within fifteen percent of the plan, alert if conversion rate drops below two percent for more than thirty minutes, and do not adjust bids without a human confirmation" has a clear mandate, clear limits, and a clear action boundary.

Showing the Math Before Acting Is Not Overhead, It Is the Control Layer

The fifth property is that the reasoning agent in this architecture makes its calculations visible before it executes any action. In the trading implementation, when the agent is told the target is a one-dollar profit, it does not begin trading. It first calculates what that profit target requires: how many points the market needs to move, what position size achieves that target given the current price, and what the downside exposure is at that position size. It shows this work. Only then does it proceed.

This visible reasoning step is not a performance of transparency for the operator's benefit. It is a functional part of the control layer. When the reasoning process is visible, the operator can catch errors in the agent's assumptions before those assumptions get acted on. If the agent has incorrectly estimated the margin requirement or has made a calculation error on the required move, a human reviewing the visible reasoning catches that before any capital is committed.

The same principle applies to non-trading monitoring systems. An AI agent monitoring a one-day sale should show its reasoning when it makes a recommendation. "Current spend rate will exhaust the budget by 2 PM. At current conversion rate, extending budget by eight hundred dollars projects to generate approximately thirty-four additional orders at the current average order value. Recommendation: extend budget." That reasoning is checkable. A bare recommendation, "extend budget," is not.

For businesses building AI monitoring systems, requiring visible reasoning is a design decision, not an optional feature. It is the mechanism by which a human operator can audit the system's logic and catch systematic errors before they compound across multiple decision cycles.

Here is a concrete illustration of all five properties working together. An e-commerce store runs a one-day promotion with eighteen thousand dollars in inventory and a two-thousand-dollar daily ad budget. The AI heartbeat checks conversion rate, cart abandonment rate, and projected budget exhaustion every thirty minutes. A dedicated data reporter pulls the raw numbers from the ad platform and compresses them into a structured digest: current spend, remaining budget, orders placed, conversion rate, and hours remaining in the promotion window. The reasoning agent receives only the digest.

By hour three, the digest shows that the current spend rate will exhaust the two-thousand-dollar budget by two in the afternoon, seven hours before the promotion ends. The agent shows its math: at current conversion rate, the remaining seven hours of the promotion window are projected to generate approximately ninety additional orders at an average order value of sixty-two dollars, representing roughly five thousand six hundred dollars in revenue. It recommends extending the budget by eight hundred dollars and shows the expected return on that extension. A human sees the recommendation and the supporting math, approves the budget extension in two minutes, and the promotion runs through its full window.

Without the heartbeat, the budget exhausts silently at two in the afternoon and the last seven hours of the promotion run with no ad support. The five thousand six hundred dollars in projected revenue from that window does not materialize. The cost of the monitoring system is the time to build it. The cost of not having it is concentrated and invisible until after the fact. The heartbeat is not a trading tool or an analytics tool. It is a decision rhythm. Any business process that depends on noticing a change quickly enough to act on it, and that currently depends on someone remembering to check, has the same problem the trading system had and can be solved with the same five-property design.