An intelligent system should leave behind more than an answer.
When it discovers a better way to work, there should be a way to preserve that discovery, test its limits, and put it to work again. A successful experiment should be able to become a reliable skill. A failure should be able to prevent another failure. A costly discovery should be able to make the next task less costly.
This should not require preserving every conversation, retraining a model after every interaction, or allowing software to rewrite itself without restraint.
It requires something more deliberate: a way to distinguish useful change from noise, preserve the evidence behind it, and pass it forward under the right conditions.
Mendel Infolabs exists to make useful intelligence cumulative.
Our name expresses a commitment to inheritance and experimentation. What carries forward? What changes when components are combined? Which improvements survive a different environment? Which apparent successes disappear under a better test?
We take these questions seriously without pretending that software is biology.
The analogy is an invitation to experiment. It is not evidence that our ideas will work.
That evidence is ours to produce.
1. Our subject is the working system
A model matters enormously. So does everything that determines how its capabilities reach the world.
The same model can be given different evidence, different tools, different memory, different opportunities to check its work, and different boundaries on its actions. Those choices belong inside the study of useful intelligence.
We will study the whole working system.
That includes the model, but also the structure around it: how a task is understood, how information is selected, how decisions become actions, how outcomes are checked, and what changes after experience.
We call this structure a harness. Its purpose is to make capabilities usable, observable, and improvable.
We do not need to declare that models are unimportant to take this work seriously. Nor do we need to settle every philosophical question about intelligence before measuring whether a system does better work.
Our questions are practical.
Did it complete the task correctly? Did it recognize when it lacked sufficient evidence? Did it respect its permissions? Could someone inspect what happened? Did its improvement justify the resources spent achieving it?
A fluent answer can be useful. A completed task is a different claim. A system that becomes more reliable across future tasks is a further claim.
We will keep those claims separate.
2. There is no intelligence apart from its conditions
“Better” requires an answer to another question: better for what, under which conditions?
A useful system must fit its environment. That environment includes more than the information presented to it. It includes available actions, operating costs, deadlines, uncertainty, human expectations, and the consequences of being wrong.
We will not assume that one configuration should dominate every setting.
Some tasks will benefit from extensive reasoning. Others will demand speed. Some will tolerate experimentation. Others will require narrow permissions, cautious execution, and explicit human judgment.
Our ambition is therefore not one universal agent with one universal definition of success.
It is a common foundation on which different systems can develop appropriate capabilities.
That foundation should make observations, actions, permissions, outcomes, and experimental changes legible across domains. It should let us reuse sound methods without pretending that a browser, a construction project, and a laboratory are interchangeable.
We seek common interfaces, not identical behavior.
We will also study the environments in which improvement happens. A training environment can reward shortcuts. A benchmark can conceal a weakness. A task generator can produce variety without producing meaningful difficulty.
Designing the conditions for learning is part of the work.
Those conditions must themselves be tested against outcomes beyond the exercises they generate.
3. Inheritance must be earned
A change does not deserve to survive merely because a system produced it.
It should survive because there is evidence that it helps.
An improvement might be a learned decision rule, a better retrieval method, a new skill, a more reliable workflow, a smaller model, or a simple piece of conventional software. It might also be the removal of an unnecessary component.
We will not privilege complexity. Sometimes the most valuable discovery is that something can be deleted.
Whatever its form, an inherited improvement should carry a record of its origin and limits: the problem it addressed, the change that was made, the conditions under which it was tested, the resources it consumed, and the failures that remain.
This record should allow a later system—or a person responsible for it—to decide whether the improvement belongs in a new setting.
Successful behavior should not spread without its qualifications.
Nor should an old success become permanent authority. When conditions change, inherited capabilities must be open to retesting, revision, and retirement.
Our experimental discipline follows from this. Candidates must compete against credible baselines under comparable conditions. Apparent gains must survive fresh tasks and checks for measurement noise. Search costs and verification costs must be counted, not hidden behind an attractive final score.
Experimental changes belong in controlled environments before they reach consequential work.
Sometimes the correct result of an improvement cycle will be to keep the existing system.
A generation that changes nothing can still be a successful experiment.
4. Better judgment is part of the research
Every improvement process depends on some account of what counts as improvement.
That account can be incomplete.
A test can check the wrong thing. A reward can favor a shortcut. An evaluator can approve an impressive-looking result that fails in use. Agreement between evaluators can still leave a shared mistake undiscovered.
We therefore intend to improve not only the systems doing the work, but also the methods used to judge that work.
This creates a difficult research problem. An evaluator cannot establish its own superiority simply by awarding higher scores.
A proposed evaluator should earn credibility through what follows from using it: whether the systems it trains, selects, or promotes subsequently perform better under independent assessment.
That assessment must remain outside the candidate’s control. It must also be renewed carefully; repeatedly optimizing against the same supposedly hidden test can undermine its independence.
Where outcomes can be measured directly, we should measure them. Where judgment is unavoidable, uncertainty and disagreement should remain visible. Where the objective belongs to a person or organization, improving the evaluator must not quietly change that objective.
Learning to measure a goal better is not permission to choose a different goal.
We regard evaluator improvement as a research commitment, not a solved problem. It may introduce costs, instabilities, or new opportunities for exploitation. Our responsibility is to investigate those possibilities as seriously as the hoped-for gains.
5. Expensive discoveries should become affordable capabilities
We do not want every routine decision to remain an expensive act of invention.
A system may initially need a powerful model to handle an unfamiliar task. After enough authorized, verified experience, some parts of that work may become suitable for a smaller model, a constrained decision mechanism, a reusable workflow, or ordinary code.
We intend to discover when that transition is justified.
Where a decision can be expressed as a defined set of choices, the system should not generate unconstrained language merely out of habit. Where a problem genuinely requires planning, interpretation, or novel reasoning, a narrow decision mechanism should not be forced beyond its competence.
The right allocation of computation is itself something to learn and test.
A fast answer is valuable only when it is sufficiently reliable for its use. Confidence alone does not establish that reliability. A well-formed action is not necessarily a correct action, and a correct action is not necessarily an authorized one.
Our interest in small models and local computation follows from this discipline. We want more useful work to be possible within the resources people actually have.
We will not assume that a particular model size, numerical format, processor, or deployment location is always the right answer.
We will measure the cost of successful work, including retries, verification, human review, maintenance, and failure.
Efficiency means using fewer resources to deliver the required outcome—not merely producing tokens more cheaply.
6. Learning does not confer authority
The ability to discover an action and the permission to perform it are separate.
A system that becomes more capable must not automatically receive broader access, a larger budget, or greater freedom to affect the world.
An experimental improvement must not be allowed to approve its own deployment, rewrite its protected permissions, choose away its oversight, or remove the evidence needed to inspect its behavior.
The authority governing a system must remain outside the changes that system is free to make.
Those governing rules can themselves be revised, but through an explicit, authorized process—not as an incidental consequence of optimizing performance.
For consequential work, we will build around scoped permissions, reviewable evidence, meaningful intervention, and recovery where recovery is possible. Some actions cannot truly be undone. Those actions require restraint before execution, not confidence that a later rollback will solve the problem.
A request for approval should explain the proposed action and its consequences. It should not be a ritual click designed to transfer responsibility to a person who cannot understand what they are approving.
We also reject the idea that every difficult judgment should eventually be automated.
Sometimes better intelligence means asking a better question. Sometimes it means making uncertainty clear. Sometimes it means stopping.
A system may become better at serving a purpose. It does not thereby acquire the right to decide that purpose.
7. Experience is entrusted to us
A system capable of learning from work will encounter information that people did not create for its benefit.
A private document, a customer interaction, or an employee’s correction is not automatically material for a shared training corpus.
We will distinguish between storing information, retrieving it for an authorized task, using it to improve a particular system, and using it to train something shared. Permission for one does not imply permission for the others.
This distinction belongs in the architecture.
Our ambition to preserve useful experience must coexist with limits on collection, retention, access, and reuse. We should retain only what a legitimate purpose requires and only under the appropriate authority.
Cross-customer learning must not become a polite name for moving private knowledge between customers.
Where a transferable improvement can be developed without exposing the information that produced it, that separation must be demonstrated rather than assumed. Where we cannot establish an acceptable separation, the information should not cross the boundary.
The record of an experiment can be valuable. That does not mean every record should exist forever.
What a system can learn and what it is entitled to learn are different questions.
A founding principle that fails this distinction would not deserve to be inherited.
8. We will earn the thesis in practice
We are proposing a research direction. We are not announcing that open-ended self-improvement has been solved.
Our first obligation is to demonstrate bounded, repeatable results.
Can a shared experimental foundation improve systems in meaningfully different environments? Can those improvements survive tasks that were not used to select them? Can useful discoveries be transferred without concealing the assumptions that made them work? Can repeated reasoning become less costly without falling below the required standard of reliability?
And does the improvement remain worthwhile after counting the cost of discovering, checking, deploying, and maintaining it?
These questions should shape our experiments and our products.
A product is where a research claim encounters real constraints. But customers are not involuntary experimental subjects. Unproven changes belong in controlled trials before they enter ordinary work.
Our products will provide different ways to test the company’s thesis. They need not all use the same models, the same hardware, or the same method of adaptation. Their names and implementations may change.
The founding commitment should survive those changes.
We will build on the work of others and credit it. We will not mistake combining public ideas for proving a new one. Our contribution must be visible in working methods, convincing evidence, and useful outcomes.
Our durable advantage should come from the quality of our experiments, the capabilities we earn, and the trust with which we handle the work entrusted to us.
When evidence contradicts a preferred idea, the idea must change.
A laboratory that cannot abandon its favorite explanation is not equipped to study self-improvement.
Our wager
We do not know the final architecture of useful machine intelligence.
We do not need to pretend that we do.
Our wager is that progress can become more durable when systems have challenging environments, well-defined actions, reliable evidence, reusable experience, and disciplined ways to change.
We want discoveries to become capabilities. We want capabilities to become more accessible. We want failures to inform future designs without preserving the mistakes themselves. We want different systems to develop different strengths without losing a common standard of accountability.
We are not pursuing change for its own sake, autonomy for its own sake, or an evolutionary metaphor made into a promise.
We are building a way for useful improvements to survive—and a way to reject those that do not deserve to.
Evolution is how we search. Evidence decides what we keep. People decide what it is for.
That is the work of Mendel Infolabs.
Make useful intelligence cumulative.