One of the things I keep coming back to with AI content is that the AI itself isn't really the interesting bit anymore.
Anybody can ask an AI to write an article about a stock.
What interests me far more is giving it access to information that everybody else doesn't have.
That is what I've been building around InPlay.finance.
First, what is InPlay.finance?
InPlay is a stock discovery and analysis system I've been developing for years.
The basic idea is to identify stocks that are experiencing unusually interesting activity during the trading day.
Rather than looking through thousands of companies trying to work out where something is happening, InPlay watches the market and surfaces stocks showing characteristics that might make them worth investigating.
That could involve unusual trading volume, significant price movement, gaps, news activity and other market behaviour.
But the important thing for this particular build is what happens to all of that information afterwards.
InPlay has been quietly building a history
Every trading day, InPlay gathers and stores information about what it sees.
Over time, that has created a fairly substantial historical record.
It knows when stocks have appeared In-Play before.
It has information about their relative volume, price movements, gaps and the conditions surrounding those appearances.
It can also retain market snapshots, historical news references and information about what happened to a stock in later trading sessions.
Originally, most of that information existed because it was useful to the application.
Then I started looking at it from a completely different angle.
There are potentially thousands of useful questions hidden inside that history.
The data can answer questions people actually ask
Imagine a stock suddenly appearing on somebody's radar.
They might search for:
- Why does this stock keep becoming active?
- Has this happened before?
- What happened after its previous periods of unusual activity?
- Was trading volume unusually high on previous occasions?
- How did the share price behave afterwards?
- What was happening around the company at the time?
Those are much more interesting questions than simply asking an AI to write "an article about Company X".
More importantly, they are questions InPlay may actually have information to help answer.
That became the starting point for this build.
I didn't want another automated AI blog
I could have taken the easy route.
Give an AI a ticker symbol, ask it to research the company and automatically produce an article.
But there is very little interesting about that.
Millions of websites can do exactly the same thing using exactly the same underlying information.
I wanted the starting point to be InPlay itself.
The article should exist because InPlay has observed something interesting.
And the evidence behind that article should come, where possible, from the history InPlay has accumulated from actually running every trading day.
That changes the role of the AI considerably.
Instead of asking it to invent a subject and then fill a page, I'm asking it to examine evidence and work out what useful question that evidence could answer.
Connecting InPlay to Control Room
To make that work, I've been building a new connection between InPlay and Control Room, the system I use to operate and manage my websites.
The important part for me was not simply giving Control Room direct access to a giant database.
I wanted InPlay to be able to explain what it knows.
Control Room can then discover useful historical information, examine selected records and provide a carefully limited evidence set to the AI responsible for producing the article.
That means the website itself remains the authority on its own information.
Control Room doesn't need to understand every internal detail of how InPlay works.
It simply needs a reliable way to ask InPlay for useful context.
The AI can now find the article
This is probably the part of the build I like most.
I don't necessarily have to decide the article topic first.
The system can look through completed InPlay history, find something genuinely interesting and then work out the strongest question supported by the available evidence.
For example, it might notice that one company has appeared In-Play repeatedly and ask why.
Or it might find a stock with several historical appearances and ask what happened in the sessions afterwards.
That gives me a much more natural route into AEO content.
Rather than starting with a keyword and trying to manufacture an article around it, the process can start with something the data can genuinely answer.
Building for AEO means building for questions
AEO, or answer engine optimisation, is something I've become increasingly interested in as Google and AI-powered search experiences change the way people discover information.
Traditional SEO has often encouraged websites to think in terms of keywords.
I'm increasingly thinking in terms of questions.
What is somebody actually trying to understand?
And does my website possess information that allows it to provide a genuinely useful answer?
InPlay is particularly well suited to that because the information isn't static.
It has been observing market behaviour day after day.
That creates opportunities for questions based on patterns, repeat appearances and historical outcomes that a conventional company profile might never address.
The difficult part wasn't generating the text
One thing this build has reinforced is that producing the words is probably the easiest part.
Making sure the AI understands the data correctly is much harder.
InPlay has terminology that makes perfect sense inside InPlay but can mean something completely different in normal financial language.
Early tests showed just how easily an AI could take a perfectly valid piece of data and give it the wrong interpretation.
That meant I had to spend time making the information clearer before it ever reached the writing stage.
Internal shorthand needed proper explanations.
InPlay classifications needed to be clearly described as observations rather than predictions.
Internal scores needed to be distinguished from probabilities or investment recommendations.
And historical information needed enough context for the AI to understand what it could and could not safely conclude from it.
It sounds like a small distinction, but I think it is one of the most important things I've learnt from the build.
More data isn't necessarily better
There is a temptation with AI to throw everything into the prompt.
I think that's often the wrong approach.
What I've been building instead is a way to provide a bounded set of relevant evidence.
If the article is examining several historical appearances for one company, the AI gets the information relevant to those appearances.
It doesn't need everything InPlay has ever stored.
That makes it easier to understand where statements have come from and much harder for the model to wander off into something unrelated.
It also means the finished article can stay focused on the actual question.
Stopping plausible nonsense
This has probably been the most interesting challenge.
AI is extremely good at producing explanations that sound completely reasonable.
Unfortunately, "sounds reasonable" and "the evidence actually says this" are not the same thing.
During testing, I found examples where the AI could see a historical piece of company news and reasonably assume that the same story explained another nearby period of activity.
It might even have been right.
But InPlay didn't have the evidence to prove it.
So the system now makes those boundaries much clearer.
If the historical record says news was involved but the original story hasn't been preserved, the article can say that news activity was recorded.
It cannot simply guess what the news was.
That is exactly the behaviour I want.
The point isn't to make the AI sound clever.
The point is to make the resulting article trustworthy.
First-party data is the interesting bit
The more I've worked on this, the more I've realised that this is the part of AI content I find genuinely exciting.
AI-generated content by itself isn't particularly special.
AI-generated content grounded in proprietary information can be.
InPlay has spent years accumulating observations because those observations are useful to the product.
I'm now building a second use for that same information.
During the trading day it helps power InPlay.
Once those sessions become history, the data can also help explain market behaviour through useful public content.
The article is another output of the product
That is a different way of thinking about a blog.
The editorial side of InPlay isn't something completely separate that needs feeding with random content ideas.
It can become another output from the same underlying product.
InPlay observes something.
That observation becomes part of its historical record.
Control Room can later discover something interesting within that history.
The AI can identify a useful question.
And the evidence can then be turned into a readable article that helps somebody understand what happened.
There is a nice loop to it.
It is also teaching me how to build for AI
There is another reason I've enjoyed this project.
It has changed the way I think about giving information to AI systems.
Building for AI isn't just about exposing data.
You also need to expose meaning.
The AI needs to understand terminology, relationships, limitations and where information came from.
Most importantly, you need to reduce the number of perfectly reasonable ways it can misunderstand what you've given it.
That is becoming part of the infrastructure I'm building into Control Room itself.
InPlay is the first really interesting use case because its data is unusually rich, but the concept doesn't have to stop with finance.
AEO built from something real
I think there is going to be an enormous amount of AI-generated content published over the next few years.
A lot of it will probably be completely interchangeable.
That isn't what I want to build.
If I am going to use AI to create content, I want the website behind that content to bring something to the table too.
With InPlay, that something is its history.
It has been observing stocks, recording market activity and building up knowledge long before I started thinking about turning any of it into articles.
Now I'm building the layer that allows that knowledge to become useful outside the application as well.
And that feels like a much more interesting version of AEO to me.
Not using AI to produce more pages.
Using AI to help a website answer questions that its own data puts it in a unique position to answer.
