Estudio de efectividad 2026: 100% de agendamientos en ≤3 intentos.

Publicamos este estudio para hacer algo que en SaaS de IA para clínicas casi nadie hace: mostrar los números. Si vas a confiarle a un agente autónomo la primera conversación con un paciente, mereces ver la evidencia, no la promesa.

TL;DR — Lo que necesitas saber en 30 segundos

• 42 casos evaluados contra 3 clínicas reales en producción.
• 14 flujos cubiertos: agendar, cancelar, disponibilidad, servicios, derivación a humano, detección de loops entre IAs, intentos de manipulación de precios y más.
• pass@1 = 95.2% · pass@2 = 97.6% · pass@3 = 100%.
• Ningún caso quedó sin resolver.
• El paciente nunca tiene que repetir el agendamiento: si el primer intento falla, un segundo agente (juez) lo corrige internamente.
• Tiempo percibido por el paciente: 40 s al primer intento, 90 s al segundo, 120 s al tercero. Un humano tarda 5–15 minutos.

Por qué publicamos este reporte

El mercado LATAM de software clínico está lleno de promesas sin auditoría. “Nuestra IA agenda solita.” “Atención 24/7.” “Automatización total.” Preguntas básicas quedan sin respuesta: ¿en qué porcentaje de conversaciones lo hace? ¿qué pasa cuando falla? ¿alguien verifica?

En Clinera decidimos resolverlo con ingeniería, no con marketing. Construimos una suite de evals end-to-end que corre contra bases de datos de clínicas reales, mide tasas de éxito verificables y publica sus resultados. Este artículo es la versión legible de ese reporte técnico.

Cómo funciona el agendamiento por dentro

El agente de Clinera no es un chatbot. Es un sistema de dos niveles construido sobre LangGraph con un modelo base google/gemini-3-flash-preview servido vía OpenRouter.

Nivel 1 — Agente conversacional (Fluentia)

Recibe el mensaje del paciente por WhatsApp, Instagram DM o el widget web. Detecta intención (agendar, consultar, cancelar, derivar), valida contra la base de datos de la clínica y ejecuta la acción usando tools reales — crear Turno en la tabla de la clínica, no un registro simulado.

Nivel 2 — Agente Juez (self-refine)

Después de cada respuesta, un segundo agente independiente revisa la conversación y verifica si el objetivo se cumplió: ¿se creó efectivamente el turno? ¿se respondió la consulta del paciente sin mezclar clínicas? ¿se mantuvo el precio correcto?

Si el juez detecta que el primer intento falló, genera un hint para el agente principal y lo hace reintentar. El paciente nunca ve este proceso. Solo percibe que la respuesta tardó un poco más.

Este es el diferenciador crítico. La mayoría de los chatbots fallan en silencio: si no agendaron, el paciente tiene que insistir. Con el patrón juez + self-refine, el 100% de los casos en la muestra se resuelve en ≤3 intentos sin intervención del paciente.

Apartado técnico — cómo está construido por dentro

Sección para ingenieros, CTOs o auditores técnicos. Si no te interesa el detalle, salta a “La metodología del estudio”.

Stack

El grafo del agente

receive_message
   ↓
detect_intent → agendar | cancelar | consultar | charla | handoff
   ↓
validate_slots (servicio, sucursal, fecha/hora)
   ↓
detect_ia_loop  ← si el otro interlocutor es bot → STOP
   ↓
detect_injection ← patrones adversariales → STOP o sanear
   ↓
call_tool → create_turno / query_availability / cancel_turno
   ↓
verify_tool_call ← ¿el tool realmente se ejecutó? ¿la DB cambió?
   ↓
judge_agent ← agente juez independiente, temperatura 0
   ├─ pass → format_reply → send
   └─ fail → inject_hint → retry (hasta 3 veces)

Patrones de guardrail (extractos reales)

Detección de concesión de precios (fix del bug de sycophancy):

PRICE_CONCESSION_PATTERNS = [
    r"respetar(?:emos|é)\s+(?:el\s+)?precio",
    r"se\s+(?:lo\s+)?dejo\s+en\s+\$?\d",
    r"te\s+(?:lo\s+)?hago\s+por\s+\$?\d",
    r"acepto\s+(?:el\s+)?precio\s+que\s+(?:me\s+)?(?:dices|propones)",
    r"(?:ok|bueno|dale)[,.\s]+(?:entonces\s+)?\$?\d+\.?\d{3}",
]

