Ir al contenido

Casos de uso y workflows

AgenteProductoAudienciaWorkflows típicos
SalesAgentemahealth.ioVisitantes anónimosQ&A productos, interoperabilidad, pricing, derivar a contacto
SupportAgentemaclinicMédicos, enfermeros, admisiónResumen clínico, verificar medicamentos, revisar GES, búsqueda de pacientes, agenda, alertas
AnalyticsAgentemavaultCEO, CFO, coordinadoresMRR/EBITDA/runway, análisis pipeline, horas equipo, obligaciones fiscales, calendario editorial

Workflow 1 — SalesAgent (chatbot del website)

Sección titulada «Workflow 1 — SalesAgent (chatbot del website)»
  1. Usuario entra a emahealth.io y abre el chat (bubble coral abajo a la derecha).
  2. Pregunta sobre productos, integraciones, certificaciones, pricing.
  3. SalesAgent responde basado en su system prompt (sin tools).
  4. Si detecta intención comercial fuerte, sugiere agendar reunión vía cal.com (link integrado al final de la respuesta).

Workflow 2 — SupportAgent (asistente clínico)

Sección titulada «Workflow 2 — SupportAgent (asistente clínico)»
  1. Médico abre EmiDrawer desde el header de emaclinic, o EmiActions desde el ContextPanel de la ficha del paciente.
  2. Pregunta operacional: “Resumime al paciente Juan Pérez”, “¿Qué medicamentos activos tiene?”, “¿Cumple criterios GES para hipertensión?”.
  3. SupportAgent invoca las tools correspondientes (search_patients, get_patient_summary, evaluate_ges).
  4. Responde con datos reales del paciente, scope-ados al tenant del profesional.

Workflow 3 — AnalyticsAgent (asistente operacional)

Sección titulada «Workflow 3 — AnalyticsAgent (asistente operacional)»
  1. CFO abre EmiDrawer desde el header de emavault.
  2. Pregunta: “¿Cómo va el MRR este mes?”, “Mostrame los gastos fijos de octubre”, “¿Qué leads están en stage de propuesta?”.
  3. AnalyticsAgent invoca tools (get_finance_summary, list_expenses, list_leads).
  4. Responde con números reales de Supabase emahub.

La selección no es manual — la determina la API key con la que el producto cliente firma la request. Cada producto tiene una API key fija asociada a un agente:

Authorization: Bearer emi_5bba56a1... → SalesAgent
Authorization: Bearer emi_81dccf8d... → SupportAgent
Authorization: Bearer emi_66d6c5... → AnalyticsAgent

Esto significa que el ruteo es 1:1 hoy. Phase 2 contempla intent detection para que un mismo producto pueda invocar agentes distintos según la pregunta.

EMA Emi es stateless: el cliente envía el historial completo en cada request. La política recomendada es:

  • Sin límite hard de turns. El widget puede tener su propio límite visual.
  • Reset al cerrar. Si el usuario cierra el chat y lo vuelve a abrir, empieza una conversación nueva.

Cuando el modelo necesita información del lado del cliente que no llegó en la request, puede pedirlo explícitamente al usuario en lugar de asumir.