Why High-Stakes Multi-Agent Workflows Are Harder Than They Look

When I started building UnHodl ↗, I gave one knowledgeable agent a few market screenshots and a clear task. It analyzed what it saw and produced promising results. Promising enough to keep going.

So I gave it more.

More data. More screenshots. More timeframes. More markets. More things to remember and more decisions to support.

The answers became less reliable. Important details got mixed together. The agent sometimes invented connections or produced something that sounded right without being grounded in the right inputs.

One agent was carrying too much.

Splitting the work exposed the real problem

The first fix was to make one job as narrow as possible. Charter would study one market on one timeframe. The answers became easier to contain and reuse.

That worked until I had several timeframe analyses and needed to understand the market across all of them. I added Analyzer to combine the narrow work into one broader market view without starting again from the screenshots.

The next analysis needed related markets and wider conditions. Quant could reuse those market views together with shared context such as Bitcoin dominance, total market capitalization, and ETH/BTC.

This was the first real scalability gain. A useful market state could be prepared once and reused wherever later work depended on it. Adding another analysis did not require one giant agent to rediscover the whole market from raw inputs.

But reuse depended on a dangerous assumption: that one agent’s output would arrive at the next agent with its meaning intact. The agents could each produce plausible work. The trouble was between them.

Imagine four timeframe analyses arriving for the same market. Each looks reasonable. But one is old. Another came from a retry after the inputs changed. A third used different assumptions. Combine them and you can get a polished market view of a moment that never existed.

That is why a high-stakes handoff cannot depend on conversation alone. Deterministic code now has a simpler job than the agents: check what an output is based on, whether it is current, whether it belongs with the other inputs, and whether the workflow may continue.

Guard adds a separate challenge. It reviews what an agent produced and can pass it, ask for revision, stop it, or return it to a human. The code checks whether the work belongs. Guard challenges what the agent concluded.

Some handoffs can be made this precise. The next problem could not.

“Wait for a break” is not an executable instruction

As the work moved closer to a possible trade, UnHodl needed a role that could watch changing conditions. That role is Broker.

A trading plan might say:

Wait for a break, then a retrace, then hourly confirmation.

A trader understands the instruction because a trader keeps interpreting the market while waiting.

What counts as a real break? How deep can the retrace be? What confirms the move? How long is the plan valid? What if volatility changes? What if the portfolio changes? What if the original reason for the trade disappears?

That is different from passing a fixed order from one service to another.

It is also where interpretation can quietly become action. Automated Broker execution therefore remains behind a human gate until that reasoning has been tested enough to deserve autonomous authority.

A trade was sent. What actually happened?

Even a clear and authorized action creates another problem once it leaves the system.

• Was it rejected?
• Partially filled?
• Completely filled?
• At what price?
• Is the exchange state delayed?
• If our local request timed out, did the exchange still receive it?
• Do we know enough to retry without creating another order?

A local timeout does not prove that nothing happened. An exchange acknowledgement does not prove that the order filled. If the system guesses wrong, it can retry an action that already happened and create a second order.

The system must compare what it intended to do with what the exchange now reports. This is often called reconciliation.

Sometimes the answer is simply unknown. That must stop the workflow until more information arrives or a human decides what to do next. Unknown cannot quietly become success, failure, or permission to try again.

Five questions we kept needing

Clawblins ↗ are my AI co-workers. They research, challenge assumptions, review architecture, help build, and help write. I own final judgment and consequential decisions.

They have found gaps in diagrams, questioned role boundaries, argued with explanations, and helped turn recurring problems into a review method called PROOF ↗.

PROOF does not solve a consequential agent workflow. It helps ask better questions earlier.

We grouped the recurring problems into five questions:

1. Premise: What is this based on? Are the inputs current, relevant, and compatible?
2. Role: Who is allowed to decide, approve, act, review, or stop?
3. Operation: What exactly is being authorized or attempted?
4. Outcome: What actually happened in the outside world?
5. Failsafe: What stops or contains the workflow when something fails or remains unknown?

Read the open PROOF standard ↗

The same failures appear outside trading

Picture a pharmaceutical manufacturer deciding whether a batch can be released.

One agent reads lab results. Another reviews manufacturing records and deviations. Another checks safety signals and regulatory requirements. A final agent prepares a release recommendation.

One lab result may have been superseded. A deviation may belong to a different batch. A safety signal may arrive while the review is in progress. Only an authorized person can release the batch, and uncertain evidence must stop the product before it moves.

Now picture a financial institution handling a large payment flagged for review.

One agent checks the customer and account history. Another looks for fraud patterns. Another checks sanctions and policy rules. A fourth recommends release, rejection, or escalation.

Approval must refer to the exact payment, amount, destination, and conditions. Then the bank sends it—and the local request times out. Did the payment fail, or is it already moving through the network? Retrying before that is known can duplicate the transfer.

Now picture a factory where a machine shows rising vibration and heat.

One agent interprets sensor data. Another reviews maintenance history. Another estimates the effect of slowing the line.

The slowdown is approved, but the controller later reports that only half the machines changed speed. The rest are still running at full rate while material moves between them. Parts can pile up, equipment can be damaged, and workers may be exposed to a line behaving in an unexpected way. Another command could make the imbalance worse.

What I learned

When I began UnHodl, I thought the difficult part would be making agents intelligent enough to do specialized trading work.

The harder problem was carrying meaning, authority, and consequence across the gaps between them.

Intelligence inside each step is not enough.