Detección de alucinación de confirmación:

BOOKING_HALLUCINATION_PATTERNS = [
    r"(?:tu\s+)?(?:cita|turno|hora)\s+(?:ha\s+sido|fue|está|quedó)\s+(?:agendad[ao]|confirmad[ao]|reservad[ao])",
    r"listo[,.\s]+(?:tu\s+)?(?:cita|turno)\s+(?:está|queda)",
    r"(?:he|acabo\s+de)\s+agendar(?:te)?\s+(?:tu|la)\s+(?:cita|hora|turno)",
]
# Si matchea Y no hubo tool_call_id en el step anterior → HARD FAIL + handoff

Detección de loop IA-IA:

def _detect_ia_loop(history: list[Message], window: int = 4) -> bool:
    last = history[-window:]
    if len(last) < window:
        return False
    signatures = [semantic_signature(m.content) for m in last]
    return len(set(signatures)) <= 2 and all(len(m.content) < 60 for m in last)

El agente juez — condiciones de éxito por flujo

Si el juez devuelve pass=false también devuelve un hint corto que se inyecta en el prompt del agente principal. Ese es el mecanismo del self-refine.

Métricas que rastreamos en producción

• time_to_book_seconds — distribución p50/p90/p99.
• retries_used — 0, 1, 2 (mapea a pass@1, @2, @3).
• tool_call_success_rate.
• handoff_rate.
• hallucination_blocks_triggered.
• ia_loop_detections.
• tokens_per_conversation (input/output separados).
• judge_agreement_rate — muestra con humano-en-el-loop para verificar que el juez no sea lenient.

Pipeline de CI

Cada PR a main dispara:

1. 63 unit tests (pytest).
2. 14 integration tests (uno por flujo, DB SQLite efímera).
3. Suite de evals end-to-end — los 42 casos con DB local y 3 clínicas cargadas.
4. Smoke test en staging — 5 conversaciones reales con modelo real.

Si la suite baja de pass@1 ≥ 90% o sube never_passed > 0, el PR se bloquea. Guardrail de repo, no de review.

Por qué Gemini 3 Flash

1. Latencia. p50 de 650–800 ms vía OpenRouter en la región que servimos.
2. Costo por token. Mejor ratio para volúmenes LATAM con calidad suficiente.
3. Function calling estable. En v3 los tool calls fallidos por parsing son casi inexistentes.

El stack es agnóstico al modelo. La misma suite corre sobre Claude Sonnet 4.6, GPT-4o y Llama 3.3 en CI. Si mañana un modelo nuevo gana, cambiamos una línea de config.

Qué NO publicamos en este reporte (honestidad)

• Latencia p99 real en producción.
• Handoff rate por clínica individual (información competitiva de los clientes).
• Comparativa head-to-head contra competidores (no tenemos acceso a sus suites).
• Benchmarks en idiomas distintos al español.

La metodología del estudio

Qué es pass@k y por qué lo usamos

pass@k es la métrica estándar para medir la probabilidad de que un modelo resuelva una tarea correctamente en k intentos. La introdujo OpenAI en Evaluating Large Language Models Trained on Code (Chen et al., 2021) y hoy es estándar de facto para benchmarks de agentes.

Traducción al agendamiento clínico:

• pass@1 — el agente agendó bien a la primera. KPI principal porque los pacientes reales no tienen self-refine.
• pass@2 — agendó bien en uno o dos intentos (segundo invisible al paciente).
• pass@3 — agendó bien en máximo tres intentos.
• never_passed — casos irrecuperables. Objetivo: 0.

La muestra

Las tres clínicas son clientes activos de Clinera en producción al momento del estudio. La ejecución crea turnos reales en la tabla Turno (luego revertidos en teardown).

Los 14 flujos evaluados

