Sección 10
Operación y soporte
Esta página responde lo que aparece cuando el servidor ya está escrito: reintentos, concurrencia, qué pasa si su servidor se cae, cómo prueba con un agente real, dónde ve las trazas y a quién escribe. Es la parte del contrato que no se ve en el código pero se nota en producción.
Reintentos y concurrencia
| Situación | Qué hace el Gateway |
|---|---|
| Conexión cortada antes de recibir la respuesta | Reintenta una vez, con la misma clave de idempotencia y un requestId nuevo. |
| Tiempo de espera agotado (30 s) | No reintenta. Informa al agente de un fallo transitorio y la conversación continúa sin la herramienta. |
error_type: "SYSTEM" | No reintenta por su cuenta. El agente puede volver a intentarlo si el usuario insiste, y esa será una llamada nueva con clave nueva. |
Cualquier otro error_type | No reintenta: son respuestas de negocio, no fallos. |
| Bucle del modelo (misma llamada, mismos argumentos, en el mismo turno) | Se descarta antes de salir a su servidor. |
Concurrencia. Una conversación es secuencial: no habrá dos llamadas simultáneas del mismo diálogo. Lo que sí ocurre en paralelo son conversaciones distintas del mismo tenant, y en horas punta pueden ser decenas. Dimensione por conversaciones concurrentes, no por usuarios.
Clave de idempotencia en vuelo. Si le llega una clave que todavía está ejecutándose, no
espere ni duplique: responda error_type: "SYSTEM" con un mensaje neutro. El agente lo trata como
fallo transitorio, y el resultado de la primera ejecución queda registrado bajo esa clave para
cuando se consulte de nuevo.
Si su servidor deja de responder
| Momento | Qué pasa |
|---|---|
| Un fallo aislado | El agente responde sin ese dato. La conversación no se cae. |
| Fallos repetidos en pocos minutos | El Gateway deja de ofrecer esa herramienta durante unos minutos y la reintenta después. El agente no promete lo que no puede hacer. |
| Caída sostenida | La capacidad se desactiva y se avisa al contacto técnico que usted registró. Se reactiva sola cuando su servidor vuelve a responder correctamente. |
Nada de esto interrumpe una llamada telefónica en curso: el agente sigue conversando con lo que tiene.
Entorno de pruebas
Se da de alta junto con la URL y la credencial (README) y es donde corre la certificación, porque hay comprobaciones que escriben.
| Requisito | Detalle |
|---|---|
| Credencial propia | DEBE ser distinta de la de producción. |
| Mismo catálogo | DEBE exponer las mismas herramientas con los mismos esquemas. Si divergen, la certificación no dice nada útil sobre producción. |
| Datos semilla | DEBERÍA tener, al menos: un cliente localizable, un cliente que no le pertenezca al primero, una entidad en estado terminal (una cita cancelada, por ejemplo) y un catálogo con al menos dos ítems. Sin eso no se pueden probar propiedad ni estado terminal. |
| Aislamiento | DEBE no enviar correos, mensajes ni cobros reales. |
Pruebas con un agente real
Cuando la certificación pasa, se habilita una conversación de prueba: un agente de Asixto configurado con sus herramientas, sobre un canal de prueba (chat web y, si su plan incluye voz, un número de pruebas). Sirve para ver lo que ninguna batería detecta: si el agente entiende sus descripciones, si elige bien entre dos herramientas parecidas y si sus respuestas se leen bien en voz alta.
Recomendación: lleve un guion de cinco o seis conversaciones reales de su operación y contraste lo que el agente hace con lo que haría un asesor.
Trazas y diagnóstico
- Registre por invocación el
com.asixto/requestIdque recibe. Es la referencia común: con ese identificador Asixto puede localizar la conversación, y usted su ejecución. - El informe de certificación se entrega con el resultado por comprobación y la fecha de la última ejecución. Quedará consultable en su panel de la aplicación cuando llegue la etapa 2 (README); hasta entonces se lo entrega su contacto técnico en cada ejecución.
- Los tiempos que Asixto mide son de extremo a extremo, así que pueden ser algo mayores que los suyos: incluyen red y encolado.
Versionado de su servidor
Declare una versión en la identidad de su servidor y súbala cuando cambie el catálogo. No dispara nada automático, pero aparece en el informe y hace que un incidente se pueda fechar.
Lo que sí obliga a recertificar está en la página 08: herramienta nueva, cambio de esquema, renombrado, cambio de credencial o de URL.
Datos, retención e idioma
| Tema | Cómo funciona |
|---|---|
| Qué guarda Asixto de sus respuestas | El texto que entra a la conversación, como parte del historial de esa conversación. No se replica su base de datos ni se construye un catálogo paralelo. |
| Retención | La del historial de conversaciones del tenant, según su plan. Se acuerda en el contrato comercial, no aquí. |
| Datos personales | Devuelva el mínimo necesario (garantía 5). Lo que no envía, no se almacena. |
| Idioma | El user_message y los textos legibles en el idioma de atención del tenant (hoy español). Si opera en varios idiomas, escálelo: el _meta no trae idioma en la v1. |
| Media de entrada | Si el cliente final envía una foto o un documento, su herramienta no lo recibe: el agente lo procesa y, si es relevante, lo describe en los argumentos de texto. |
Contacto
| Para | Canal |
|---|---|
| Dudas de interpretación del contrato, escenarios nuevos, borrado, interruptores por acción, multi-idioma | El contacto técnico que le asigna Asixto en la incorporación |
| Incidentes en producción | El mismo canal, citando el requestId y la hora aproximada |
| Cambios que afectan al contrato | Se anuncian con antelación según la página 09 |
Cuando esta documentación dice «escálelo», se refiere a ese contacto técnico. Ninguna de esas decisiones se resuelve improvisando en el código: casi todas afectan a los tres repositorios de Asixto y se coordinan.