The Day My AI Said Mitochondria Produce Oxygen

The answer was wrong. And it was delivered with complete confidence.

I had asked our prototype a basic biology question. Its answer was simple: mitochondria produce oxygen.

Any school student would catch the mistake. I didn't immediately correct it. I wanted to see what happened next.

I typed:

Mitochondria consume oxygen; they do not produce it.

Then I asked a related question. I wasn't really testing biology anymore. I was testing the system.

Had it actually learned something? Or had it simply produced the familiar conversational response, "You're right, thank you for the correction", without changing anything underneath?

That distinction became the beginning of a much larger question: what does it actually mean for an AI system to learn?

Most AI systems are remarkably good at accepting corrections within a conversation. But conversational acceptance and persistent learning are not the same thing. A system can say "you're right" without becoming different.

What I wanted to build was something I could inspect.

• If I corrected a system, could I see what changed?
• Could I test whether the change persisted?
• Could I introduce a related problem and determine whether the system could use what it had learned somewhere new?
• And, perhaps most importantly: could we measure any of this without relying on the system simply sounding intelligent?

That question became a research project with five of my classmates at Vasavi College of Engineering, an early prototype called QwiXAGI, and eventually a research paper.

This is the first post in a series about that experiment: what we built, what worked, what didn't, and the questions I still don't have good answers to.

The problem nobody warns you about

When you first start reading about Artificial General Intelligence, you expect to find a definition. Instead, you find several, and many of them are intellectually beautiful.

• Goertzel describes general intelligence in terms of achieving a variety of goals across a variety of environments.
• Legg and Hutter approach intelligence through performance across environments and formal measures of universal intelligence.
• AIXI provides an elegant theoretical model of an idealized general agent.
• Work from organizations such as MIRI emphasizes another dimension of the problem: capability is not enough if the resulting system cannot remain aligned with human objectives.

These perspectives aren't necessarily contradictory. But they leave an engineering problem.

• If we say a system is capable of learning, what exactly counts as learning?
• If we say it can reason, how do we distinguish reasoning from producing a correct answer?
• If we say it can generalize, how far outside the training distribution does it need to go?
• If we say it can transfer knowledge, how do we know it transferred an abstraction rather than recognizing a superficial pattern?
• And if we say it can improve itself, what constitutes improvement?

These questions changed how I thought about AGI. I stopped thinking of the problem as simply how do we build something intelligent? and started thinking about a more fundamental question:

What evidence would convince us that a system is becoming more generally capable?

That became the starting point for our framework.

From an idea to an operational definition

Before building the prototype, we needed something more concrete than the word intelligence. Our working definition was:

It is not a perfect definition. It is not intended to settle the AGI debate. It is an operational definition: a framework that turns broad claims into things we can attempt to test. Each part creates a question that can be examined experimentally.

The important word here is test. A definition becomes much more useful to an engineer when it can generate experiments.

What we actually built

There is an important distinction I want to make upfront. QwiXAGI is not a new foundation model. We did not train a massive language model from scratch and claim to have solved AGI.

QwiXAGI is an early cognitive orchestration prototype built on top of existing language-model backends. Our goal was different: to make certain cognitive functions explicit enough that we could inspect and experiment with them.

The architecture was organized into seven components:

1. Perceptual intake transforms raw inputs into structured representations that downstream components can work with.
2. Knowledge acquisition extracts concepts, relationships and rules from information presented to the system.
3. Adaptive knowledge memory stores acquired information in an explicit, inspectable representation.
4. Reasoning engine performs multi-step reasoning while recording intermediate steps rather than exposing only a final answer.
5. Cross-domain transfer attempts to apply learned abstractions beyond the context in which they were acquired.
6. Self-improvement loop processes corrections and updates the explicit knowledge representation accordingly.
7. Safety and alignment governance applies checks before newly acquired information or reasoning results enter the system's persistent state.

A controller coordinates the cycle:

learn → remember → reason → transfer → evaluate → adapt

That architecture gave us something I found surprisingly valuable: inspectability.

The difference between saying "I learned" and actually changing

Let's return to the mitochondria example. Suppose the system initially contains the rule mitochondria produce oxygen. I provide the correction: mitochondria consume oxygen.

A conventional conversational system might respond, "You're absolutely right." But what changed? If the next conversation starts from scratch, perhaps nothing.

In our prototype, the correction entered the learning pipeline. The conflicting representation could be identified, marked, removed or superseded, and replaced with the corrected one. The resulting knowledge structure remained explicitly inspectable, which means I could ask a different question later and examine whether the correction persisted.

This doesn't prove human-like learning. It doesn't prove general intelligence. But it gives us something scientifically useful: a system state that can be inspected before and after an intervention.

That makes learning less of a conversational impression and more of an experimental variable.

Measuring what we were actually interested in

Once we had a prototype, the next problem was measurement. We defined seven evaluation dimensions:

The overall number is easy to put in a headline. But honestly, it is the least interesting part. The individual measurements tell us much more.

Why we scored reasoning step by step

Consider two systems. System A produces the correct answer with a valid chain of reasoning. System B produces the same correct answer, but reaches it through an invalid intermediate step.

