Why I Created the Michael Sloggett AI Lab

SALES & EMPIRE · Michael Sloggett

Why I Created the Michael Sloggett AI Lab

For years the things I built lived in scattered places. A script that watched a market overnight. A dashboard a small team used and nobody outside ever saw. An automation that quietly removed a few hours a week of work I hated doing. None of it had a home. When someone asked what I actually build, I did not have a straight answer to give them.

Why I created the AI Lab

I created the Lab to fix that. It is a working archive of the AI systems, trading technology, automations and digital products I have directed, tested and developed. It is a record rather than a pitch, so the sensible thing is to Explore Michael Sloggett AI Lab and judge it yourself rather than take my description on trust.

This site is about me: the trading, the education, the writing, the years spent in the market. That is one thing. The build work is a different thing, and putting both in one place did neither of them any favours. A personal site answers who someone is. A project archive answers what they have made and what happened when they made it.

Separating them also forced a discipline I wanted. Once the work has its own site, every entry has to earn its place.

What the site documents

Each entry sets out the problem, the approach, the decisions taken along the way and the current state of the thing. Where a project is early, it says so.

I want to be accurate about my role, because this is the point where people overclaim. I am not the person writing every line of code. On most of this work I am the product creator, the domain expert, the operator and the director. I decide what gets built and why, I define what correct behaviour looks like, I shape how it should feel to use, I test it against real conditions, and I work with collaborators and with AI tools to get it finished. The judgement is mine. The engineering is shared.

Alpha Signals and the move from trading experience to working technology

Alpha Signals is the clearest example of experience turning into software. It began with a problem I had lived with: a screen full of information, very little of which was worth acting on.

Knowing the market well is what made the product possible at all. I could say which questions matter before a position is opened, which conditions should stop an idea outright, and where traders talk themselves into decisions they should have walked away from. Turning that into a system meant building something that holds those checks in a sensible order and shows its working, so the person reviewing an output can see how it got there.

In its current form the service runs the xs momentum engine, which ranks the whole crypto market every day and refreshes a long and short basket at 00:05 UTC, executing on each member's own exchange account rather than a pooled fund. That is the piece which has to hold up in public, on a fixed schedule, in front of people putting real money behind it. There is more on Alpha Signals and why I built it on that site.

That is also where the limits sit. A system can organise a decision and make it easier to examine. It cannot remove the risk inside that decision, and it cannot take responsibility for what a person chooses to do next. The longer account of how the product developed, version by version, is in How Alpha Signals became a working product.

The wider systems, automations, products and experiments

The range is wider than people expect, because the problems came out of running real operations rather than from picking a technology and hunting for something to point it at.

Around the trading work sits automation, and most of it is unglamorous. Things that move data between systems, catch a failure before a person has to notice it, or take a repetitive task away from someone whose hours are better spent elsewhere.

Then there are applications and websites, media and content work, and product experiments that exist mainly to answer a question. Some are live. Some were built, tested and put down because the honest answer was no. Those belong in the record too. A project archive holding only successes is a marketing page wearing a costume. The fuller inventory, and what I actually mean when I say I built something, sits in What I have built with AI.

Why I want the work documented honestly

There is a lot of noise in this space at the moment. Plenty of it is people describing capability they do not have, in language designed to stop you asking a second question.

I did not want to add to that pile. So the Lab shows the work and the reasoning behind it, including the parts that did not go well. That is a slower way to build credibility and it is the only version of it that survives contact with a reader who knows the subject. If you go through an entry and conclude the reasoning is faulty, you have enough detail in front of you to say so. I would rather have that conversation than be handed the benefit of the doubt.

The teaching background sets the standard here. Once you have taught people who then put their own money at risk, you get careful about what you claim. That habit carries straight into how the Lab describes its own work.