Make a Smaller Model Behave Like a Frontier Model: Put Buffaly Around It

How do you make a smaller, inexpensive, open-source model behave like a frontier model?

You put Buffaly around it.

That is the whole claim, and we have a number for it. GLM 5.2, an open model you can run yourself, scored 101/150 (67.33%) answering MedQA questions directly. Nothing about the model changed. No fine-tuning, no larger checkpoint, no swap to something stronger. With Buffaly around it, the same weights scored 144/150 (96.00%). Direct GPT-5.5 scored 146/150 (97.33%).

So the open model finished within 2 answers and 1.33 percentage points of a direct frontier model. The distance that separated them at the start was 45 answers. The layer around the model closed it.

The measurement

Seven models. The same 150 questions from MedQA, a public benchmark built on medical licensing exams. Every model answered every question twice: once directly, the way you would use any chatbot, and once with Buffaly supplying structured context before the model committed.

GLM's swing was the largest. It corrected 46 answers it had previously missed and worsened 3 it had gotten right, for a net gain of 43.

The pattern holds below GLM too. Gemma4 31B, a 31-billion-parameter model, reached 145/150, one answer behind what GPT-5.5 and GPT-5.6 Sol scored on their own. Different cost tier entirely. Same neighborhood on the scoreboard.

Why the small model got there

Most AI products treat the model as the entire source of intelligence. Everything goes into the prompt: instructions, context, rules, and reminders not to forget the rules. Then you hope the model reads all of it, follows a process described in prose, and remembers to look things up. When it fails, the reflex is a bigger model.

Buffaly starts somewhere else. The model does the part that needs language and judgment. Software does the part that has to happen every single time.

In a conventional agent, the prompt asks the model to follow a process. In Buffaly, the process is executable: real code in a real runtime, wired to knowledge, tools, services, memory, and validation rules. We call the structure a typed executable graph. The idea underneath is plain. The important knowledge and the important steps are parts of the system, not sentences the model might skim.

For this benchmark, that meant Buffaly looked up all four answer choices in SNOMED CT, the standardized clinical vocabulary, before the model answered. The model could also flag up to four terms from the vignette it wanted defined. Buffaly retrieved everything, packed it into a compact context, and handed it back to the same model. The lookup could not be forgotten, skipped, or judged unnecessary this time.

The intervention was deliberately narrow: one ontology, one lookup step. Buffaly is built to coordinate multiple ontologies at once and has a verified connection to ICD-10 as well. We used SNOMED CT alone, on purpose, to see what a single enforced retrieval step would do to a smaller model.

It moved that model 43 answers.

What this changes about what you buy

When you see a capability gap, the standard move is to buy across it. You reach for the strongest model available, wire it into everything, and absorb the bill on every task whether or not the task needed it.

There is a second move, and on this benchmark it worked: put a real operating layer around a cheaper model.

The consequence is not subtle. If executable knowledge, enforced process, tools, memory, and validation can carry an open model to within 2 answers of a direct frontier model, then the most expensive model stops being the default answer for every task in the organization. Some work genuinely needs the strongest reasoning available. A great deal of work needs reliable lookups, the same steps every time, and a check before the output moves downstream. That second category is enormous, and it is exactly the category where the layer does the heavy lifting.

So the evaluation question changes shape:

What is the least expensive, most controllable complete system that meets the requirement?

Nobody needs two models to be identical. They need a complete system that clears the bar at a price they can live with, on infrastructure they control, with a process they can inspect.

Now put the same layer around a frontier model

If supplying reliable knowledge and enforced process moves a small open model 43 answers, the natural next question is what it does around a model that is already at the top.

A frontier model with Buffaly around it is still a frontier model, plus retrieval it cannot skip, tools it can actually call, memory that survives the session, validation gates that catch bad output before it travels, and coordination across steps that no prompt enforces on its own. None of that comes from weights. All of it comes from the layer.

That is the general form of the thesis. Buffaly lifts a smaller model toward frontier behavior, and it gives a frontier model a reliable way to reach knowledge, take action, remember the work, and finish the job. Same layer, both directions.

The benchmark is medical. The layer is not.

We used a medical benchmark because it grades itself cleanly. Two rounds, same questions, same models, a number at the end anyone can check. Very little organizational work is that tidy to measure.

But nothing about the layer under test is medical. It is knowledge, tools, memory, validation, and execution, and that applies to any work that is knowledge-intensive, repeatable, and tool-using. Claims review. Compliance checks. Underwriting. Vendor and contract analysis. Support triage against a real product catalog. Anything where the right answer depends on looking something up in a system of record, following the same steps every time, and getting caught when you are wrong.

In all of it, the same economics apply. Put Buffaly between your models and your work, hold the knowledge and the process in software, and plug in whichever model each job actually requires. Smaller and open models get lifted toward frontier behavior. Strong models get a system worthy of them.

A second proof: Buffaly ran the experiment

The scores are one proof. The project itself is a smaller one, and it speaks to coordination capacity rather than accuracy.

I handed Buffaly a research paper on agent architecture for reducing diagnostic failures and hallucinations in healthcare, and asked it to explore the idea.¹ What came back was this experiment. Buffaly designed the comparison, built the runners, connected seven models of very different sizes and a clinical terminology service, created the validation gates, ran both rounds, checked the data, analyzed the paired results, generated the chart, and drafted the reporting materials.

That is a long-running, multi-model, tool-heavy operation: seven models to keep straight, SNOMED CT retrieval to execute consistently, gates that had to hold, paired data that had to stay paired across two full rounds, and analysis that had to be reproducible. It ran far longer than any single prompt and produced files, not just answers. That is what an executable graph is for.

The answer

How do you make a smaller, inexpensive, open-source model behave like a frontier model?

You put Buffaly around it. GLM 5.2 went from 101/150 (67.33%) alone to 144/150 (96.00%) with Buffaly, against 146/150 (97.33%) for direct GPT-5.5. Two answers apart. 1.33 percentage points apart. No retraining, no bigger model, no larger bill.

The model matters. It was never the whole product.

Buffaly is an open-source neurosymbolic engine that makes knowledge, tools, and execution native parts of AI systems. Learn more at buffa.ly.