KabuForge did not start as KabuForge.
It did not even start as a single project.
It started as a folder full of Google Colab notebooks.
I had been experimenting with vibe coding, mostly with Gemini, and wanted something concrete to build. Investing was an obvious subject because I was already interested in testing stock-selection ideas.
At the beginning, there was no plan to build a quantitative research framework. I was learning what I could make by describing an idea to an AI, running the code, seeing what broke, and asking it to fix the next thing.
That was enough.
And, for a while, it worked surprisingly well.
One notebook for every idea
One of my earliest experiments, in March 2026, was a simple quality-factor notebook.
The workflow was simple: upload a stock universe, download data through yfinance, calculate a Quality Factor, rank the stocks, and export the result.
When I wanted to try another idea, making another notebook was the easiest option.
So I did.
By the middle of March, I had separate notebooks for quality, value, attention, reversal and building a stock universe. Each was a small tool for one research idea: get the data, calculate a signal, rank the stocks and export the results.
There was nothing wrong with this approach. In fact, that was why it grew so quickly.
If I had an idea in the evening, I could have a rough implementation running in Colab without first deciding where it belonged in some larger software architecture.
At that stage, speed of experimentation mattered much more than software design.
Then the notebooks started becoming applications
The problem with a notebook is not that it cannot do very much.
The problem is that it can do surprisingly much.
That makes it very easy to add one more thing.
By early April, I had another Colab notebook for NISA and portfolio backtesting. It used yfinance, interactive widgets, benchmarks, exchange-rate data, XIRR, drawdown and Sharpe calculations, portfolio allocation and rebalancing.
Most of the application eventually lived inside one very large code cell.
It was ugly in the way that useful prototypes are often ugly. But it worked, and that made it tempting to keep adding to it.
A couple of weeks later, another notebook had become something called JP Equity Rebalance Control Tower.
By then the situation was very different.
Japanese equity data was moving toward J-Quants. Historical data was being cached. I was thinking about TOPIX universes, point-in-time pools, factor composition, weekly and monthly backtests, holdings simulation and benchmarks.
The notebook itself was no longer enough to contain the logic.
To start the Colab environment, I was uploading a ZIP file containing reusable Python modules for factor calculations, historical data, caching and backtesting. The notebook was gradually becoming a way to launch and coordinate those modules.
In retrospect, that was probably a fairly obvious sign that I was no longer building notebooks.
I just had not admitted it yet.
Why I moved away from yfinance and Colab
As the research became more serious, two things started bothering me.
The first was data.
yfinance is great when the goal is to get something running quickly. For the kind of Japanese equity research I was beginning to do, however, I ran into enough issues with coverage and consistency that I did not want it to remain the core data source.
The second problem was speed.
Some experiments took far too long.
How much of that was caused by yfinance, and how much was caused by the code Gemini and I had produced while I was still learning how to work with AI-generated code, I honestly cannot say.
Probably both.
I even went through the usual stages of adding parallel downloads, retries and shorter request intervals to make the notebooks less painful.
Eventually, moving the research to a local environment made more sense than continuing to optimize around Colab.
Around the same time, I started using J-Quants more seriously.
That became the beginning of the first proper local project.
The local project solved one problem and created another
Moving local helped a lot.
Data could be cached. Repeated operations became reusable modules. Factor calculations no longer needed to be copied between notebooks. Backtests became easier to run repeatedly.
For a while, this felt like the obvious solution.
Then the number of experiments exploded.
At the time I was using the J-Quants Standard Plan, and I eventually accumulated more than a hundred raw factors.
Some were useful.
Some were experiments that went nowhere.
Some were slightly different definitions of ideas I had already tested.
Strategies multiplied in the same way.
The project could do more and more, but I increasingly had trouble answering very ordinary questions.
What exactly was this factor measuring?
Was this the version I used in the previous experiment?
Which strategy still depended on it?
Was this parameter change actually a new research idea or just another variation I would forget about next week?
The difficult part was no longer implementing another factor.
The difficult part was keeping track of the research.
Letting agents operate the CLI
Once the system had enough factors, strategies and parameters, manually operating everything through the CLI also became tedious.
So I increasingly let agents do it for me.
This was useful.
I could describe an experiment and let an agent handle commands, configuration changes and repeated runs. It removed a lot of mechanical work.
But after doing this for a while, I noticed something I did not like.
The more I delegated to the agent, the less involved I felt in my own research process.
A run would start. Parameters would change. Outputs would appear.
Technically, everything was working.
But I was sometimes looking at the final result without having a good mental picture of the path that produced it.
I did not want to go back to manually typing every command. That would miss the point of automation.
I also did not want the agent to become a layer that hid the research system from me.
That tension ended up influencing KabuForge quite a lot.
Rebuilding the project without a grand plan
KabuForge did not come from one big architectural breakthrough.
I started by cleaning up the project.
Then one question led to another.
What exactly should a Factor receive and return?
Where should a Strategy end?
When does a Strategy become a portfolio?
Where should risk constraints be applied?
How should a research decision become an order plan?
If I repeat an experiment six months later, what information do I need in order to understand what actually ran?
Should a run started from the GUI mean something different from one started from the CLI?
And if an agent starts the same run, should that suddenly become a different research process?
The answers gradually produced clearer boundaries.
Today the main decision flow can be described roughly as:
Data → Factor → Strategy → TargetPortfolio → Risk → Planner → OrderIntent
The important part for me is not that all interfaces execute exactly the same code path in every circumstance.
It is that they operate under the same research and decision semantics.
A human using the GUI, a developer using the CLI, and an agent using MCP should not silently be doing three different kinds of research.
That was the point where JP-Equity-Backtest-Console no longer felt like the right name.
The project had become something else.
I renamed it KabuForge.
The boring parts became more interesting
Earlier in the project, I was mostly interested in finding another signal.
Later, I started spending much more time on things that look boring from the outside.
For example: when was a piece of financial information actually knowable?
It is easy for historical data to exist today. That does not mean a strategy running three years ago should have been allowed to see it.
KabuForge therefore treats decision-time visibility explicitly. Data can carry an available_at timestamp, and later information is gated from earlier decisions.
The same happened with reproducibility.
A backtest result by itself is not particularly useful if I cannot later tell which data, factor definition and configuration produced it.
So identities, run evidence and research artifacts became part of the system rather than something I tried to reconstruct afterwards.
Execution created another class of problems.
An order is not always simply “filled” or “failed.” Sometimes the honest state is that the system does not yet know what happened. KabuForge models that uncertainty explicitly rather than assuming that retrying an unknown submission is always safe.
None of these ideas is very exciting compared with discovering a new factor.
I now think they matter more.
AI was there from the beginning, but its role changed
There is one slightly strange thing about calling KabuForge “agent-operable.”
AI was involved almost from the first notebook.
I was using Gemini to help write code before KabuForge existed.
But AI-assisted development and agent-operated research are different things.
The early workflow was basically:
I describe something → AI writes some code → I run the notebook.
Later, the question became:
How should an agent interact with an existing research system without bypassing its rules?
KabuForge's answer is to treat the agent as another client.
The GUI, CLI and MCP interface all sit above the same application boundary. The agent can inspect factors, validate research specifications, run backtests, compare experiments and inspect evidence without being given a special route around the domain model.
I did not want to put a chatbot on top of a backtester.
I wanted the research environment itself to be operable by agents.
Those are different goals.
What KabuForge is today
When this article was first written on 1 October 2026, the public release candidate was v0.1.0-rc.1. The account below preserves that historical snapshot. See the KabuForge project page for the current release status.
KabuForge currently includes:
- point-in-time-aware factor research
- registered Factor and Strategy contracts
- historical backtesting
- local paper simulation
- portfolio and risk handling
- broker-neutral order planning
- CLI and desktop GUI interfaces
- bounded MCP access for agents
- research evidence and reproducibility mechanisms
It does not currently submit real broker orders.
Broker protocol mappings and validation exist as a separate layer, but external order submission is deliberately disabled in this release candidate.
That boundary matters to me. I would rather describe what the project actually does than make the roadmap sound like a finished feature.
Still the same experiment
KabuForge looks very different from those early factor notebooks.
But I still use it for essentially the same reason I opened those Colab notebooks in the first place.
I have an idea about the Japanese equity market, and I want to find out whether it survives contact with data.
The difference is that I now care much more about the path between the idea and the result.
What information was available?
What definition did I actually run?
What changed between two experiments?
Can I reproduce it?
Can an agent help without making the process less visible to me?
I did not know I cared about those questions when I started vibe coding in Colab.
I had to build a fairly messy project first.
KabuForge is what came out of cleaning it up.
The project is open source and still evolving.
GitHub: KabuForge Website: kabuforge.com
KabuForge is research and simulation software, not investment advice.