Cada límite aquí es permanente y a propósito. Ninguno es un bug, y conocerlos temprano cambia cómo configuras la cosa.
Si en cambio un correo particular quedó sin respuesta, eso es un diagnóstico y no un límite: por qué la IA no respondió.
Empieza al conectar. No hay historial.
Conectar un buzón inicia una vigilancia del correo nuevo. Nada de antes de la conexión se importa, y nada de lo que hagas después lo rellena.
La consecuencia práctica: conecta el buzón antes del periodo que quieres cubierto. Un buzón conectado el viernes no sabe nada del jueves, y la base de conocimiento es la única forma de darle contexto que sea anterior a él.
Solo cuenta las respuestas que salieron a través de él
La plataforma registra el correo saliente que ella envió. Una respuesta que un colega escribe en Gmail u Outlook es una respuesta real a un cliente real, y no se acredita aquí — así que el hilo puede seguir leyéndose como en espera.
Los dos proveedores fallan distinto, y no es seguro describir a uno como el otro. En Gmail la vigilancia está armada sobre la bandeja de entrada, así que su respuesta nunca llega a nosotros. En Outlook la suscripción de elementos enviados sí la entrega, y el hilo aún así no se marca como respondido.
Así que “sin respuesta” aquí siempre significa el último mensaje que veo es suyo — nunca le debes una respuesta a esta persona.
En Gmail, ve la bandeja de entrada y nada más
La vigilancia está armada sobre INBOX específicamente. El correo que se
salta la bandeja — filtrado directo a una etiqueta, o archivado al llegar —
es invisible. Si ejecutas filtros agresivos, el correo que más quieres
gestionado puede ser el correo que nunca llega.
Las instrucciones pertenecen al agente, no al buzón
No hay instrucción por canal. Lo que le dices a un agente aplica en todos los sitios donde ese agente responde. Puedes redactar una instrucción que se acote a sí misma — “cuando respondas correo en support@…” — pero eso es una petición a un modelo, no un ajuste que algo imponga.
Dos buzones que de verdad necesitan comportamiento distinto necesitan agentes distintos.
Una instrucción no puede impedir que se escriba un borrador
Esta es la que la gente prueba primero, y no funciona como parece. Decirle a un agente “no respondas a correo de marketing” cambia cómo se redacta una respuesta, no si existe. La única forma de que un prompt produzca cero borradores es que el modelo emita cero caracteres, y a un modelo al que le dicen que se calle típicamente escribe una negación cortés en su lugar — que se convierte en el borrador.
Lo que de verdad detiene una respuesta es determinista y vive en el código,
antes de que el modelo corra: el correo que se auto-identifica como
automatizado se descarta, y el correo de una dirección no-reply se muestra
pero nunca se redacta. Esos son filtros, no instrucciones, y no son
configurables por buzón.
Los borradores no están en todas partes
En la mayoría de los buzones una respuesta pendiente también se escribe en la carpeta de Borradores del proveedor. En un grupo de Microsoft 365 no — Graph no tiene API de borradores para conversaciones de grupo, así que esos viven solo en el panel.
Tampoco hay puntaje de confianza por borrador. Un borrador queda marcado por el triaje o no queda; nada califica qué tan seguro estaba el modelo, y cualquier interfaz que sugiera lo contrario lo estaría inventando.
Un modo de respuesta sin fijar significa autónomo
Si el modo guardado alguna vez falta o no se reconoce, el respaldo es autónomo — la IA envía. Es una elección deliberada sobre cuál falla es peor, y significa que fijar el predeterminado explícitamente es mejor que asumir que un campo vacío significa “no hacer nada”.
La entrega no es nuestra
Si una respuesta salió de aquí y nunca llegó, eso es SPF, DKIM, la reputación de tu dominio o el filtro de spam del destinatario. Esos viven con tu proveedor de correo y tu DNS. Este producto no los gestiona, no los monitorea ni reporta sobre ellos, y nada aquí te dirá que un mensaje fue marcado como spam.