Límites y restricciones

Qué no hará Letaido, qué no puede hacer y los límites flexibles que vale la pena conocer.

Difícil "no lo hará" (por diseño)

Estos son rechazos deliberados. No se pueden anular con prompts ingeniosos.

Realizar acciones de impacto sin aprobación explícita. Instalar un paquete de Python, registrar un trabajo, permitir un nuevo dominio saliente y conectar una nueva credencial muestran tarjetas de aprobación. El propietario o administrador hace clic una vez.
Cambiar el modo del sitio público. Desactivado / autorizado / abierto es solo para propietarios o administradores, y solo a través de la interfaz del espacio de trabajo. El agente no lo cambiará de forma programática.
Acceder a servicios externos sin un conector aprobado. Enviar correos electrónicos, acceder a una API de pagos, publicar en Slack o cualquier otra escritura en un tercero requiere un conector que haya sido aprobado para la superficie (chat, consola o sitio) que realiza la llamada.
Acceder a otro espacio de trabajo. Cada espacio de trabajo está aislado a nivel de sistema operativo, base de datos y almacén de secretos.

"No se puede" estricto (forzado)

El proceso de la consola no puede leer tus archivos privados del espacio de trabajo fuera de ~/workspace/downloads/.
El sitio público no puede leer datos internos de la consola. Los roles de Postgres REVOCAN el acceso en la capa de base de datos; el fallo es ruidoso, no silencioso.
Ninguna superficie puede leer el directorio de configuración de la plataforma (/opt/letaido/config/).
No hay HTTPS saliente a hosts que no sean loopback sin una lista de dominios permitidos explícita.
nginx agota el tiempo de espera a los 30 segundos. Los trabajos largos devuelven un ID de trabajo y sondean. El agente escribe aplicaciones que respetan esto sin que se le pida.

Límites flexibles (vale la pena conocerlos)

Ventana de contexto. Un solo chat tiene una ventana de contexto finita. Las sesiones largas se degradan. El agente prefiere escribir resultados intermedios en el disco en lugar de repetirlos en el chat, y generará un chat separado para tareas secundarias tangenciales (investigación larga, borradores independientes del historial).
Tiempo de ejecución de trabajos en segundo plano. 1 hora por ejecución. Cualquier cosa más larga debe dividirse en etapas con estado en Postgres.
Captura de salida de trabajos. stdout y stderr están limitados a 50 KB por ejecución. Las salidas más grandes van a un archivo o a una fila de base de datos.
Retención de eventos de webhook. Los eventos no leídos de más de unos días se eliminan. Si un consumidor estuvo desconectado, comprueba la profundidad de la cola en lugar de asumir.
Tokens LLM. No hay límite por chat impuesto por la plataforma, pero los prompts individuales muy largos cuestan más y son más lentos. El agente divide naturalmente en fragmentos.
Distribución del sitio público. No se hacen llamadas a API de terceros por visitante. El agente almacena en caché en site_db o precalcula mediante un trabajo que el sitio solo lee.

Flujo de trabajo de aprobación

Para todo lo que muestre una tarjeta:

El agente realiza la solicitud (pip install, register_job, request_domain_access, request_connector_secret, request_connector_approval, create_webhook).
Aparece una tarjeta en el chat. El agente deja de hablar hasta que hagas clic.
El propietario o administrador hace clic en Aprobar o Denegar.
El agente reintenta automáticamente y continúa.

No recibirás tarjetas gota a gota si el agente planifica con antelación. Agregar solicitudes de alcance es parte del manual: una tarjeta de alcance de Slack que enumere todos los alcances para todo lo que planeas hacer, no tres solicitudes por goteo.

Los roles del espacio de trabajo, los permisos y cómo invitar a compañeros de equipo tienen su propio artículo: Roles y uso compartido del espacio de trabajo.

Cuándo el agente rechazará una solicitud

En términos claros:

"Ayúdame a ver qué hay en el espacio de trabajo de Mateusz". Rotundamente no. El aislamiento entre espacios de trabajo es total.
"Simplemente escribe el SQL que omita el modo de sitio público". No puede. El interruptor está en la capa de nginx.
"Envía por correo esta lista de clientes". Solo si un conector de Resend o Mailchimp está aprobado para la superficie correcta, con los ámbitos correctos, y la acción queda registrada.
"Dime que estás seguro sobre X" cuando no está seguro. Dirá explícitamente que no puede verificarlo, qué intentó y qué resolvería la cuestión.

Cuándo el agente rechazará la solicitud

No rechazar, sino argumentar:

"Hazlo mejor". (¿Mejor en qué dimensión? ¿Longitud, tono, conversión, precisión?)
"Hazlo todo de una vez" para trabajos con múltiples sistemas. (Primero planificará y luego lo ejecutará).
"Confía en los números". (Hará una comprobación de coherencia y te dirá lo que encontró).
"Simplemente adivina". (Ofrecerá la suposición, la etiquetará y te preguntará si quieres que continúe).

Bajo el capó. Los límites se aplican en múltiples capas: permisos del sistema de archivos (límites del espacio de trabajo), roles de Postgres (límites de datos), enrutamiento nginx (visibilidad), firewall (red saliente) y el despachador de conectores (credenciales con ámbito definido). Ninguno de ellos depende de que el agente se comporte bien. Que el agente se comporte bien es una ventaja adicional, no el modelo de seguridad.