Build Decisions for Treasury AI:
Proving Idle Cash Logic Before Writing

The demo showed the agent moving funds between internal accounts. It looked clean. The stakeholder nodded. But the code behind it is a mess of hardcoded thresholds and brittle logic. You are about to inherit that debt. The outcome you want is a system that executes treasury instructions with zero manual review. The outcome you will likely get, if you rush, is a script that breaks the moment market conditions shift slightly.

You are deciding how to build this capability. The core question is not whether the agent can move money. It is whether it understands what it is moving. The bank has profited from idle cash for years. That profit margin depends on precision. If the agent misreads a balance, the cost is not just a bad trade. It is a compliance breach. It is a halted operation. It is a loss of trust that takes months to rebuild.

What does the shadow ledger prove?

The shadow ledger proves that the agent's logic matches human intent on historical data. It is a read-only mirror of the production environment. The agent runs against a snapshot of the bank’s ledger. It proposes moves. It does not execute them.

This is the first gate. You feed the agent a week’s worth of historical ledger states. You let it propose how it would allocate idle cash. You compare its proposals to what the human treasury team actually did. If the agent moves funds that were needed for next-day clearing, you know it has a fundamental misunderstanding of liquidity constraints.

The goal is not to get a 100% match immediately. The goal is to identify the specific logic gaps. Does the agent ignore pending settlements? Does it treat a balance above zero as available without checking the settlement cycle? These are the bugs you need to find before they cost you money.

The shadow environment is cheap to build. It is expensive to ignore. If you skip this step, you are betting that your agent’s definition of idle cash is identical to your team’s. It is not. Humans contextually understand that a balance might be needed for a known future obligation. The agent sees only the number.

How do we define idle cash in code?

You must define idle cash explicitly. The agent will not infer it. It will treat any balance above zero as available. This is the primary failure mode. The agent misinterprets idle as unallocated. It moves funds needed for next-day clearing.

The definition must include pending settlements. It must include known future obligations. It must include a buffer for volatility. If the agent does not have this buffer, it will optimize for yield at the cost of liquidity. It will move the last dollar of cash into a short-term instrument, leaving the account empty when a settlement hits.

This is not a model problem. It is a data problem. The agent needs a clear signal for what is available. If the ledger does not provide that signal, the agent will guess. You cannot debug a guess. You can only debug a rule.

The rule should be simple. Available cash is total cash minus pending outflows minus a safety buffer. The safety buffer is not a fixed number. It is a function of the volatility of the account. If the account has high variance, the buffer is larger. If it is stable, the buffer is smaller. The agent needs this logic in its decision loop.

When do we stop reviewing every move?

You stop reviewing every move when the diff is empty. The agent proposes a move. The human reviews the diff. If the diff is empty, the human approves. If the diff is not empty, the human rejects.

This is the second gate. You move from shadow to limited write access. The agent gets write access to a sandbox account. The limit is $1. The agent can execute real trades, but the impact is negligible. The point is not the money. The point is the process.

The agent must handle edge cases in this phase. What happens when the price feed is stale? What happens when a counterparty defaults? The agent must have a halt path. If it does not know what to do, it must stop. It must not guess.

The human review is not a bottleneck. It is a validation tool. You are checking if the agent’s logic holds up under real-time conditions. If the agent consistently produces the right moves, the diff will be empty. If it does not, you will see the errors in the log. You will see why it made the wrong move.

This phase is short. It is not meant to last months. It is meant to last weeks. You are looking for consistency. You are looking for reliability. If the agent is reliable in the sandbox, it is ready for the next step.

Why does stale price data break the agent?

The agent executes a trade based on stale price data because the feed latency exceeds its decision window. This is a common failure mode. The agent thinks it is buying at $100. The market has moved to $102. The agent buys at $102. It loses money.

The agent must check the timestamp of the price data. If the data is older than the decision window, the agent must not trade. It must hold. It must wait for fresh data.

