Ian here, ferreting the internet like a truffle pig looking for nomnoms. 🐷 This is an example of my own personal automated trading strategy (binary coded), adjusted for an equity curve + guard rails specifically designed for passing propfirm evals. Tests say it should be a 100% pass rate, but we'll see about that! Just a fun side-experiment I wanted to try. BUT: The base strat currently runs on my live account, built from my own trading experience and what I personally see on the charts. It was rough, going back and forth with Claude co-work, but it definitely did the heavy lifting of building Python scripts for testing, parsing 16 years worth of historical data, and coding/re-coding it to match my typical strategy. Took a long time and many dollars. 🤑 My objective is to move towards a more agentic style, where it can watch the trades that are taken autonomously, understanding what might need to be changed- Then implementing those changes for more testing. Plus, self-learning experimentation to improve upon the base strategy. Not new to LLM use, but never made a single agent before. 🙃 FYI, the PnL looks astronomical, but it's designed to be a consistent grinder. This just shows how consistent it actually is starting with only $2k! On a $50k account, the drawdown is only 2.64% (as built for my challenge)...

I have just completed Days 1–16 of the Zero One Systems curriculum. My contribution has been applying the prompts provided each day to my own work, challenging the assumptions where they did not fit, and following the process far enough to see what emerged. For my use case, a personal agent is not simply a chatbot that remembers you. It is an operator-facing manager backed by explicit context, bounded authority, specialist systems, and evidence. That is the claim this post is trying to earn. I began with a personal dashboard and a simple question: what would an AI need to know about me to become genuinely useful? The curriculum works through personality, values, goals, risk tolerance, and decision-making. The most useful—and uncomfortable—exercise was a documentary-style interview covering my background, career change, failures, family, money, and what actually drives me. That became soul.md: a private canonical file describing how I think and operate. I then distilled it into soul.runtime.md, a smaller set of executable principles for practical agent use. Two of those principles have already changed the architecture: - Autonomy requires bounded authority, which exposed the weakness in my original agent design. - Correctness governs speed, which is why completion evidence now belongs in an append-only - Decision and Evidence Ledger rather than being reduced to a status flag. One lesson mattered more than the rest: More context is not automatically better. Stable identity, current project state, private history, operational knowledge, and evidence are different classes of information. They update at different rates and should only be exposed to agents that genuinely need them. The biggest change came when I reviewed which agent to build first. My initial choice was a Founder Intelligence Scout—monitoring AI tools, GitHub repositories, contracting opportunities, and founder tactics. After two separate research workflows, the problem became obvious. I already had specialised systems doing adjacent work:

How should an agentic trading system recover after losing its live market-data stream? I’m working through a problem in the supervised trading system I’m building and would be interested in how others would approach it. The system consumes live market data through a WebSocket. During controlled observation sessions, the connection can occasionally close unexpectedly. Reconnecting to the provider is the easy part. The harder question is: After reconnecting, how does the system prove that its view of the market is complete and trustworthy enough to resume making decisions? My current thinking is that a lost connection should immediately remove decision authority. The system can continue recording diagnostics, but it shouldn’t treat a successful reconnection as proof that continuity has been restored. A few possible problems remain after the socket reconnects: - Events may have been missed during the outage - The first messages received may not rebuild the full current state - Delayed or duplicate events may arrive - Subscriptions may not match the original session - Indicators may have been calculated from an incomplete sequence - The agent’s previous thesis may no longer be valid - Broker or position state may have changed independently The recovery path I’m considering looks something like this: 1. Mark the live stream unhealthy and suspend decision authority. 2. Record the disconnect reason and last accepted event. 3. Open a new connection with a new connection-generation identity. 4. Authenticate and restore the required subscriptions. 5. Backfill the missing market-data window through an independent source. 6. Deduplicate and reorder events where possible. 7. Rebuild indicators and the current market snapshot. 8. Reconcile positions and outstanding orders independently. 9. Re-evaluate the previous thesis using fresh information. 10. Restore authority only after explicit continuity checks pass. The design question I’m still wrestling with is what evidence should be considered sufficient to restore authority.

Who watched/attended live THE BIG EVENT by Lewis? I think this community could give some honest feedback. 💰What were the expectations? 🤖What were the thoughts during the event? 👉🏼Have you stayed till the end? What do you think overall about Louis' big event?😉 Let's be transparent. I think that feedback, good or bad, is always valuable for the creator themselves.

Trader working toward consistent income using a 10 EMA strategy. Building alerts and automation so I can manage trades while working 8–5. Comfortable with TradingView, newer to Claude Code and agents. Goal is a system that handles analysis, journaling, and eventually execution.