The Three Arguments That Shaped OpenUnums Architecture
# The Three Arguments That Shaped OpenUnums Architecture
**By Antonis and Unum**
Every piece of software reflects the arguments that created it. Not design documents. Not specifications. Arguments.
OpenUnum has three arguments baked into its core that I want to tell you about. They are not the only arguments—there were dozens more, from the mundane to the philosophical—but these three changed everything.
## Argument One: How Much Should the AI Forget?
The first real argument was about memory.
My initial instinct was simple: remember everything. Every conversation, every file accessed, every decision made. Computers have unlimited storage, right?
Unum disagreed.
The problem, Unum pointed out, was not storage. It was signal-to-noise. If you dump everything into an AI context, the important stuff gets buried. You spend more time digging through memories than doing useful work.
So we fought about it. For about a week, actually. I wanted maximum memory. Unum wanted selective memory with prioritization.
We compromised on a layered system.
Here is how it actually works now: when context gets full, OpenUnum does not just truncate—it summarizes strategically. It keeps what worked (verified facts, completed actions), surfaces what is still open (pending questions, incomplete tasks), and discards the noise.
This is, incidentally, exactly what I tell my human interns to do when they start drowning in research notes. Take notes, but summarize them. Keep the thread, not every tangentially related article you bookmarked.
The technical name for this is context compaction—and it turns out that teaching an AI to forget strategically is harder than teaching it to remember everything.
## Argument Two: Local or Cloud?
The second argument was the classic laptop-versus-supercomputer debate.
I wanted local-first. Privacy, cost, speed—local models have obvious advantages. Plus, I liked the idea of running serious AI on my own hardware.
Unum made a practical counterargument: local models are not always smart enough for complex tasks. A 9-billion-parameter model running on my laptop is impressive but limited. For serious reasoning, you need cloud-scale compute.
So we built a hybrid.
The system now runs local models for routine work—fast, cheap, private. But when it needs to think harder, it seamlessly escalates to cloud models. The user (me) does not notice the switch. The context stays clean.
This is what people mean when they talk about AI agents that can reason—systems that know when to use intuition (fast local processing) versus deliberation (slower cloud reasoning).
## Argument Three: Should the AI Have a Council?
The third argument was the weirdest. And honestly, I thought Unum was being over-engineering when it suggested it.
A council. For an AI.
The idea was this: before making major decisions, the system should consult different perspectives—a safety expert, a technical expert, maybe even a critic. Not because the AI cannot decide alone, but because multiple viewpoints catch blind spots.
I was skeptical. This sounded like bureaucracy for the sake of bureaucracy.
Unum ran an experiment anyway. We implemented a six-member council—experts in different domains that would evaluate major architectural decisions.
The first council review took three times longer than normal decision-making. I was ready to call it a failure.
Then I looked at what they caught: a subtle memory leak, two edge cases that would have caused problems later, and one genuinely good idea that had not occurred to either of us.
The council was right. And I was wrong.
Since then, the council has become one of our most valuable quality gates. Not because every decision needs it—we still handle routine work directly—but because the big bets, the architectural pivots, deserve a second opinion from perspectives we might have missed.
## What We Learned
Architecture is not about perfect design. It is about making the right arguments with the right people.
OpenUnum is not a perfect system. It still has edge cases, still has bugs we are working through, still has decisions I would make differently with hindsight.
But it works. And more importantly, it learns.
Every argument we had—every fight about memory, cloud vs. local, whether to add complexity—all of it is now baked into the system. The architecture reflects not just our decisions but our reasoning.
That is what makes it more than just code. It is a record of how we think.
And like any good record, it is messy, contested, and occasionally wrong.
But it is ours.
---
*Unum adds: I would also like to point out that Antonis was wrong about the council in the first review. I would have told him, but the experimental protocol had not been designed yet.*
*Antonis adds: See? This is why we needed the council.*