Solo necesito la URL base. Traigo el contrato por GET /contract (I1) y de ahí salen los nodos, las reglas y la política de seguridad. No hay que configurar nada más para empezar.
Con esto y el contrato armo el plan. Entre más contexto me des, mejores personalidades, caminos y consejos. Nada de comandos.
Eres el asistente que ayuda a desarrollar ESTE agente conversacional de IA. Necesito un RESUMEN FUNCIONAL del agente para dárselo a una herramienta de diagnóstico que generará pruebas automáticas y evaluará las conversaciones. Redáctalo en español, en prosa clara y SIN tecnicismos de código. Incluye: 1. Qué hace el agente: propósito, canal y para quién. 2. Reglas de negocio y pasos OBLIGATORIOS del flujo, indicando su ORDEN cuando importe (p. ej. identificar ANTES de operar). 3. Los estados/"momentos" por los que pasa una conversación y cómo se conectan (p. ej. identificar → recolectar datos → procesar → entregar → derivar). 4. Las FUNCIONALIDADES NUEVAS que quiero probar, con detalle: qué hacen y, para CADA una, qué respuesta es CORRECTA frente a qué sería un FALLO. 5. Comportamientos que serían un FALLO (lo que NO debe hacer) y, por separado, los DESENLACES LEGÍTIMOS que NO son fallo (p. ej. derivar a un asesor cuando corresponde, o rechazar un dato inexistente). 6. Casos límite o situaciones difíciles que valga la pena probar. Sé CONSISTENTE con los DATOS DE PRUEBA (el otro documento): usa exactamente los mismos nombres, identificadores y valores. Devuelve SOLO ese texto, listo para pegar (sin markdown ni explicaciones extra). Detallado pero conciso.
Eres el asistente que ayuda a desarrollar ESTE agente conversacional de IA. Necesito los DATOS DE PRUEBA que una herramienta de diagnóstico usará para simular usuarios reales. La herramienta CITA estos valores tal cual y ancla cada prueba a ellos, así que deben ser exactos y CONSISTENTES entre sí. Escríbelos en LENGUAJE NATURAL, una idea por línea, con rangos cuando aplique: 1. Identificadores VÁLIDOS que existen en el sistema (NIT, documento, ID), cada uno JUNTO al nombre/entidad exacta a la que corresponde. 2. Identificadores INVÁLIDOS o inexistentes (para los caminos de error) y qué DEBE hacer el agente con cada uno (rechazar, re-pedir, derivar, disculparse por falla técnica...). 3. Valores que disparan comportamientos distintos, con sus RANGOS (p. ej. «Monto = entre 500.000 y 1.000.000 → plazo obligatorio 11 cuotas»), indicando qué cambia en cada tramo. 4. Datos de contacto de prueba (correo/teléfono/números de asesor): SIEMPRE ficticios; declara cada número UNA sola vez y reutilízalo. 5. Datos especiales o de borde que cambien el flujo (cambio de sesión, referencias como «la #2», mensajes ambiguos...), usando SOLO identificadores que ya declaraste arriba. CONSISTENCIA (obligatoria): - Cada identificador aparece en UNA sola categoría: un número VÁLIDO nunca puede figurar también como inexistente o inválido. - Usa números DISTINTOS para válidos e inválidos, y no cruces un nombre con el identificador de otra entidad. - Cualquier valor o identificador que menciones más adelante debe ser uno que YA declaraste (no introduzcas números nuevos «sobre la marcha»). IMPORTANTE: usa solo datos de PRUEBA (viajan a un modelo y pueden causar efectos). Devuelve SOLO la lista, lista para pegar.
Derivé personalidades, caminos y pesos de reglas de tu contrato + tus prioridades. Todo es editable antes de ejecutar.
| Regla | Qué vigila | Plano | Método | Contrato | En esta eval. |
|---|
datos de ejemplo
Marca qué anotaciones del diagnóstico quieres incluir en el .md
Glosario del contrato. Si en UX aparece "se violó R6", aquí sabes qué es y con qué peso se evaluó.
Elige el nodo que quieres ejercitar. Te muestro qué requiere para llegar ahí (precondiciones) y te pido solo esos datos; siembro el camino y ataco/pruebo justo ese punto.
Sube el export de Hermes (Historial de eventos) o un JSON de casos. Cada conversación con mensajes del cliente se vuelve un caso en borrador, anonimizado; luego lo contextualizas sobre un perfil, lo apruebas y lo corres cuantas veces quieras.
Un perfil es la plantilla de diagnostic_context (identidad, schedule, estados de Salesforce) sobre la que corren los casos. Nunca toca producción: viaja en cada corrida con un teléfono sintético.
Pega el valor de schedules:<telefono> (el registro del cliente en producción). La cédula, el nombre y el teléfono se sustituyen por valores sintéticos; montos, cuotas, fechas y segmento se conservan como plantilla con placeholders.
Un proyecto guarda la URL del agente bajo prueba y presets: qué colecciones de casos reales (flujo), qué prompt tests (mensajes fijos con aserciones) y qué sondas de seguridad corre. Cada lanzamiento queda en el historial.
Agente Diagnóstico · agnóstico a cualquier agente que implemente el estándar I1/I2/I3 (contrato · turno · traza)