This is not a model problem. It is a data pipeline problem. The agent needs a clear signal for data freshness. If the pipeline does not provide that signal, the agent will use stale data. You cannot debug a pipeline that does not tell you when it is stale.

The decision window is not arbitrary. It is based on the volatility of the asset. If the asset is highly volatile, the decision window is short. If it is stable, the decision window is longer. The agent must know this. It must adjust its behavior based on the asset class.

How does the agent track its own pending orders?

The agent double-books a position because it does not track its own pending orders. It sends an order to buy. It does not wait for confirmation. It sends another order to buy. It now has two positions. It has over-allocated its cash.

The agent must track its own state. It must know what orders are pending. It must know what orders are filled. It must know what orders are cancelled. It must not send a new order until it knows the state of the previous one.

This is a state machine problem. The agent is a state machine. It has states. It transitions between states. It must not transition to a new state until it is sure of the current state.

The state machine must be explicit. It must be in the code. It must not be implicit in the model. The model can make mistakes. The state machine cannot. The state machine is the guardrail. It prevents the agent from making the same mistake twice.

What is the cost of a counterparty default?

The agent fails to recognize a counterparty default and continues to extend credit. This is a catastrophic failure. The agent is lending money to an entity that will not pay it back. The agent is losing money.

The agent must check the credit status of the counterparty. It must know if the counterparty is in default. It must know if the counterparty is at risk of default. It must not extend credit to a counterparty in default.

This is a data problem. The agent needs a clear signal for counterparty risk. If the data source does not provide that signal, the agent will guess. You cannot debug a guess. You can only debug a rule.

The rule should be simple. If the counterparty is in default, do not extend credit. If the counterparty is at risk, reduce the credit limit. If the counterparty is healthy, extend credit. The agent must follow this rule. It must not deviate from it.

How do we measure liquidity penalty?

The agent optimizes for yield but ignores the liquidity penalty for early withdrawal. It moves cash into a high-yield instrument. It assumes it can withdraw the cash whenever it wants. It cannot. There is a penalty. The agent loses money.

The agent must calculate the liquidity penalty. It must know the cost of early withdrawal. It must factor this cost into its decision. It must not choose a high-yield instrument if the penalty is higher than the yield.

This is a calculation problem. The agent must be able to do the math. It must be able to compare the yield to the penalty. It must be able to make the right choice.

The calculation must be explicit. It must be in the code. It must not be implicit in the model. The model can make mistakes. The calculation cannot. The calculation is the guardrail. It prevents the agent from making a bad financial decision.

What is the path to full autonomy?

The path to full autonomy is not a straight line. It is a series of gates. You must pass each gate before you can move to the next.

The first gate is the shadow ledger. You prove the agent’s logic matches human intent on historical data. The second gate is the sandbox. You prove the agent handles edge cases in a limited environment. The third gate is live execution. You prove the agent maintains liquidity ratios under live market stress.

You do not skip gates. You do not rush. You build the system step by step. You validate each step. You ensure that the agent is ready for the next step.

This is the method. Diagnose the problem. Model the logic. Build the system. Harden the system. You do not do it all at once. You do it in stages. You validate each stage. You ensure that the system is ready for the next stage.

This week, you should build the shadow ledger. You should feed it a week’s worth of historical data. You should let the agent propose moves. You should compare the proposals to the actual moves. You should identify the logic gaps. You should fix the gaps. You should repeat the process.

This is not a quick fix. It is a long-term investment. It is an investment in reliability. It is an investment in trust. It is an investment in the future of your treasury operations.

The agent is not a magic bullet. It is a tool. It is a tool that can be used well or badly. It is up to you to use it well. It is up to you to build the system that allows the agent to be used well. It is up to you to validate the agent’s logic. It is up to you to ensure that the agent is ready for live execution.

The cost of waiting is high. The cost of rushing is higher. You must find the balance. You must build the system that is both fast and safe. You must build the system that is both efficient and reliable. You must build the system that is both innovative and conservative.

This is the challenge. This is the opportunity. This is the path to full autonomy.