Skip to main content

Autonomous Decision Systems With Real Money on the Line

Most teams deploying autonomous agents can tell you the agent ran. Almost none can tell you whether it should have.

That gap is survivable when the agent drafts emails. It is not survivable when the agent moves money. I run an unattended trading system against a live onchain market. Real capital, adversarial counterparties, no human in the loop, months between interventions. This is what production actually required.

Objective

Build an agent that acts continuously without supervision, and instrument it well enough that every decision, including the decisions it declined to make, can be audited against what actually happened.

Architecture

  • Single async daemon, roughly twenty concurrent tasks under one supervisor
  • Multiple websocket feeds for market data and order books, REST fallback for discovery and reconciliation
  • Two decision cadences: a sub-second path for time-sensitive situations, a slower scan for the bulk of the work
  • Heartbeat logging with reject-reason counts, so a quiet period is distinguishable from a broken loop
  • Risk state machine with exposure caps, capital reserves and a hard halt
  • SQLite journal in WAL mode, fire-and-forget writes that can never block a decision

The model is deliberately dumb

Each binary outcome is priced with a zero-drift log-normal model. Given spot S, strike K, annualised realised volatility σ and time to expiry T:

d2 = (ln(S/K) - 0.5 * σ² * T) / (σ * √T)
P(S_T > K) = N(d2)

Volatility comes from realised returns. There is no drift term, and that omission is the point. An early version annualised the recent move and used it as drift. On short horizons that is roughly harmless. On a thirty-day horizon it produced confidence above 99% on outcomes that were nowhere near certain. Momentum does not extend linearly and a model that assumes it will is not conservative, it is confidently wrong.

The pricing is textbook on purpose. The discipline lives downstream.

Break-even is the only benchmark that matters

A binary paying $1 bought at price p has break-even win rate p. Enter at 0.45 and you need better than 45% to make money. That is arithmetic, and it makes every guardrail falsifiable: either the trades a gate lets through clear their own break-even, or the gate is leaking losers.

Journaling the refusals

Every execution is journaled with full context. So is every rejection: which gate blocked it, at what price, with what modelled probability, on which market. The rejections are the valuable half. A system that only records what it did cannot tell you what it cost you.

Once the market resolves, each blocked decision is scored against reality. If the trade would have won, the counterfactual is 1.0 - price. If it would have lost, -price. Sum by gate and the question answers itself: is this guardrail earning its keep, or quietly blocking profitable work?

Calibrating on the lower bound, never the raw rate

Closed trades are bucketed by modelled probability and by entry price. Per bucket: sample count, realised win rate, and the Wilson 95% lower bound.

          p̂ + z²/2n - z * √( p̂(1-p̂)/n + z²/4n² )
lower =  ─────────────────────────────────────────
                      1 + z²/n

Verdicts gate on the lower bound, so a lucky streak can never loosen anything. The thresholds are asymmetric by design: tightening needs only a modest sample, loosening needs several times more. Cheap to be careful early, expensive to relax on thin data.

The output is advisory. No cron, no auto-tuning. A human reads the verdicts and decides. An agent that retunes its own risk limits from its own recent performance is a feedback loop pointed at its own head.

Reconciling against an external source of truth

Local state drifts from settled onchain reality. Positions resolve and vanish. Partial fills leave phantom inventory. A reconciliation pass diffs local storage against chain state and closes what no longer exists.

The instrumentation itself needed auditing too. A worthless position was journaled twice, once when written off locally and again when the onchain redemption ran an hour later, both rows carrying the full loss. Summing them double-counted every write-off and made the track record look considerably worse than it was. The bug was in the measurement, not the system. If you are not auditing your own accounting, your calibration is built on it anyway.

Where this connects to my day job

It's a project we've investigated and which I drive at Scalytics, where we build Lascaris, a sovereign operating system for AI agents. Kafka-native event streaming, an agent runtime, shared memory, and an immutable record of every agent decision on S3. The open core includes KafScale, the S3-native Kafka-compatible transport underneath it.

The system described is where I test the architecture on myself. Same shape as what Lascaris does for regulated operators: every decision recorded with the context that produced it, every action reconstructable after the fact, no dependency on a vendor holding your reasoning. The difference is that here the feedback arrives in hours and costs money, which is a considerably less forgiving test environment than a quarterly audit.

Finance is one of the sectors where that matters most. Trading and treasury desks moving toward autonomous execution, onchain settlement, and agent-driven risk have the same requirement that defense and energy operators do. You have to be able to reconstruct why the system acted, and prove it to somebody who was not there.

What transfers

The shape is not specific to trading. Any agent acting without a human in the loop has the same blind spot:

  • Procurement agents that auto-approve under a threshold and decline above it
  • Fraud review that blocks transactions nobody ever revisits
  • Incident response automation that decides what not to page on
  • Content and compliance filters whose false negatives are invisible by construction

In every case the refusals are unobserved, the thresholds were set once by intuition, and nobody has checked since. Markets force the accounting because the loss shows up in the balance. Everywhere else you have to build the accounting yourself.

One last thing, since it is the most common question about systems like this.

Why the screenshots don't add up

