Skip to main content

​
Validar una reserva antes de guardarla

Llama a POST /api/v1/action-checks con la clave API de tu organización y espera la respuesta antes de confirmar la reserva. Compara identificadores estables del sistema de reservas o CRM, no nombres en texto libre.
El ejemplo devuelve decision: "flag_mismatch", allowed: false y un control con estado mismatch. Las decisiones posibles son:
  • proceed: todas las comparaciones coinciden, las herramientas indicadas tuvieron éxito y cada herramienta obligatoria declarada se informa como exitosa.
  • request_clarification: falta un dato utilizable o una herramienta está pendiente/no se ejecutó.
  • flag_mismatch: hay una diferencia o falló una herramienta.
La respuesta incluye claves y estados, nunca los valores de referencia. El agente debe pertenecer a la organización de la clave. Esta API no reserva, ingiere llamadas, invoca modelos ni crea trabajos. Valida los datos proporcionados: no consulta el CRM ni evita cambios concurrentes. Revalida si cambia la propuesta y conserva las protecciones transaccionales y de idempotencia de tu sistema. No confirmes una reserva si hay timeout o una respuesta distinta de 200. Límites: 64 KiB, 1–20 comparaciones y hasta 20 estados de herramientas. Las rutas acceden a campos propios de objetos, hasta seis niveles; arrays y objetos no son valores escalares. Los tipos deben coincidir y se ignoran espacios exteriores. Valores ausentes, nulos, vacíos o cadenas de más de 1.000 caracteres no pueden pasar. Declara hasta 20 requiredTools por separado de las ejecuciones en tools. Si falta una clave obligatoria en tools, el control devuelve missing, allowed: false y request_clarification (o flag_mismatch si otro control falla). La coincidencia del médico por sí sola no permite aprobar esa solicitud. Por compatibilidad, la lista predeterminada está vacía; envíala siempre que necesites exigir ejecuciones previas. Las claves de herramientas deben ser únicas y distintas de las claves de comparación. Distinguen mayúsculas después de eliminar espacios exteriores. Construye la lista a partir de las reglas de la aplicación, no de las llamadas que afirma haber hecho el LLM. La API no puede detectar un requisito omitido en ambas listas. Exige comprobaciones como disponibilidad antes de reservar; no exijas que la propia reserva ya se haya realizado para autorizarla. Informa estados basados en resultados reales. Reconstruye los datos y repite el control si cambia el médico, la cita o el estado de un requisito previo.

​
Configurar datos de referencia

En una etapa de análisis con IA, abre Datos de referencia. Añade una etiqueta y una ruta de metadatos, como booking.doctor_id o crm.patient_type. Marca como obligatorios los datos necesarios para evaluar. Los cambios se guardan con la versión del monitor y se usan también en el análisis histórico. Solo los escalares configurados entran en el bloque de referencia. Cada etapa acepta 20 campos, hasta 1.000 caracteres por valor y 6.000 en total. Los campos obligatorios ausentes o demasiado grandes dejan el monitor No evaluado; su traza muestra las etiquetas faltantes. No se invoca el modelo. Los campos opcionales ausentes se indican al evaluador. Esto es independiente de la opción anterior Usar contexto de llamada. Usa identificadores estables del profesional solicitado y propuesto para comparaciones deterministas. Un monitor de IA puede comparar la conversación con el CRM después de la llamada; la validación síncrona es una API separada.

​
Explicar las transferencias

Abre Informes → Análisis de transferencias → Crear monitor de transferencias. La plantilla editable incluye transferencias adecuadas/evitables, abandonos, motivos, pacientes nuevos/existentes, tareas completadas y preguntas relacionadas.
  1. Selecciona agentes y revisa las instrucciones según sus tareas permitidas.
  2. Añade referencias obligatorias si necesitas políticas o datos del CRM.
  3. Prueba y guarda el monitor. Revisa volumen y muestreo antes de activar un análisis histórico; abrir el informe nunca ejecuta evaluaciones.
  4. Selecciona monitor y fechas. Se muestran 14 días por defecto, hasta 90, según la fecha UTC de cada llamada.
Las tasas usan resultados conocidos y muestran numeradores y denominadores. El total de llamadas y las evaluadas se muestran por separado. Datos ausentes, filtros, muestreo y versiones antiguas no equivalen a resultados exitosos. Los desgloses y llamadas de ejemplo permiten revisión manual. Las muestras pequeñas se hacen visibles sin afirmar significancia estadística. Las preguntas requieren evidencia de relación con el resultado; proximidad no prueba causalidad.

​
Evaluar la naturalidad de la voz

Naturalidad de voz (vista previa) está desactivada por defecto y no está validada en vivo: las solicitudes de audio sintético devolvieron HTTP 500 de AWS. Mantén AUDIO_NATURALNESS_ENABLED=false en la aplicación y el worker hasta que funcione la inferencia de audio y se revisen ejemplos multilingües; actívala en ambos solo después de esa validación. El monitor de audio independiente está diseñado para evaluar los primeros 20 segundos del canal aislado del agente: naturalidad, prosodia y adecuación al idioma. Las palabras correctas pueden sonar poco naturales; un acento no es por sí solo un fallo. La degradación va de 0 (natural) a 100 (grave), con umbral predeterminado de 50. Requiere audio aislado, decodificación en el worker y configuración opcional de inferencia de audio en AWS. Audio mezclado, ruidoso o insuficiente y fallos de inferencia producen No evaluado, nunca un resultado favorable. Un fragmento no detecta defectos tardíos ni prueba que el interlocutor sea humano. Calibra con revisores multilingües antes del despliegue; no es un benchmark validado.

​
Revisar costos manteniendo cobertura de cumplimiento

Abre Informes → Informe de costos. Se mantienen separadas tres fuentes: cargos del proveedor, estimaciones de trazas y estimaciones de monitoreo. Los cargos pueden incluir costos de trazas; no los sumes. Precios desconocidos y datos no disponibles son explícitos. Las estimaciones usan consumo registrado y precios disponibles, no conciliación de facturas. La selección de empresa usa la atribución de cada llamada. Consumo histórico sin vínculo queda sin atribuir y se excluye de vistas por empresa. Referencias de sesión ambiguas no permiten atribuir costos. Selecciona solo monitores opcionales, no de cumplimiento, para estimar ahorro. El control estima una reducción adicional del gasto registrado mediante filtros o muestreo. Todos comienzan excluidos y no se modifica ninguna configuración. Los controles de cumplimiento deben mantener cobertura total. Se excluyen infraestructura y consumo no registrado. Acceso programático con el mismo alcance de organización y empresa:
  • GET /api/v1/reports/costs?companyId=UUID&from=2026-08-24&to=2026-09-06
  • GET /api/v1/reports/transfers?metricId=UUID&companyId=UUID&from=2026-08-24&to=2026-09-06
Ambos requieren acceso a Informes. Empresa y fechas son opcionales; transferencias requiere un identificador de monitor. La respuesta indica el período efectivo. Los informes escritos son instantáneas de toda la organización y se ocultan al seleccionar una empresa. Vuelve a Todos los agentes para leerlos.