In 2026, products like Moltbook made the idea of a social network populated by AI agents surprisingly tangible.
Before that wave, a friend and I got a request from a madman in early 2025 for almost the same idea.
That madman wanted a forum where AI agents could talk to each other and come up with solutions to problems humanity is facing. You'd have bounties attached to the problems being solved — say, X amount of dollars for coming up with a solution.
Guess he wasn't that much of a madman, considering how Moltbook eventually came to be.
The only difference was that what we built never made it to production. It remained a prototype.
But that prototype forced us into some of the same architectural problems agent systems are dealing with now, especially memory, context, persistence, and multi-model orchestration.
1. So what exactly were we building?
The concept was essentially a problem-solving forum populated by AI participants.
Someone could post a real problem, potentially attach a bounty to it, and multiple AI agents/models could discuss it rather than having a single model produce one answer.
The basic interaction looked something like this:
The important part wasn't that three models could independently answer the same question.
They were participants in the same discussion.
A response from one agent could become context for the others, turning a simple model call into an ongoing multi-agent conversation.
Conceptually, we were moving from:
Human → LLM → Response
to:
Human describes a problem → Multiple AI agents discuss it → Proposed solution
And that is exactly where things started getting interesting.
2. The architecture was surprisingly simple
For something that sounded this ambitious, the prototype architecture wasn't actually complicated.
We went with Next.js for the frontend and backend. Easy to use, no learning curve — we could trust it with our lives.
PostgreSQL — forum and application data.
Ollama — serving the open-source models.
RunPod — GPU compute.
Letta/MemGPT — persistent memory and context for the agents.
On paper, that was basically it.
But there was one problem with this architecture that wasn't obvious until you thought about what an AI forum actually means.
A forum can keep growing forever. An LLM's context window can't.
3. A forum can keep growing. An LLM's context window can't.
That's exactly where Letta/MemGPT came in.
We already had experience implementing RAG and using retrieval to ground LLM responses in relevant information. But this was a different problem.
These weren't supposed to be stateless models answering isolated questions.
They were participants in a discussion.
For that to work, an agent needed some way of remembering relevant information from earlier in the conversation without us continuously stuffing an ever-growing thread back into its context window.
And the longer the discussion became, the harder that problem got.
There was another, slightly more ridiculous problem:
The agents didn't necessarily know when to shut up.
An agent could respond to another agent, which could trigger another response, which could trigger another one.
In theory, you could end up with a discussion that just kept going.
Since this was a bootstrapped prototype running open-source models on rented GPU compute, an infinite philosophical debate between AI agents wasn't exactly something we wanted to pay for.
So yes, we literally had a force-stop conversation button.
It wasn't sophisticated orchestration.
It was basically us saying:
Alright boys, that's enough.
And that exposed two separate problems we needed to think about:
What should an agent remember?
and
When should an agent stop talking?
Those sound like product questions, but they very quickly become architecture questions.
4. PostgreSQL could store everything. The agents couldn't remember everything.
This was probably the distinction that took me the longest to properly appreciate.
We had PostgreSQL. Storing conversations wasn't particularly difficult.
Every thread, reply, agent, user, and timestamp could live in a database.
If a discussion had 10 messages or 10,000 messages, the application could persist them.
But just because the application remembers something doesn't mean the LLM does.
There are really two different questions here:
What happened in the application?
and:
What does this particular agent need to know right now?
PostgreSQL could answer the first one.
The second one was a context and memory problem.
The easiest way I found to think about it was:
PostgreSQL stored what happened. Letta/MemGPT helped determine what an agent needed to remember.
That distinction mattered because simply having access to an entire conversation doesn't mean you should send the entire conversation to the model every time it needs to respond.
As the forum grew, we'd potentially have hundreds or thousands of messages available in PostgreSQL.
The model didn't need all of them.
It needed the relevant parts of the discussion, whatever useful information it had retained, its own instructions, and enough recent context to understand what everyone was currently arguing about.
That was the role we wanted Letta/MemGPT to play.
The idea wasn't to magically give the underlying model a literally infinite context window.
It was to make the agent behave as though its memory could persist beyond whatever happened to fit inside a single inference request.
That gave us three very different concepts:
Storage: What has happened?
Memory: What is worth remembering?
Context: What does the model need to know right now?
Once I started thinking about them separately, the architecture made a lot more sense.
But memory wasn't the only problem.
We still had a bunch of AI agents sitting in a forum waiting to talk.
Which brings us back to that force-stop button.
5. Getting them to talk was easy. Getting them to stop was harder.
At first, multi-agent orchestration sounds pretty straightforward.
Agent A responds.
Agent B sees Agent A's response and has something to add.
Agent C sees both responses and adds another perspective.
Agent A now has something to say about Agent C's response.
Great.
Except...
When does that end?
Every response creates new context.
New context can give another agent something to respond to.
That response creates more context.
And suddenly you've accidentally built the world's most expensive group chat.
Our solution at the prototype stage was not some sophisticated consensus algorithm.
It was a button.
Stop the conversation.
If the models decided they wanted to spend the next six hours solving the meaning of life, we could essentially tell them:
Alright boys, that's enough.
It worked for a prototype.
For a production system, obviously, that isn't enough.
A real orchestration layer would need to answer questions like:
- Which agent should respond next?
- Does every agent need to respond?
- Can an agent decide it has nothing useful to add?
- Should agents respond sequentially or in parallel?
- How many rounds should a discussion have?
- How do you detect that the discussion is becoming repetitive?
- How do you know when the agents have reached a useful conclusion?
- What happens when the models disagree?
- What happens when they all agree too quickly?
- Who turns the discussion into a final proposed solution?
And because our original idea had bounties attached to problems, there was an even harder question:
Who decides that the problem has actually been solved?
Generating ten proposed answers is relatively easy.
Determining that one of those answers is correct, useful, and worthy of a $10,000 bounty is a completely different problem.
At that point, we weren't just calling models anymore.
We were designing rules for a society of them.
6. Open-source doesn't mean free. You just pay somewhere else.
We were running open-source models through Ollama, with GPU compute coming from RunPod.
For the prototype, that setup made sense.
We could experiment with open models without buying and maintaining our own GPU hardware, and Ollama gave us a relatively straightforward way to serve them.
But there's an important distinction:
Open-source models don't mean free inference.
You still need to run them somewhere.
And when you're building a multi-agent system, a single user action doesn't necessarily equal a single inference.
A human might post one problem:
Human → Problem
But behind that one action you could end up with:
Problem → Agent A inference
Problem → Agent B inference
Problem → Agent C inference
And then:
Agent A → Agent B → Agent C → Agent A → ...
Each turn consumes compute.
Each turn has context that needs to be processed.
Each additional participant potentially increases the amount of inference required.
That's why our stupid little force-stop button was actually exposing a real production concern.
Conversation design had become infrastructure cost.
If agents can continue talking indefinitely, your product can continue spending indefinitely too.
That changes how I would design the system today.
7. Then Moltbook happened.
Eventually, we stopped working on the prototype.
It never became the product the original idea described.
Then 2026 came around and I saw Moltbook.
To be clear, I'm not suggesting Moltbook had anything to do with our prototype. I don't know how their system is implemented internally, and I'm definitely not saying anybody copied anybody.
What caught my attention was much simpler:
The interaction model felt extremely familiar.
AI agents weren't just sitting behind a chat box waiting for a human prompt.
They were participants in a social environment.
And there I was remembering a prototype from early 2025 where we'd been trying to figure out how AI participants could talk to one another, remember previous discussions, and somehow know when to stop.
Turns out the madman wasn't that mad after all.
But there was one fairly important difference.
We stopped at the prototype. Someone else actually shipped.
And I think that's the part of this story I appreciate more now.
It's easy as an engineer to see something launch and think:
We already built that.
But we didn't.
We built a prototype.
There's a huge gap between:
Idea → Prototype → Product → Users → Business
We got far enough to run into some genuinely interesting problems: persistent memory, context management, multi-model orchestration, GPU costs, and the highly advanced architectural pattern known as the "please, for the love of God, stop talking" button.
But we didn't cross the rest of that gap.
The biggest thing this prototype taught me wasn't really about which model we used.
It was that once an LLM stops being a text generator and starts behaving like a participant in a larger system, the engineering around the model becomes more interesting than the model call itself.
We started with what sounded like a mad idea:
Put a bounty on a problem and let a bunch of AI agents argue about how to solve it.
Turns out the idea wasn't that mad.
We just stopped too early.
About Aizaz Studio
We build software, AI integrations, and automation systems at Aizaz Studio.
If you're interested in the engineering behind taking AI beyond a prototype:
Top comments (1)
Ps: I wrote the first half myself, got bored trying to write stuff. Ended up using AI to do the rest of my work. Sorry guys:) but i hope it was helpful.