By Billy P. · Founder Notes #1.
Written from Blackpool, UK. Probably while you read this.
It’s too long. I know.
I did something this weekend that I never really expected to do when all of this first started.
GCF became an actual company.
GCF FramWorks LTD now officially exists.
That still feels strange to write because none of this started as a business idea. There was no pitch deck. There wasn’t a plan to raise investment. There wasn’t even really a plan for GCF. It started because in 2020 I had an accident and broke my back. I spent a lot of time recovering, and like a lot of people during that period, COVID also meant life had slowed down and changed completely.
I suddenly had a lot of time to think.
Probably too much time.
And during that recovery I started thinking about something I had wanted for years.
My own AI assistant. Not just a chatbot. Not something where I open a website, ask it a question, and then close the tab again. I wanted something that could actually be there with me. Something that could remember things. Something that could help me when I was working on something. Something I could talk to when I needed information. Something that could understand the way I worked instead of me having to explain everything again every time I used it. Something that eventually might be able to control parts of my computer, help with projects, manage tasks, and actually become useful in everyday life.
That idea became ISAC.
At the time, though, I didn’t really know what ISAC was going to become. I just knew what I wanted it to feel like.
ISAC started while I was recovering
Looking back now, I think the accident probably had more influence on ISAC than I realised at the time.
When you’re suddenly forced to stop doing the things you normally do, you start noticing all the little things that would be easier if you had some help. And I don’t necessarily mean someone physically doing things for you. Sometimes it’s remembering something. Finding information. Keeping track of what you’re working on. Helping you think through a problem. Being able to say something instead of sitting at a keyboard trying to find it yourself.
I kept thinking about what it would be like to have an assistant on my computer that actually knew me. Not in some creepy way. Just something that could build context over time. If I was working on a project yesterday, it would know what I was talking about today. If I had a particular way of doing something, it could learn that. If I needed help with a task, it could actually help rather than just giving me a paragraph of text explaining how somebody else could do it.
That was the dream. And honestly, at the beginning, it was probably massively unrealistic. But that’s usually how these things start. You have the version in your head first. Then you slowly discover all of the horrible technical problems standing between you and it.
At first I thought the model was the answer
When I started thinking seriously about ISAC, my assumption was probably the same assumption a lot of people have when they first think about building AI.
You need a really intelligent model. That seems obvious. If the model is smarter, the assistant will be better. So I started looking at models, how they worked, what hardware they needed, what was becoming possible.
Then AI started moving ridiculously quickly, especially after 2022. Suddenly everybody was talking about large language models. Every few months there was something new. Bigger models. More parameters. Better benchmarks. Huge GPU clusters. Massive investment. Bigger data centres. And I was watching all of this while still thinking about the assistant I originally wanted to build while recovering from my accident.
The problem was that the further I got into ISAC, the more I started asking practical questions that nobody seemed to be asking in the same way. Like, ok, even with a smart model how does it actually remember something from six months ago? That alone is a whole engineering problem. And what is it allowed to access. What happens when it wants to use a tool who decides whether it can actually modify a file. What about contradictions, where two pieces of information disagree. Memory in particular gets weird because real life doesn’t have a single ground truth. And the compute question how much compute should one task be allowed to use. And what happens when the model gets something wrong, which it will, how does the system actually recover from that. And the obvious one, how do you stop it.
None of those were really model problems. They were system problems. And the more I tried to solve them in code, the more I realised the model was only going to be a small part of the answer.
November 2023
By around November 2023 I’d reached a point where ISAC itself wasn’t the real problem anymore. The more I worked on the project, the more I started looking sideways at how AI systems were being built generally.
AI was exploding. There was a new model every week. New benchmarks. New training clusters. New press releases about how many GPUs someone had. New announcements about parameter counts and training compute. Obviously scaling works. I’m not going to pretend it doesn’t. Bigger models, more compute, better training. Real improvements.
But it had started feeling like the industry had reduced intelligence down to one equation. More power equals more intelligence. More GPUs. More parameters. More training runs. More infrastructure. More energy. Bigger data centres. Do it again. And again. And again.
And I kept looking at that and thinking, surely there is another part of this. Something we’re missing. What about the system around the model? What about deciding when a large model is actually needed? Memory? Specialised reasoning? Permissions? Tool access? Resource limits? Different models for different jobs? Learning which approach worked previously instead of treating every request like it had never happened before?
And the big one: what happens when the AI is capable enough to actually do things in the world? When it stops being a chatbot and starts being an agent? Because that question got heavier the further I got into the project.
Intelligence and authority are not the same thing
This is one of the ideas that sits closest to the centre of GCF.
I think AI development sometimes mixes up two completely different things. Intelligence and authority. If a model becomes better at reasoning, why should that automatically mean it gets more access? Why should a smarter model automatically be allowed to use more tools, see more files, hold more memory, call more APIs, sit in more systems? Those aren’t intelligence decisions. They’re authority decisions. We should be treating them separately.
A model might be incredibly capable. That doesn’t mean it should be able to do whatever it wants.
Quick example of something we’ve been testing inside GCF. Imagine an AI agent has some access to a computer. A request comes in that includes something destructive deleting config, changing system settings, shutting something down. The system shouldn’t run the request and then ask whether that was a good idea. It shouldn’t rely on the model remembering that it probably shouldn’t. There has to be a boundary before execution.
That’s what the governance layer in GCF does. A destructive request enters the system. GCF sees that the request involves a system-changing action. The governance layer evaluates it. Decision comes back: block. Execution returns before the request reaches anything that could actually do damage.
I’m being careful here. It’s still an internal synthetic test. It is not proof that we’ve solved AI safety. It is not proof GCF is production-ready. But it is proof that one of the architectural ideas I’ve been talking about for years now exists as working code. That matters to me. It’s the difference between having a diagram and having an artefact.
GCF stands for Governed Cognitive Framework. Originally most of this was just the architecture underneath ISAC. But at some point I realised what I was building wasn’t really specific to ISAC.
ISAC could use it. So could other AI systems. The model could change. The tools could change. The hardware could change. The use case could change. The governance architecture could stay.
That was the moment I started thinking about GCF as its own thing. The model became one component, rather than the entire AI. And that distinction matters. When people talk about AI they often talk as if the model is the system. But once you start building anything serious you realise very quickly that it isn’t. You have the model. Then memory. Then tools. Then routing. Then state. Then permissions. Then resource allocation. Then logging. Then fallback behaviour. Then recovery. Then governance. Then human control. Then potentially multiple models doing completely different things.
The model is the most important piece, but it’s still one piece. GCF is my attempt to build the architecture around all the pieces.
Which is probably why the next thing I started designing ended up looking weird.
Yes, there are really chess pieces inside it
This is the bit where people who haven’t followed the project think I’ve lost the plot.
The GCF architecture uses ideas based around a cube and chess pieces. Pawn. Knight. Bishop. Rook. Queen. King.
Sounds weird until you understand why they’re there. Different types of reasoning shouldn’t behave the same way. A factual retrieval problem isn’t the same problem as coming up with a creative alternative. A procedural task isn’t the same as analysing patterns. So instead of pretending one reasoning process is good at everything, the architecture can have different reasoning roles.
A Pawn deals with straightforward factual work. A Knight looks for unusual approaches. A Rook focuses on procedures and structured execution. A Bishop looks for patterns. A Queen brings information together. The King sits around constraints and governance.
These are names for architectural roles, not little virtual chess pieces running around inside the computer, although that would honestly look cooler and I’d watch a demo of it. The cube itself organises different areas of cognition, state, and escalation. And as the project has developed those ideas have become considerably more complicated than the original versions there are now concepts around inner reasoning, escalation, resource budgets, memory lifecycle, recursive processing, governance, the relationships between those, none of which appeared overnight. It’s basically been years of one problem leading to another until eventually the architecture stopped being a diagram and started being a thing I could run.
Why efficiency became such a big part of GCF
Part of this philosophy came out of necessity. I’m a solo developer. I don’t have a giant compute cluster. I don’t have a research lab. I don’t have thousands of GPUs. I don’t have millions of pounds to spend training something just to find out whether an idea works. I’ve been building this with what I can actually get access to, which means whatever I can run on my own machine, or rent by the hour when I really have to.
When your resources are limited you start asking different questions. Does every request actually need the biggest model available? Probably not. If something simple can be handled by a smaller model, why waste a much larger one? If one specialist is good at a specific kind of task, why send every problem through the same general-purpose system? If the system already knows what approach worked previously, why start from zero every time? If a task doesn’t justify a large compute budget, why give it one?
That’s where “smarter for less” started becoming important to me. I want to be clear about what I mean by that, because people assume the worst when they hear it. I’m not saying compute doesn’t matter. It obviously matters. I’m not saying larger models aren’t valuable. They clearly are, and I’m going to keep using them where it makes sense. I’m saying I don’t think scaling the model should be the only thing we optimise, and I don’t think the architecture around the model should be treated as plumbing that someone else has already figured out. A lot of the time I think we just haven’t tried very hard on that part yet.
I want to find out how much additional capability we can squeeze out of the hardware we already have by improving the architecture around the model rather than just making the model bigger. Sometimes the right answer is going to be: use the massive model. But sometimes it’s going to be: you don’t actually need it, and the system itself should be able to tell the difference.
why I think this matters now
A few years ago most people interacting with AI were basically chatting to it. You typed something. It responded. That was mostly the end of the interaction.
That’s changing. Now we’re talking about agents. AI browsing websites. Writing code. Running tools. Calling APIs. Accessing files. Using terminals. Remembering things. Operating computers. Taking actions in other systems.
Once AI stops simply giving you an answer and starts doing something, mistakes become different. A hallucinated sentence in a chatbot is annoying. A hallucinated system command being executed on real infrastructure is a completely different problem. Different problem, different stakes, different responsibility.
Which is why I keep coming back to capability not having to equal authority. You can build an incredibly intelligent system and still put boundaries around what that intelligence is allowed to control. In fact the more capable these systems become the more important those boundaries get, not less.
I want to be honest about what hasn’t been proven
Something I want to be careful about as GCF becomes more public. There is a huge temptation in tech to talk about everything as if it’s already finished. Especially in AI. Everything is revolutionary. Everything changes the world. Everything solves some enormous problem. I’m trying not to do that.
GCF is still under development. ISAC is still under development. We’re currently around stage 35 of the roadmap. There’s a lot of work ahead. There are parts that still need proper external validation. There are parts that may need redesigning. There are assumptions that testing might prove wrong. There are things I haven’t built yet. There are probably bugs sitting in the code right now that I don’t even know exist.
That’s normal. I’m building something. I’m not writing a story where everything magically works first time.
What has changed is the project has reached the point where I have evidence instead of just ideas. Benchmarks. Tests. Governance behaviour. Resource measurements. Working implementation. That’s why I’ve become more confident about taking the next step.
So why a startup now
Because eventually I had to decide whether this was always going to remain something I built privately, or whether I actually wanted to find out what it could become.
And I want to find out. That’s basically the whole answer.
I still have the passion for it. I still enjoy building it. I still find myself thinking about architecture at stupid times of night. And I realised that if I’m serious about taking GCF and ISAC further, eventually I need resources that I can’t realistically provide myself forever. Better compute. Hardware. Testing. Security review. Infrastructure. Potentially other people. Legal work. Model research. Eventually training our own models.
Most importantly, time.
The project has been personally funded for years. I’ve spent thousands of pounds of my own money on it since around 2023. There comes a point where bootstrapping something like this becomes incredibly difficult.
So this weekend I decided to take that step properly. GCF FramWorks LTD became a company.
Which means I’m now talking to investors. That sentence still makes me laugh. Because this all began with me lying on my back doing nothing, thinking about how useful it would be to have an AI on my computer. And now I’m making investor decks.
Life is weird.
But yes, I’m currently exploring funding. The plan is to raise enough to push development through the next major stages, keep working towards ISAC Core v1.0, improve testing, get independent validation, and start moving towards something developers can actually use.
Funding would also help with another part of the long-term plan I keep thinking about: our own models. GCF is designed to be model-agnostic. I don’t want the whole system tied to one provider. That means it could work with third-party models, local models, and eventually models designed specifically around the GCF architecture. Long term I’d like to train specialist models that are extremely good at the role they’re supposed to play, rather than trying to make every model brilliant at everything. Those models could eventually be available through GCF as part of the platform.
That’s a long-term goal. We’re nowhere near claiming it exists today. But it’s part of where I think this can go.
From a broken back to a company
There is something slightly surreal about all of this when I think about where it started.
In 2020 I was recovering from breaking my back and thinking about how useful it would be to have my own AI assistant. I wasn’t thinking about building an AI framework. I definitely wasn’t thinking about incorporating a company. I just wanted to build ISAC.
What happened after that was, I think, the more honest version of how a company actually gets made. I didn’t sit down and decide to make a business. I kept trying to build ISAC and kept running into problems that didn’t have good answers in the existing tooling. Memory had no good model. Governance had no good model. Permissioning had no good model. So I started writing the missing pieces myself. The missing pieces turned out to be more interesting than the original assistant. The architecture got bigger than ISAC. I called that GCF. GCF sat on my computer for a few years while I kept building. And then this weekend I incorporated it.
That’s not a story about a five-year plan. It’s a story about one problem leading to another leading to another. And I think that’s actually the better way to make a company, if you’re going to make one. Because GCF wasn’t created because I went looking for something that might sound good to investors. It exists because I was trying to build something for myself and kept hitting walls that the existing approach didn’t solve the way I wanted.
Now I want to find out whether those walls are walls for other people too.
ISAC is still the point
Turning GCF into a company doesn’t mean ISAC suddenly disappears. Quite the opposite. ISAC is still incredibly important. It’s the first real implementation of the framework. It’s where these ideas get tested together. Memory. Governance. Reasoning. Model routing. Resource management. Tools. State. Personality. Eventually voice. Eventually more autonomy. Eventually, hopefully, the kind of assistant I imagined while lying on my back in 2020.
ISAC is basically the place where GCF has to prove it can survive contact with reality. If an idea looks brilliant on a diagram but falls apart when ISAC tries to use it, the architecture has to change. That’s one reason I think building ISAC alongside GCF has been useful. I’m not designing the framework in isolation. I’m constantly trying to build something with it.
The company doesn’t actually change much
Tomorrow I’ll still be sitting at my computer doing exactly what I was doing last week. Writing code. Running tests. Breaking something. Wondering why it broke. Fixing it. Breaking something else. Changing an architecture document because the code proved the architecture was wrong. Running another benchmark. Probably arguing with myself about whether something should be a Pawn or a Bishop.
The company doesn’t magically make GCF successful. It just gives me a structure to try. And hopefully it gives me a better chance of eventually getting the resources the project needs.
I’m nervous about it
I don’t mind admitting this. Putting something you’ve spent years working on in front of other people is terrifying, and the reason it’s terrifying is that when the project is private it belongs to you, you can believe in it without anyone else having an opinion, and you don’t have to defend any of the choices you made at 2am that you probably wouldn’t make again in daylight. That part of the work is over now.
Investors are going to look at it. Developers are going to look at it. People who know far more about certain areas of AI than I do are eventually going to look at it and most of them are going to have notes, which is fine, that’s the point of showing it. Some people will probably love the idea. Some won’t understand it. Some will think the architecture is overcomplicated. Some might think I’m solving the wrong problem entirely. Some investors will reject it because the timing is wrong, or because the space is too crowded, or because they don’t like the chess pieces metaphor that last one is going to happen, I can already tell.
I’m not expecting everyone to look at GCF and immediately decide I’ve discovered the future of AI. That would be ridiculous, and if that happened I’d probably be more worried than flattered. What I want is the opportunity to prove the ideas properly. If they work, brilliant. If parts don’t work, I want to know why because at this stage I’d rather know now than in another two years. If something completely different comes out of all this research, that’s useful too.
The worst thing I could do right now is spend another five years secretly building something because I’m scared somebody might tell me it isn’t good enough. Eventually you have to let the idea meet the real world. I think I’ve reached that point. Probably past it.
I don’t think the AI industry is “wrong”
I want to clarify something because I’ve said before that I think AI development is heading in the wrong direction. That was probably too simple.
I don’t think companies building enormous models are stupid. Clearly they’re not. I don’t think scaling models is pointless. It has produced some of the biggest breakthroughs we’ve seen. What I’m challenging is the idea that scaling is the only important path. I think there’s another layer of innovation available. Architecture. Governance. Specialisation. Resource allocation. Memory. Model orchestration. Authority. How all these systems fit together. That’s the part I want GCF to explore.
So maybe the better way of saying it is: I don’t want to prove everyone else wrong. I want to prove there might be another way as well.
Where I hope this eventually goes
The dream is bigger than where the project is today. Eventually I want ISAC to become the assistant I originally imagined. A genuinely personal AI system. Something that can work locally. Something that remembers. Something that understands context. Something that can use different models and reasoning approaches depending on the problem. Something useful enough that people actually want it running alongside them every day.
Beyond that, I want GCF itself to become available infrastructure. If another developer wants to build an AI agent, I don’t think they should have to rebuild governance, permissions, memory, auditing, and resource management from scratch every time. I’d like GCF to be the layer they build on. Maybe through APIs. Maybe through enterprise deployments. Maybe through local versions. Maybe through specialist models. The details will evolve. That’s the direction.
for now there’s still a lot of work to do
This isn’t the end of the story. It’s barely the beginning of the public part of it. Right now I’m still building. Still validating. Still trying to close out the current development stage. Still trying to work out what survives into the final architecture and what needs throwing away.
The funding process has started. Two investor applications are currently out. More will probably follow. Maybe somebody believes in it enough to invest. Maybe it takes a while. Maybe I hear no a lot more than I hear yes. I’m prepared for that.
Regardless of what happens with the first investors I speak to, I’m still interested in the questions that started all of this. Whether we can build AI differently. Whether you can get more from hardware you already have instead of always assuming the answer is more compute. Smaller specialists where they make sense. Different kinds of reasoning working together instead of one model handling everything. Memory as part of the architecture rather than just being a really long prompt. Letting an AI become more capable without automatically giving it more control. Governance that lives inside the runtime instead of being a document somebody writes after the system is built. Systems that are easier to understand and easier to stop when something goes wrong.
I don’t know yet. That’s the whole point. I want to find out.
So yeah. GCF is a startup now. That’s where we’re at.
Something that started during COVID with me on my back recovering from a broken spine eventually became ISAC. ISAC forced me to think about the architecture underneath it. That architecture became GCF. GCF became something I spent years developing on my own. And this weekend I finally decided to see whether it could be something bigger than a project sitting on my computer.
I’m still solo. Still learning. Still building. Still an enormous amount I need to prove and probably a few things I’m wrong about that I haven’t found out yet.
But for the first time, GCF has a company behind it. So we’ll see what happens. I’ll write the next one of these after the first investor conversations close out, whatever the answer turns out to be.
— Billy P.
This is the first post in Founder Notes long-form updates on what it’s actually like to try to build something like this from scratch. Less engineering, more journey. The next one will be after the first round of investor conversations close out, whether that goes well or badly.
Tested on the GCF 2.0 frozen framework, SHA eeae2bc8a426b063c687e40f9724adbb1dc3a61a. The company is new. The architecture remains.