Search for prediction market bots and you will find the same claim repeatedly: thousands of trades, near-perfect win rate, buy at $0.98 or $0.99 where the outcome is already obvious, collect the last cent, repeat forever. The screenshots show a rising equity curve and a win rate in the high nineties.

The arithmetic kills it before liquidity even enters the picture.

Buy a $1 binary at $0.99. You risk $0.99 to make $0.01. That is a payoff ratio of 1:99, so break-even win rate is 99%. Not "almost always." Ninety-nine percent, exactly, before fees and slippage. At 99.0% you have done all that work to earn nothing. At 98% you are losing money steadily while your win rate screenshot looks spectacular. One reversal erases ninety-nine wins in a single settlement, and reversals are precisely the events nobody screenshots.

Then the market structure makes it worse in three ways.

The price you see is not a price you can trade. Screenshots show mid or last, not executable depth. At the extremes the book is a few hundred dollars deep at best. Sizing up walks you through the ladder into progressively worse fills, and at 1% gross margin your slippage budget is measured in tenths of a cent. Displayed liquidity above your ceiling is not liquidity you can use.

Nobody sells you a sure thing. If an outcome is genuinely settled, the holders redeem at $1.00 rather than sell to you at $0.99. The asks that do sit there exist for a reason: someone needs the capital now, or someone knows the outcome is less settled than the price implies. You are not picking up free money, you are being adversely selected. The size available correlates inversely with how certain the outcome actually is.

Exits are worse than entries. Buying into a thin book is hard. Selling into one when you need out is harder, because the bid that was there in calm conditions vanishes exactly when the outcome turns. The strategy has no stop. Its only exit is being right.

The same failure runs in reverse at the cheap end. Deep out-of-the-money contracts at a cent or two get sold as free lottery tickets. A $0.01 contract needs better than a 1% strike rate to break even, and the ones sitting at a cent are usually there because the market has priced them correctly. Buying more as the ask declines is not averaging down. It is the market telling you the outcome became less likely and you disagreeing without new information.

Turnover finishes the argument. Daily markets resolve once a day. A strategy that only fires in the last hour before resolution gets a handful of shots per day across the whole universe, each capped by real depth. The compounding curves in those posts assume unlimited turnover at displayed prices. Neither holds.

This is why the guardrails described above are asymmetric, and why every cheap entry has to clear a minimum expected return rather than merely being cheap. A high win rate is not evidence of anything on its own. Paired with the payoff ratio that produced it, it is often evidence of the opposite.

Notes

This system is private and remains so. Entry criteria, parameter values and performance figures are not disclosed. What is described here is the engineering: how it is supervised, journaled, reconciled and calibrated. That part transfers.

Running agents in production and unsure whether your guardrails are helping or hurting?

See my Services

Book a call

Contact me

Most read articles

Building a Model-Agnostic Multi-Agent System with OpenClaw

Over one week we rebuilt our AI stack around OpenClaw’s multi-agent architecture to avoid provider lock-in and stop wasting premium tokens. By aligning models to tasks, diversifying fallbacks across providers, enforcing minimal tool access, and switching to memory-first workflows with ephemeral sessions, we reduced token usage per task by about 70% and cut our monthly bill by 77% while improving operational resilience. How We Achieved 77% Cost Reduction and Provider Independence Over the past week, we rebuilt our AI infrastructure around OpenClaw’s multi-agent architecture. The result was a 77% cost reduction , provider independence , and a delegation system that routes work to the most cost-effective model for each job. Below is the technical journey of optimizing a 7-agent squad with OpenClaw. The Challenge: Model Provider Lock-In We started with a simple problem: our entire squad defaulted to a single model provider. This created three issues: Cost inefficiency beca...

BacNet => MQTT in Production: The Real Cost of Bridging BACnet to MQTT at Scale

bacnet2mqtt looks simple in a README and expensive in production. Once BACnet polling, reconnection behavior, stale state, and MQTT publishing collide, teams discover they are not deploying a lightweight adapter but operating infrastructure. This article breaks down where bacnet2mqtt works, where it becomes a bottleneck, and which production patterns reduce the operational damage before incidents, backlogs, and silent data loss turn a building integration into a long-running engineering problem. I inherited a building controls integration problem 18 months ago. Three office floors. 217 BACnet sensors covering temperature, occupancy, and HVAC actuators. The data was trapped inside the building automation network while the business wanted analytics, reporting, and compliance visibility in the data platform. The obvious answer looked easy enough: deploy bacnet2mqtt, bridge BACnet into MQTT, and push the stream into the lakehouse stack. The repository made it sound like a w...

Why Is Customer Obsession Disappearing?

Many companies trade real customer-obsession for automated, low-empathy support. Through examples from Coinbase, PayPal, GO Telecommunications and AT&T, this article shows how reliance on AI chatbots, outsourced call centers, and KPI-driven workflows erodes trust, NPS and customer retention. It argues that human-centric support—treating support as strategic investment instead of cost—is still a core growth engine in competitive markets. It's wild that even with all the cool tech we've got these days, like AI solving complex equations and doing business across time zones in a flash, so many companies are still struggling with the basics: taking care of their customers. The drama around Coinbase's customer support is a prime example of even tech giants messing up. And it's not just Coinbase — it's a big-picture issue for the whole industry. At some point, the idea of "customer obsession" got replaced with "customer automation," and no...