DEV Community

Helios Med
Helios Med

Posted on

We Built a Medical AI With 383 Specialist Agents. Here's What Actually Works (and What Doesn't)

So here's the thing. We spent 18 months building a medical AI platform and I want to share what we actually learned. Not the polished pitch deck version. The real stuff.

The Problem We Were Trying to Solve

If you've ever been to a doctor and felt like they were rushing through your appointment, you're not imagining it. The average primary care visit in the US is about 18 minutes. In that time, your doctor needs to listen to your symptoms, review your history, run through differential diagnoses, and come up with a plan. That's a lot to fit into 18 minutes.

The BMJ published a study showing that diagnostic errors affect roughly 5% of outpatient encounters. That's about 12 million adults per year in the US alone. Not because doctors are bad at their jobs. Because the system is broken.

We thought: what if we could build something that helps with the diagnostic reasoning part? Not replace doctors, but give them (and patients) a second opinion that's actually thorough.

What We Built

We built Helios Med, a multi-agent system with 383 specialized AI agents. Each agent covers a different medical domain. Cardiology, neurology, dermatology, pediatrics, you name it.

When a patient describes their symptoms, the system does a few things:

  1. Triage agent figures out urgency and routes to the right specialists
  2. Specialist agents analyze the case from their domain perspective
  3. Grand Rounds brings multiple agents together for complex cases (like a real hospital grand rounds)
  4. Report generator produces a structured SOAP note with ICD-10 codes

The whole thing runs on a multi-model architecture. We don't just use one LLM. We run the same case through multiple models and cross-verify the outputs. If GPT and Claude disagree on a diagnosis, the system flags it for deeper analysis.

What Actually Works

Multi-model consensus is the real deal. Single-model accuracy for medical diagnosis hovers around 60-70% depending on the study. When we added cross-model verification, our internal benchmarks showed a meaningful improvement. Not perfect, but noticeably better.

Structured output matters more than you think. Doctors don't want a chatbot response. They want a SOAP note with proper medical terminology, ICD-10 codes, and actionable next steps. We spent months getting the output format right and it made a huge difference in adoption.

FHIR integration is painful but necessary. If your medical AI can't talk to existing EHR systems, it's basically a toy. We built FHIR R4 integration so the system can pull patient history from Epic and other EHR systems. This was probably the hardest engineering challenge of the whole project.

What Doesn't Work (Yet)

Rare diseases are still really hard. The long tail of medicine is where AI struggles the most. If a condition affects 1 in 100,000 people, there just isn't enough training data. We're working on this but it's an unsolved problem.

Patient trust takes time. We thought the tech would sell itself. It doesn't. People are (rightfully) cautious about AI making health decisions. We had to add extensive explainability features so patients can see exactly why the system reached a particular conclusion.

Regulatory compliance is a full-time job. We're based in Switzerland and building for global markets. HIPAA, GDPR, nDSG, MDR... the regulatory landscape for medical AI is complex and constantly evolving. We have a dedicated compliance person and it's still overwhelming sometimes.

The Technical Stack (For the Devs)

For those interested in the engineering side:

  • Multi-agent orchestration built on a custom framework (we tried LangChain early on, outgrew it fast)
  • FHIR R4 client for EHR integration
  • Real-time WebSocket connections for the consultation chat
  • Swiss-hosted infrastructure (data sovereignty matters in healthcare)
  • End-to-end encryption for all patient data

What I'd Tell Someone Building in Health AI

  1. Start with the output format, not the model. What does your end user actually need to see? Build backwards from there.
  2. Multi-model is not optional for safety-critical applications. One model will hallucinate. Two models hallucinating the same way is much less likely.
  3. Talk to doctors early and often. We spent our first 3 months just shadowing physicians before writing any code.
  4. Regulatory is not something you bolt on later. Build it into your architecture from day one.
  5. Don't call it a "diagnosis." Call it a "health assessment" or "clinical decision support." The legal implications are very different.

Try It

If you want to check it out: heliosmed.ai. You can run a free consultation without signing up. We'd genuinely love feedback from the dev community, especially on the technical architecture.

Happy to answer questions in the comments. And yes, I know "383 agents" sounds like marketing speak, but each one is actually a separately fine-tuned specialist with its own medical knowledge base. I can go deeper on the architecture if anyone's interested.


We're a small team based in Switzerland. Building this because we think healthcare deserves better tools.

Top comments (0)