The symptom: "it answers correctly, but not the right thing"

A general-purpose GPT assistant deployed on a medical clinic's website consistently fails in three predictable ways:

• To "can I have an MRI?" it returns generic medical advice instead of immediately asking about metal implants, tattoos and pregnancy — the questions any MRI technician asks in the first minute of the call.
• To "what does a neurosurgery consultation cost?" it replies "it depends on the region and your insurance" — even though the clinic has a fixed published price list and an integrated insurance engine.
• To "my head has hurt for three days" it gives the safe, impersonal "you should see a doctor" — when the clinic's actual value would come from capturing the pattern of the complaint and routing the patient to the right specialist.

The general-purpose engine isn't doing anything "wrong." It just doesn't know the domain. And more importantly — it doesn't know what it doesn't know.

What makes an engine vertical

1. Domain ontology

A vertical engine starts with an explicit model of the domain's entities. In healthcare it's patient → complaint → symptoms → specialty → available slot → insurance status → procedure prep. In hospitality it's guest → reservation → room → ancillary services → loyalty tier → communication language. The ontology isn't just a glossary; it's a structure the engine uses to decide which questions it must ask and which answers it isn't allowed to give without verification.

A general-purpose engine doesn't carry that structure. It can imitate it via a system prompt, but it can't fall back on it at moments of uncertainty.

2. Domain-tuned RAG configuration

Generic RAG (a single vector index across the whole knowledge base) returns the top-5 semantically nearest chunks. That isn't enough in domains where:

• Some documents are authoritative (Ministry of Health protocols, internal procedures) and others are advisory (review articles, opinion pieces).
• Some documents contain stale information that's formally archived but a semantic search will still surface — leading to a dangerous hallucination.
• Documents are in several languages and the user writes in a fourth.

Vertical RAG splits sources by authority level, filters by date and applicability to the query before chunks reach the LLM. At SLAtech we maintain separate indexes per deployment: "clinic protocols" (vector + keyword filter + date), "physician schedule" (structured SQL, not vector), and "general reference" (free vector). The LLM gets all three with explicit source tags and priority order.

3. Audit trail and right to refuse

In regulated domains (healthcare, finance, legal advice) the engine must log every answer with its sources and be able to refuse to answer when confidence is below a threshold. These aren't add-ons; they're infrastructure requirements without which no compliance team will approve production.

A general-purpose GPT chat doesn't meet that requirement out of the box. You can add it — but that's exactly the work that turns a general engine into a vertical one.

4. Domain-specific integrations

A medical assistant without an EHR and scheduling integration is a toy. A hotel assistant without PMS and booking engine — the same. An educational assistant without LMS and credential recognition — same again. These integrations make up half the product value; you cannot fake them with a prompt.

What vertical costs

Honestly:

• Time to launch: a generic GPT chat ships in a week; a vertical engine is 2–4 months per vertical.
• Build cost: ontology + three RAG indexes + integrations is real engineering. Prompts are free; ontologies are not.
• Maintenance: when a clinic protocol changes, the index has to be updated. No vendor does this for you — it's an operational process.

On the other hand, in production the vertical engine doesn't "lose" 30% of queries to mismatched answers and doesn't create legal exposure for the operator.

When the general engine actually wins

Not everything should be vertical. A general-purpose GPT assistant remains the right choice when:

• The cost of being wrong is low — an information chat on a marketing agency's website.
• The domain is too broad to define — a generic "travel assistant" across dozens of countries and services.
• Scenarios are unpredictable — SaaS technical support where every ticket is unique.

These three conditions mostly describe B2C and SMB marketing. In B2B and regulated domains they almost always fail.

What to take away

1. If you're launching an AI chat in B2C and the cost of error is tolerable — pick a general-purpose engine. Don't overcomplicate.
2. If you operate in a regulated domain — healthcare, finance, legal advice — plan for a vertical engine from day one. The general one will have to be rewritten; doing it right the first time is cheaper.
3. When choosing a vendor, ask specifically: "what domain ontology do you have for my industry," "how do you separate authoritative from advisory sources in RAG," "how do you log refusal-to-answer?" Generic vendors either don't answer these questions or promise "we'll customize" — which is the same as asking them to build you a vertical engine retroactively.