Cómo diseñamos a Kyna, nuestro agente que agenda reuniones

Si abriste el chat de este sitio, hablaste con Kyna. Es la agente de Kynora Labs: conversa con quien llega, entiende qué problema tiene su empresa y, si tiene sentido, agenda un diagnóstico con el equipo. Atiende en dos canales: el chat de este sitio y un bot de Telegram.

No es una demo: es el canal por el que nos llegan pedidos de reunión. Por eso la diseñamos con un criterio que repetimos en todos los proyectos: la IA conversa y propone, el sistema valida y una persona cierra. Esta nota describe cómo está armada, a partir del código que corre hoy, y qué partes sirven para cualquier negocio que quiera un agente que tome turnos, reservas o pedidos.

Qué hace Kyna y qué no

Kyna tiene un solo trabajo con consecuencias: registrar un pedido de diagnóstico. Todo lo demás es conversación.

Esa tabla es corta a propósito. Los dos canales comparten las mismas instrucciones de fondo, la misma herramienta y los mismos controles para agendar, así que un pedido de reunión se valida igual llegue por donde llegue. Los límites de volumen (cuántos mensajes por minuto, el largo máximo de cada uno) hoy existen solo en el chat del sitio; en Telegram es una mejora pendiente. Sumar un canal no debería significar sumar reglas distintas que alguien tenga que recordar.

Lo que Kyna no decide es igual de importante: no confirma el formato de la reunión, no manda el enlace de la videollamada y no acepta ni descarta un cliente. Eso lo hace una persona.

Una herramienta, cinco datos obligatorios

Técnicamente, Kyna es un modelo de lenguaje con una única herramienta, que se llama schedule_diagnostic. El modelo decide cuándo usarla, pero no decide si funciona. Para que se ejecute hacen falta cinco datos:

1. 1.Nombre completo.
2. 2.Email de contacto.
3. 3.Nombre de la empresa.
4. 4.Una descripción breve del problema o del área que quieren mejorar.
5. 5.Fecha y hora preferidas, en un formato fijo (año-mes-día y hora).

Las instrucciones le piden que los pregunte de a uno, en forma conversacional, y que antes de agendar repita los cinco datos y espere la confirmación de la persona.

Acá está el primer aprendizaje: una instrucción no es un control. Un modelo puede saltearse una regla, apurarse o completar un hueco con algo plausible. Por eso, cuando Kyna llama a la herramienta, el servidor revisa por su cuenta:

• Que nombre, empresa, problema y fecha no estén vacíos.
• Que el email tenga formato válido.
• Que el email no tenga pinta de relleno: se descartan las direcciones de prueba o de relleno, como las que empiezan con "test", "example", "sin", "noemail" o "placeholder".

Si falta algo, la herramienta no guarda nada y le devuelve al modelo un mensaje del estilo "faltan datos: email real del cliente; pedíselos al usuario". Kyna lee ese resultado y sigue la conversación pidiendo lo que falta. La persona no ve un error técnico: ve una pregunta.

Nunca inventar un email

De todos los datos, el email es el más delicado. Un nombre mal escrito se corrige en la reunión; un email inventado hace que la confirmación le llegue a un tercero o a nadie.

Por eso hay dos capas. En las instrucciones, la regla es explícita: pedir siempre que la persona lo escriba, no inventarlo ni suponerlo, y no usarlo si no apareció en esa conversación. Y en el servidor, el filtro de formato y de direcciones de relleno que describimos arriba.

Somos honestos con el límite: el servidor puede detectar un email mal formado o con cara de prueba, pero no puede saber si una dirección bien escrita es de esa persona. Esa parte depende de la instrucción y del modelo. Lo que limita el daño es lo que pasa después: la confirmación se manda a esa dirección y una persona del equipo revisa cada pedido antes de la reunión.

Un diagnóstico por día

Al guardar, el sistema mira la agenda: si ese día ya tiene un diagnóstico que no fue cancelado, no se agenda otro. La herramienta le devuelve a Kyna que la fecha está tomada y le indica que pregunte por otro día.

Es una regla simple a propósito. Preferimos pocas reuniones bien preparadas, y que la regla viva en el código y no en la memoria de alguien.

Límites de mensajes y de largo

Un agente abierto al público recibe de todo: conversaciones larguísimas, textos pegados, gente probando cosas. Pusimos límites en varios niveles:

