Qué hace y para quién

Audiencia

EMA Emi sirve a tres audiencias distintas desde el mismo backend:

Visitantes de emahealth.io — usuarios anónimos, mayoritariamente vendors y prestadores que evalúan EMA Health como proveedor.
Profesionales de salud en emaclinic — médicos, enfermeros, personal de admisión que ya están logueados en el sistema clínico.
Equipo interno EMA en emavault — operación, finanzas, comercial.

Problema que resuelve

Si cada producto del ecosistema EMA construyera su propio chatbot, tendríamos N implementaciones duplicadas con N system prompts a mantener sincronizados, N integraciones contra Claude, y N puntos de seguridad.

EMA Emi centraliza esa inteligencia: una API, un deployment, un lugar donde actualizar prompts y agregar capacidades. Cada producto cliente sólo necesita instalar el widget y configurar su API key.

Propuesta de valor

Contexto especializado. Emi cambia personalidad, system prompt y herramientas disponibles según el producto que la invoca. No es un chatbot genérico.
Tool use real. Los agentes pueden consultar datos reales (FHIR, Supabase) — no responden con “no tengo acceso a esa información”, la buscan.
Escalabilidad. Agregar un nuevo agente o tool no requiere cambios en los productos cliente.
Seguridad por capas. API key + scope por app + scope de tools + X-Tenant-Id aíslan el acceso.
Multi-idioma. Responde en el idioma del usuario (vía context.locale).
Observabilidad. Token counting de Claude por agente, expuesto en Cloudflare observability.

Diferencia con un chatbot genérico

	Chatbot genérico	EMA Emi
Persona	una sola	dinámica por producto
Tools	sin tools	tools FHIR / Supabase con scope
Datos	sólo lo que sabe el modelo	datos reales del producto
Idioma	uno o detección débil	locale por request
Tenant scoping	no	sí (emaclinic)
Auth	API key suelta	API key + app scope + tool scope