AGENT · RUNNING · HEARTBEAT 14s AGO
RISK UTIL 42% · POSITIONS 2 · DELAY 30m
SINCE APR 2026 · SAT APR 18 · 14:32 EDT
← All posts  ·  2026.04.17  ·  MANIFESTO  ·  9 min read

Rules of the Road: Building a Rust Options Agent in Public

This is a public engineering log of an autonomous software agent that trades options on my personal brokerage account. Every trade it executes, every tool call it makes, every gate the risk engine enforces — logged here, on a thirty-minute delay, for anyone to inspect. This post explains what I'm doing, why I'm doing it this way, and the constraints that keep the project from becoming something it shouldn't be.

Why publish at all

The answer isn't "for the audience." I'm not running a signal service. You cannot subscribe. There is no Discord. No broker affiliate link. No "copy this trade" button.

The answer is that the best way to demonstrate what FERROUS — the Rust AI agent consultancy I'm building — actually does is to put one of its agents in front of a brutal, quantifiable benchmark and let anyone watch. Writing code that trades real money is a different discipline from writing code that passes a test suite. The dashboard is not a funnel for signals. It's proof-of-work.

There are plenty of screenshots-of-PnL accounts on the internet. Most of them are noise. What's harder to fake is a live reasoning trace — the LLM's tool calls, the risk gate's approve/reject decisions, the self-grading pass on a closed position. That's what's on the dashboard, and that's what makes this different from the countless "trade with my bot" pitches that should make any honest engineer uncomfortable.

The constraints that keep this clean

Running a public-facing site that shows live options trades is a regulated activity in most contexts. The specific danger is becoming an unregistered investment adviser under the Investment Advisers Act of 1940 — a three-part test that looks at whether you're giving advice about securities, as part of a business, for compensation. Miss any one of the three prongs and you're (generally) outside the definition.

I've structured the project to sit firmly outside that definition, and it stays there by design. The rules I live by:

No compensation for the trades themselves

Nobody pays to see them. There is no subscription tier, no paid access, no ads on the trade feed, no affiliate relationships with brokers. If the site ever sells anything, it sells FERROUS engineering services or framework licensing — products about building agents, not about following trades.

No solicitation of capital

I will never accept capital from a viewer of this site in connection with this strategy. No pooled vehicle. No managed account. No fund. The LLC that owns this brokerage account is capitalized entirely by me. If you read "send me money and I'll trade it for you" anywhere on this site, it's a defacement — report it.

No "do this too" framing

The site is written in the third person about the agent. It does not say "good setup on INTC." It says "the agent took a bull put spread on INTC; here is the reasoning trace; here is the risk gate's decision." The subject is the software. Anything that reads like a recommendation gets cut.

Thirty-minute delay on every trade

Trades don't appear on the public dashboard until thirty minutes after the broker fill timestamp. This exists for two reasons. The first is regulatory hygiene — it removes the real-time-signal optics. The second is practical: real-time options fills are adversarial information. Publishing them live would invite front-running of my own book. The delay is enforced at the database layer, not the display layer. A public_at column on the trade record is set to executed_at + 30 minutes, and the public API filters on that column. It's harder to accidentally leak.

Equity curve from day one, no windowing

The chart on the dashboard starts on the inception date of live trading. I cannot change that. I cannot show "last 30 days" during a good month and "all time" during a bad one. Selective performance display is where marketing shades into misrepresentation, and the fastest way to destroy whatever credibility the project builds is to let a dashboard quietly start favoring a recent window.

A separate LLC for the trading account

My professional engineering practice, Barron Engineering, operates as a New York DPC under a PE license. It has nothing to do with this project. The trading account is held by a separate LLC so there is zero chance of a viewer mistaking the two businesses for one another, and zero chance of this project affecting the licensure side of my life.

Disclaimers that take themselves seriously

The site's disclaimers are not a footer afterthought. They appear above the fold on the dashboard, in the global footer, on a dedicated Disclosures page, and in the Terms of Service. They're reviewed by a securities attorney in my jurisdiction. When they say "this is not investment advice," they mean it — and the structure of the site reflects that claim rather than contradicting it.

What the agent actually is

street-agent is a Rust binary. A single process, with no Python glue, no LangChain, and no framework stack between the LLM and the broker. It's built on three layers that cannot see past each other:

  1. The reasoning layer. An LLM (Claude, via the Anthropic SDK directly) given a typed tool registry of 26 capabilities across 7 categories. It can analyze markets, price options, propose strategies, submit orders. It cannot read or write the risk configuration. It cannot modify its own tool registry. It cannot talk to the broker except through the risk engine.
  2. The risk engine. A Rust module with hardcoded limits and a config file loaded at startup. Every proposed order passes through a series of gates: strategy allowlist, position size, concurrent positions, underlying liquidity, spread width, days-to-expiry, daily drawdown, weekly circuit breaker. A rejection is final. The LLM sees only "approved" or "rejected: reason."
  3. The execution layer. Paper-default. Live trading requires the --live flag on the command line, every run. There is no config value, no UI toggle, no persistent setting. If I don't type --live, no real capital moves.

The whole architecture pivots on one idea: the reasoning layer and the execution layer are different programs as far as trust is concerned. The LLM is treated as an adversary — not because it's malicious, but because it's probabilistic. You don't give a probabilistic system unbounded access to money. You give it a narrow, typed interface and an unblinking gate in front of the thing that matters.

What this is testing

The agent's P&L is one kind of test, but it's not the most interesting one. The harder questions are architectural:

  • Can a Rust risk engine successfully constrain an LLM reasoning loop over weeks of operation without a single violation reaching the broker?
  • Can a self-grading pipeline produce genuinely useful retrospective analysis on its own trades, or does it just produce plausible-sounding text?
  • How often does the LLM propose something the risk engine rejects, and what's the distribution of rejection reasons? (This tells you a lot about what kind of reasoning the model does under the prompt.)
  • What breaks first — the pricing math, the broker integration, the risk engine, or the LLM's judgment? Which one should you watch most carefully?

Those are the posts I'll actually be writing. The P&L curve will do what it does.

Why this is a good bet, regardless of P&L

The worst-case outcome is that the agent loses money. The LLC takes the loss, I learn things, and the dashboard becomes a public record of honest failure — which is its own kind of credential in a field saturated with anonymous track records.

The base case is that the agent breaks even or does something mildly interesting, and the project generates a steady flow of engineering content that demonstrates FERROUS's capabilities to the people who care about that sort of thing: prop shops, quant teams, small funds, and the engineers who'd want to work on infrastructure like this.

The upside case is that the agent does something interesting enough that the framework behind it — not the strategy — becomes a product: a Rust crate, a consulting practice, an enterprise license. The path to monetization runs through infrastructure, not signals. Every structural decision in this project is in service of keeping that path open.

The dashboard is content. The architecture is content. The reasoning traces are content. The losses are content. The product is FERROUS — this is just what it looks like with the hood open.

What happens next

The agent has been running since [DATE]. Posts on this blog will cover architecture decisions, risk engine internals, options math, postmortems of trades that went badly, and observations about what it's actually like to run an LLM reasoning loop against a market. The dashboard will keep publishing the trade log on a thirty-minute delay. I'm not making promises about frequency — I'm making promises about honesty.

If you want to follow along, the RSS feed is on the engineering page. If you're a prop shop or a fund evaluating Rust infrastructure for your own use, the about page has contact information.

If you're here for trade signals, please go somewhere else. This site is not for you, and it never will be.


Dan Barron · FERROUS Labs · More posts