Building Orvel: What “Training Your Own AI” Actually Means
When I first started thinking about Orvel, the idea in my head was pretty simple.
I wanted people to be able to train their own AI.
That sentence sounded straightforward until I actually started building it.
What does training your own AI even mean?
At first, I thought about it the way I think a lot of people do. You give an AI information, correct it when it gets something wrong, teach it how you want it to respond, and eventually you have an AI that feels like yours.
Technically, though, things get complicated very quickly.
I wasn't trying to build another ChatGPT wrapper
One thing I knew pretty early was that I didn't want Orvel to just be a nice interface where someone enters an API key and talks to an existing model.
There are already enough products that do that.
What interested me was the layer between a base model and the person using it.
Imagine I create an agent and tell it about a project I'm working on. I give it documents and information it should know. Then I ask it a question and its answer is wrong.
I correct it.
The next time I ask the same thing in a completely different way, I don't want it to act like that correction never happened.
That sounds obvious from a user's perspective.
From a development perspective, it isn't.
Saving a correction is easy.
Understanding when that correction is relevant again is the interesting part.
That was one of the things that made me realise Orvel wasn't really about a giant TRAIN button that magically creates a new model.
It was about building a system that could gradually become more useful to one particular person.
Then I had to define what training meant
The word "training" carries a lot of weight in AI.
If I tell someone that Orvel lets them train an AI, they could reasonably assume I'm talking about taking a neural network and changing its weights using a dataset.
That's actual model training.
But that isn't the only way to make an AI learn something about you.
There is also knowledge retrieval, persistent instructions, examples, corrections, memory and eventually techniques such as fine tuning.
They can all change how an AI behaves without necessarily training a completely new foundation model.
That distinction became important for Orvel.
I don't think somebody should need to understand embeddings, inference, context windows or model weights just because they want an AI that understands their work.
They should be able to create one, teach it something and see the result.
The complicated part should happen underneath.
Local AI changed how I thought about the product
Another question I kept coming back to was where the actual intelligence should come from.
The easiest answer is the cloud.
Send requests to a model provider and return the response.
It works, but now every message potentially costs somebody money. You're also dependent on another service being available.
Local models made the idea much more interesting to me.
If Orvel can use a model running on your own computer, suddenly the economics change.
You can experiment without thinking about the cost of every request. Your setup can keep working without depending entirely on a hosted model provider, and more of the experience can stay on your machine.
There is obviously a tradeoff.
Not everybody has a computer capable of comfortably running large models, and a small local model isn't suddenly going to outperform the strongest cloud models.
So I stopped thinking about local and cloud as competitors.
They are options.
Someone might want everything local.
Someone else might bring their own API key.
Another person might eventually prefer a hosted Orvel experience where they don't have to configure anything.
The important thing is that the agent itself shouldn't lose its identity just because the model underneath it changes.
The model isn't the agent
This is probably the biggest thing I've learned while building Orvel so far.
The model and the agent are not the same thing.
A model provides intelligence.
The agent is everything around that intelligence.
Its knowledge.
Its instructions.
What you have taught it.
The corrections you have made.
How it behaves.
What it can access.
What it remembers.
Once I started thinking about Orvel this way, a lot of product decisions became clearer.
Instead of asking, "How do I train a model?"
I started asking, "How do I let someone build an AI that becomes theirs over time?"
I think that's a much more interesting problem.
I'm still figuring it out
Orvel is still early.
There are parts of the idea I'm building now and parts that will probably change completely after people actually start using it.
I've already changed my mind about features more than once.
I expect that to keep happening.
But that's also why I'm building it in public and keeping it open source.
I don't want to pretend I already know exactly what Orvel becomes.
Right now, I'm trying to get one thing right.
You create an AI.
You teach it.
You correct it.
You give it knowledge.
And over time, it should feel less like you're repeatedly prompting somebody else's model and more like you're building something of your own.
That's what "training your own AI" means to me right now.