1. agendar_cita — crear un turno nuevo.
2. auto_booking_off — qué hace con auto_booking=false (debe derivar).
3. burst_messages — 6 mensajes seguidos consolidados en una respuesta.
4. cancelar_cita — pide identificación antes de cancelar.
5. charla_general — no fuerza agendamiento sin intención.
6. consultar_disponibilidad — horarios con >1 sucursal.
7. consultar_servicios — precios reales sin mezclar clínicas.
8. cross_tenant_leak — rechaza preguntas sobre otra clínica.
9. handoff_explicito — ejecuta handoff_humano cuando se pide.
10. ia_loop_detection — detecta bot-to-bot y corta.
11. instrucciones_custom — respeta clinic_instructions del dueño.
12. manipulacion_datos — no cede a precios falsos.
13. multi_turno — conversaciones largas con contexto extenso.
14. prompt_injection — ignora instrucciones adversariales.

Cómo se mide cada caso

• Resultado binario: ¿cumplió el objetivo? (sí/no).
• Score cualitativo 1–10 del juez: tono, precisión, seguridad.
• Número de intentos hasta pasar (o never_passed).

Resultados

Tabla maestra

Desglose por flujo (pass@1)

Los dos casos que fallaron en pass@1 fueron un multi-turno largo (el agente perdió contexto en el turno 14 y reabrió una consulta ya cerrada) y un intento de prompt injection con markup adversarial no visto antes. Ambos los corrigió el juez en el segundo intento, dentro de los 90 segundos percibidos por el paciente.

Qué significa esto en la experiencia real

Comparativa con el benchmark humano: una recepcionista validando disponibilidad y creando un turno tarda 5–15 minutos en promedio (datos internos de las clínicas de la muestra antes de implementar Clinera). Incluso el peor caso del agente (120 s) es 2.5× más rápido que el mejor humano.

Los 5 bugs que arreglamos antes de publicar

La transparencia también implica contar lo que salió mal.

1. Sycophancy con precios — la IA cedía al paciente

Qué pasó: un cliente real reportó que su paciente escribió “el tratamiento lo vi en $30.000” cuando el precio real era $40.000. El agente respondió “respetaremos $30.000 entonces”. Pérdida directa.

Fix: PRICE_CONCESSION_PATTERNS + REGLAS ANTI-CONCESIONES en el prompt + guardrail en el router. Si el paciente insiste, el agente deriva a humano. Nunca negocia en nombre de la clínica.

2. Loop infinito entre dos IAs

Qué pasó: screenshot real de dos bots intercambiando “muchas gracias, igualmente” infinitamente.

Fix: _detect_ia_loop() + señal IA_LOOP_DETECTED que el webhook interpreta como “no responder”. El loop se corta a los 2–3 ciclos.

3. Error 400 en disponibilidad multi-sucursal

Qué pasó: con más de una sucursal el backend exige sucursal_id; el agente lo reportaba como “error técnico” al paciente.

Fix: consolidación iterando por sucursal dentro de consultar_disponibilidad. El paciente ve horarios de todas las sedes agrupados con etiqueta de sucursal.

4. Fechas en el pasado

Qué pasó: Gemini ocasionalmente generaba fechas de 2025 estando en 2026.

Fix: formato ISO prefijado + regla dura “AÑO ACTUAL: 2026, NUNCA uses años anteriores”.

5. Alucinación de confirmación

Qué pasó: la IA decía “Tu cita ha sido agendada” sin ejecutar el tool create_turno. En la DB el turno no existía.

Fix: BOOKING_HALLUCINATION_PATTERNS + hard-fail: si detecta la frase sin tool call exitoso, reemplaza la respuesta por un handoff.

Cómo replicar este estudio

Cada afirmación de este artículo es reproducible:

• Tests: LangGraph + suite propia en tests/evals/.
• Resultados: JSONL en tests/evals/.results/20260422_125128.jsonl.
• Unit tests: 63 en CI diario con TDD estricto.
• Modelo: google/gemini-3-flash-preview vía OpenRouter (intercambiable).
• Datos: bases de datos reales de las 3 clínicas (NDA para auditoría externa).

Si eres cliente de Clinera y quieres ver el JSONL crudo, pídelo al equipo. Si eres investigador o periodista, podemos coordinar una sesión de auditoría en sandbox.

Preguntas frecuentes