Introducing Buffaly
Why traditional LLM agents are an operational dead end in medical administration: and why we built a neurosymbolic alternative.
For the last decade I've served as CTO or President of MedTech companies. I've worked with great people to start, build and scale medical software companies. I've lived through audits, downsizing, upsizing, and acquisitions.
Over the years, I’ve worked deeply in AI, but I’ve also spent countless hours digging through EMRs, reading regulations, working with medical billers, doctors, nurses, office managers, and insurance representatives.
I mention that because I want you to understand: I know the pain. I know how difficult the medical industry is. I know it's built entirely on rules, and exceptions, and interpretations, and the knowledge deep within your best biller's head.
"I once spent hours on the phone with an insurance rep over a monthly billing code that gets rejected every single February. Why? Because the payer’s system hardcodes a strict '30 days between codes' requirement. When I pointed out that February only has 28 days, the rep completely agreed with me, and then calmly explained that the claim was still denied because their computer requires 30 days every month."
That is medical administration in the real world. It is not clean workflows and elegant data. It is broken processes, rigid legacy systems, payer games, and the constant risk that a dumb, hardcoded rule will cost you real money.
Buffaly
In our healthcare software work, we provide the most fully featured remote care software available to clinicians and a powerful integrated AI in FairPath. Clinicians and patients benefit from our AI software every day in the form of better care, and less wasted administrative time.
Today I'm introducing something fundamentally beyond what we already offer. A different type of AI agent: Buffaly. Buffaly is the child of years of research and experience solving real problems. Buffaly is fundamentally new: but the experience that shaped it is not.
// Internal Milestone
Buffaly already runs the backend of our own software operation. It writes all of our code, it maintains FairPath, it manages our servers, it imports and manages patients... Everything.
The "Chatbot" Problem
Look at the generic AI agents flooding the market right now. Underneath the slick marketing, almost all of them are built on the exact same architecture: a giant text file (the prompt) fed into an LLM. They retrieve some context, flatten it into text, and generate a polite, conversational answer.
That might work if you are trying to automate customer service for an e-commerce brand. It is operationally useless in medical tasks.
In our world, a "guess" isn't a funny AI mistake. It is an audit trigger. It is revenue leakage. It is billing fraud. You cannot fix that kind of operational chaos with a chatbot.
The Differentiator
"Buffaly thinks in code; traditional AI thinks in language."
1. Buffaly does not expose HIPAA-protected data to the LLM
The safest PHI is the PHI the model never sees.
Traditional Agents (Text Serialization)
{
"patientId": "P-77821",
"mrn": "12345",
"name": "John Doe",
"dob": "1954-03-12",
"insurance": { "payer": "Medicare" },
"diagnoses": ["E11.9", "I10"]
}
// Full record is serialized and sent to the LLM context.
Buffaly (Native Reference)
var patient = Patients.GetPatient(12345); // What the LLM sees: Handle: Patient#A17F Type: Patient // PHI never enters the prompt. Reference only.
2. Buffaly uses the code and data you already have
Your most valuable technical asset is the business logic your organization has already built. The last thing you need is an architecture that forces you to rebuild all of that as "adapter glue."
The "Glue Code" Problem
// Engineers must build custom translation wrappers
public async Task<string> GetPatientForLLM(string mrn) {
var p = await _emr.GetPatientAsync(mrn);
return JsonSerializer.Serialize(p);
}
Native Binding
// Buffaly binds directly to your existing objects public BillingResult CheckBilling(Patient p) { return MyRealBusinessLogic.Run(p); } // No wrapper. No serialization. No maintenance.
3. Buffaly uses ontologies and knowledge to control execution
Healthcare administration is not a bag of unstructured text. It is a dense web of formal structures. Traditional agents treat all of this as language to be interpreted on every single request.
Typical Production Prompt Excerpt
Buffaly Execution Environment
4. Buffaly costs less over time because repeated work becomes executable
Traditional agents remember text. Every repeated request forces the model to re-discover the data path and re-reason the logic. Buffaly turns repeated work into infrastructure.
Traditional Agents (Repeat Reasoning)
Request 1 - Model reasons through the workflow
Request 2 - Model reasons through the same workflow
Request 3 - Model reasons through the same workflow
// Token cost repeats every time.
Buffaly (Promoted Capability)
Experience becomes structure.
Structure becomes executable capability.
// In one real FairPath task, token cost dropped by 79.7%.
What is available now
If you are deploying AI agents into healthcare, you should examine Buffaly.
The core is now available as a public-source developer preview. You can download the installer and inspect the source code. The runtime is released under GPLv3 by default. Commercial licensing options are available for organizations that require different terms for production deployment, redistribution, private embedding, or partner integration.
This is the architecture we have been running on our own medical software operations. The source is available so teams responsible for compliance, PHI protection, audit readiness, and integration with existing clinical and billing systems can evaluate the actual mechanisms directly.
Some healthcare-specific components, customer workflows, production adapters, and deployment assets remain private for now. The core runtime, ontology engine, typed action system, provider model, and memory-promotion approach are available for inspection and extension.
Start with the installer if you want to run it locally. Use the source if you want to understand how the runtime works or begin building against it.