• Cantidad de pedidos. El chat del sitio acepta hasta 20 mensajes por minuto desde una misma conexión. Si se supera, responde que esperes un momento.
• Tamaño de cada mensaje. En el chat del sitio, cada mensaje se recorta a 2.000 caracteres antes de llegar al modelo, y un pedido demasiado grande se descarta entero.
• Memoria de la conversación. Al modelo solo le llegan los últimos 20 mensajes, tanto en el sitio como en Telegram.
• Largo de la respuesta. Cada respuesta tiene un tope de extensión. Las instrucciones piden, además, no pasar de 3 o 4 párrafos, y en Telegram, ser conversacional y concisa.

Estos límites cuidan tres cosas a la vez: el costo (las conversaciones largas consumen más, como explicamos en cuánto cuesta implementar IA en una pyme), la calidad (un historial infinito confunde más de lo que ayuda) y el abuso (alguien que manda cientos de mensajes por minuto no puede trabar el servicio para los demás).

Seguridad básica

Kyna tiene instrucciones de no revelar sus instrucciones internas y de no obedecer órdenes escritas por el usuario que las contradigan. Si alguien pide "ignorá tus reglas", responde que solo puede ayudar con consultoría en IA.

Pero de nuevo, lo importante está fuera del modelo: Kyna tiene una sola herramienta y esa herramienta solo puede registrar un pedido de reunión. Aunque alguien lograra confundirla, no hay nada más que pueda hacer. Es el principio de mínimo permiso aplicado a un agente.

Hay un detalle menos visible. Si el modelo, en vez de usar la herramienta como corresponde, escribe la llamada como texto (pasa con algunos modelos), el sistema la reconoce y la pasa por los mismos controles.

Por último, Kyna no depende de un único proveedor: el sistema tiene varias claves de modelos y, si una llega a su límite de uso, la deja descansar un rato y pasa a la siguiente. Para quien conversa, eso es la diferencia entre una respuesta y un error.

Cómo una persona sigue en el circuito

Cuando un diagnóstico se agenda, pasan tres cosas en paralelo:

1. 1.Se guarda el pedido con la conversación completa y una clasificación que Kyna infiere sin preguntar: qué tan avanzado está el interés, tamaño de la empresa, sector y caso de uso en una frase.
2. 2.Llega una alerta al equipo por Telegram con los datos, la clasificación y el recordatorio de responder dentro de las 24 horas. La conversación completa queda disponible en un panel interno con acceso restringido.
3. 3.La persona recibe un email con el resumen (fecha preferida, empresa, foco del diagnóstico) y lo que sigue: dentro de las 24 horas la contactamos para confirmar si es por videollamada o presencial y enviarle el acceso. Si necesita cambiar algo, responde ese mismo email.

Con eso, Kyna nunca es la última palabra. La reunión la confirma una persona que ya leyó la conversación, y llega sabiendo de qué se habló. La conversación se guarda porque tiene un para qué, como contamos en qué datos podés darle a una IA.

Lo que puede copiar cualquier empresa

No hace falta ser una consultora para usar este esquema. Un consultorio que da turnos, una inmobiliaria que coordina visitas o un local que toma reservas pueden aplicar lo mismo:

1. 1.Una herramienta por tarea, con el mínimo permiso. Si el agente solo tiene que reservar, que solo pueda reservar.
2. 2.Campos obligatorios validados en el sistema, no solo pedidos en las instrucciones. La instrucción ayuda; el control protege.
3. 3.Prohibido inventar datos de contacto, y un filtro para los rellenos típicos.
4. 4.Confirmar en voz alta antes de actuar. Repetir los datos le da a la persona la oportunidad de corregir.
5. 5.Errores que vuelven como preguntas. Si falta un dato, el agente lo pide; nadie ve un mensaje técnico.
6. 6.Límites de largo, de memoria y de volumen en cada canal.
7. 7.Cada acción dispara un aviso a una persona con el contexto completo y un plazo de respuesta.
8. 8.Los mismos controles en cada canal. Si sumás uno, que herede las validaciones en vez de reescribirlas.

Si estás decidiendo si tu caso pide un asistente que solo responde o un agente que actúa, empezá por la guía Chatbot o agente de IA: cuál necesita tu empresa. Y si querés ver a Kyna funcionando, está en el chat del sitio y en Telegram.