The hardest part of my AI trading bot was the software around it

I built a trading bot for part of my own portfolio. After about six weeks of backtesting, paper trading and fixing bugs, it made its first real trades. The AI that decides what to own is only one of five core parts. Much of the difficult work was in the four conventional parts around it.

That experience changed how I want to build software. If you have a job whose inputs change but whose result you can check, try giving an agent a goal, principles for unfamiliar cases, examples, and a check for its work. Building this bot showed me why that structure matters.

What the five parts do

1. One program collects long research articles and preserves revisions.
2. Another collects shorter updates and the conversations around them.
3. A price service prepares market history and current quotes.
4. An AI reads a saved snapshot of the research, prices and bot-owned portfolio, then writes a proposed portfolio decision.
5. A broker service checks that decision, places the orders it can afford, and records what actually happened.

The bot and I use the same physical broker account, so the software must also keep our separately owned shares and cash straight. The AI makes the portfolio decision; the other parts currently follow written rules to gather its inputs and carry out its request.

Why the rules around the AI took so much work

A broker order is not a single, tidy reply. A sale can fill in pieces. An order acknowledgement, fill and fee can arrive at different times. A later download can repeat a record the bot has already seen. The account software must keep my trades and the bot's trades separate before it calculates what the bot can use.

During paper testing, repeated broker records made an account update take many minutes. While that update ran, a fresh account view was unavailable. Other cases involved a fee arriving after a fill and money reserved for a currency conversion leaving too little for a planned share purchase. Each surprise meant finding the real sequence, correcting the program, and testing that the correction did not break another sequence.

The first live runs surfaced fresh cases too. A setup check stopped one run before the AI started. A later account check could not rebuild the bot's ownership record because a previous currency conversion lacked a saved exchange rate. The software stopped rather than guessing, and the case needed investigation.

The lesson is broader than trading. In this bot, the fixed programs had to recognize each new variation. When they could not, I returned to the code. The combinations multiplied quickly.

Give the changing part a job, not a list of every possible case

I now want to build more of those jobs as specialised agents. Instead of telling a collector where every field will appear, I could give it a result to produce: find the new material, preserve the original, identify what changed, and hand the next role a complete, dated record. If a page moves or a response arrives in an unfamiliar order, the agent can inspect what is in front of it and decide how to reach that result.

The work does not vanish. It moves: instead of coding every possible exception before launch, I define the job and checks, then improve the agent's guidance when a real exception appears. I expect to spend less time encoding cases up front and more time reviewing results and improving the agent's tools as I learn.

Today, four of the bot's five core parts are still conventional software. Replacing them with agents is a direction I want to explore, not a feature I have already shipped. Whatever does the work must still show where its facts came from. Before real money moves, the system must check the account, ownership, available cash and exact order; afterward it must check what the broker actually filled. An agent can help with those jobs, but its confidence cannot substitute for the broker's record.

I learned the same way to delegate at FunnelBud

When I built FunnelBud, I could not write a script for every situation an employee would face. I gave people roles with goals. I wrote down principles for making decisions and attached examples to each one. We practised with role plays and discussed what a better response would have looked like.

When someone made a choice I did not expect, I asked how they had reasoned. Sometimes the goal was unclear. Sometimes a principle was missing or wrong. Sometimes the example taught the wrong lesson. I updated that part of the guidance, then used it in training. The internal portal holding those role guides improved through real work.

That gives me a useful order for instructing an agent too: first the goal, then the principles for handling unfamiliar situations, then examples that show those principles in action. Examples alone cannot cover the future. The goal and principles help it reason when the next case looks different.

Try this with one job you can check

Pick a small task whose inputs vary but whose result you can inspect. Suppose you want an agent to turn weekly customer questions into a list of problems to investigate. Give it:

1. A goal: “List the recurring problems our customers described this week so I can decide what to investigate.”
2. Principles: keep different causes separate, use customers' words as evidence, and mark unclear cases instead of guessing what they meant.
3. Examples: in this invented example, one customer says, “I cannot tell whether my invoice was sent.” Another asks, “Where can I check if the invoice went out?” A supported summary is “Two customers could not see whether an invoice was sent,” linked to both questions.
4. A check: every proposed problem links back to the original questions. If the agent cannot tell which problem a question describes, it asks rather than filling the gap itself.

Try it on work you have already seen. Look at the first answer that surprises you. Ask whether the agent misunderstood the goal, applied the wrong principle, or needed a better example. Improve that layer and try again before giving it a more consequential job.

My bet is that more software will be built this way: people owning a set of specialised agents, the instructions that guide them, and the record of what they did. That is part of why I care about people and companies owning the intelligence they depend on. The bot is one place where I am learning what that takes.