If we score only the final answer, both receive full credit. But they aren't behaving the same way.

So for our initial evaluation, reasoning was assessed at the step level. Human evaluators examined 40 reasoning sequences and assessed the validity of the intermediate steps.

This is still a small evaluation, and it is not a replacement for large-scale benchmarks. But it reflects an idea that I think deserves more attention:

A correct answer does not necessarily imply a correct reasoning process.

The reverse matters too. A system can have a useful reasoning structure and still arrive at a wrong answer because it lacks information. Those are different failure modes, and we should measure them separately.

Transfer was the more interesting experiment

For me, the most interesting part wasn't whether QwiXAGI could remember a fact. It was whether something learned in one context could become useful somewhere else.

One of our experiments explored whether a rule learned in mathematics could contribute to pattern detection in a task that was not presented as a mathematics problem. The point wasn't that the system suddenly "understood mathematics". The point was a narrower question: can an explicit abstraction survive a change of context?

• Memorization asks: can you reproduce what you saw?
• Transfer asks: can something you learned become useful somewhere you weren't explicitly shown?

Those are very different capabilities. And designing a transfer test that genuinely measures transfer, rather than hidden similarity or a shortcut in the task construction, is much harder than I expected. That will be the subject of a later post.

What the numbers do not prove

This is probably the most important section of the article.

The benchmark-style evaluations we explored, including BBH, ARC, GSM8K and MMLU, were limited in scope, with only a subset of items evaluated. Those results should be read as early experimental evidence and directional observations, not proof of general intelligence.

There is another important limitation. On knowledge-heavy tasks, frontier language models have enormous advantages, because they contain vastly broader pretrained knowledge than our prototype. Our architecture does not magically compensate for that. If the problem is essentially "retrieve an obscure fact from a massive knowledge base", a large pretrained model is likely to be far better equipped.

Our interest was elsewhere: what happens when we make memory, learning, adaptation, transfer and reasoning structure explicit?

What I actually think the experiment shows

The strongest conclusion isn't "we built AGI". We didn't. It isn't even "our architecture is better than large language models". We haven't demonstrated that.

The narrower conclusion is much more interesting:

Some behaviors associated with general intelligence can be represented as explicit system-level mechanisms and evaluated independently.

• Learning from correction can be tested.
• Memory retention can be tested.
• Transfer can be tested.
• Reasoning processes can be inspected.
• Adaptation can be measured.
• Safety constraints can be evaluated independently of raw task accuracy.

That suggests a different way of thinking about AI systems. Instead of treating intelligence as one enormous, mysterious number, we can begin treating it as a collection of capabilities with observable failure modes and measurable interactions.

That doesn't solve AGI. But it gives us somewhere to start.

The part I didn't expect

When we started this project, I assumed the difficult part would be making the system smarter. I was wrong. The difficult part turned out to be deciding what "smarter" actually means.

• A system can score higher on one benchmark and become worse at something else.
• It can answer more questions correctly without becoming better at learning.
• It can remember more information without becoming better at transferring knowledge.
• It can produce longer reasoning traces without actually reasoning better.
• It can adapt rapidly while becoming less safe.
• And it can appear remarkably intelligent in conversation while changing almost nothing about its underlying state.

That forced us to think differently. Maybe the central engineering problem isn't simply how do we make AI more capable? Maybe part of the problem is: how do we make capability observable enough to know when it has actually improved?

Why I'm writing this series

This project began with a wrong answer about mitochondria. It became a question about memory. That became a question about learning. Learning became a question about transfer. Transfer became a question about evaluation. And evaluation led me back to the question that started everything:

What would we actually accept as evidence of intelligence?

I don't think we have a complete answer. I don't think our framework is the final answer. And I don't think a small prototype can settle a question as enormous as AGI. But I do think these questions are worth asking experimentally.

So this series will document the project as honestly as I can, including the parts that worked, the parts that didn't, and the assumptions we discovered along the way. In the next posts, I'll explore:

• Why accuracy alone is a misleading measure of intelligence
• How to design a transfer experiment without accidentally rewarding shortcuts
• What persistent memory actually means in an AI system
• When correction becomes learning rather than conversational compliance
• What "safe self-improvement" could mean in actual code
• What broke in QwiXAGI, and the experiments that didn't work
• The questions from our research that I still can't answer

That last category may be the most important. A research project shouldn't end when you have an answer. Sometimes the most valuable outcome is discovering that your original question was too simple.

One last thing

I'm publishing this because I want the work to be examined, not merely announced.

If you're a researcher, engineer, student, or simply curious about how systems like this are built, challenge the assumptions. Question the metrics. Question the architecture. Question the evaluation. Try to reproduce the experiments. Tell me where the methodology is weak. Show me where we accidentally measured something other than what we intended.

I'd rather have someone find a real flaw in the work than have a polished result survive because nobody looked closely enough.

After all, that's how this project began. The system gave me a wrong answer. I corrected it. And instead of ending the conversation there, I started asking a different question: did it actually learn?

That question is still open. And that's why I'm writing.

Also published on Substack. Read the research behind it: Redefining AGI.

Build the system. Measure what it does. Publish the evidence. Make it possible for others to question it.