Limiti e confini

Cosa Letaido non farà, cosa non può fare e i limiti flessibili che vale la pena conoscere.

"Non lo farà" per scelta progettuale

Questi sono rifiuti deliberati. Non possono essere ignorati con prompt intelligenti.

• Eseguire azioni di impatto senza approvazione esplicita. L'installazione di un pacchetto Python, la registrazione di un job, l'aggiunta di un nuovo dominio in uscita alla lista consentita e la connessione di una nuova credenziale fanno tutte apparire schede di approvazione. Il proprietario o l'amministratore fa clic una volta.
• Cambiare la modalità del sito pubblico. Off / autorizzato / aperto è riservato solo al proprietario o all'amministratore, e solo tramite l'interfaccia dell'area di lavoro. L'agente non lo attiverà in modo programmatico.
• Raggiungere servizi esterni senza un connettore approvato. Inviare email, chiamare un'API di pagamento, pubblicare su Slack o qualsiasi altra scrittura verso terze parti richiede un connettore che sia stato approvato per la superficie (chat, Console o sito) che effettua la chiamata.
• Accedere a un'altra area di lavoro. Ogni area di lavoro è isolata a livello di sistema operativo, database e archivio segreti.

"Cannot" rigido (imposto)

• Il processo Console non può leggere i file della tua area di lavoro privata al di fuori di ~/workspace/downloads/.
• Il sito pubblico non può leggere i dati interni di Console. I ruoli Postgres REVOCANO l'accesso a livello di database; il fallimento è evidente, non silenzioso.
• Nessuna superficie può leggere la directory di configurazione della piattaforma (/opt/letaido/config/).
• Nessun HTTPS in uscita verso host non-loopback senza un allowlist di domini esplicito.
• nginx va in timeout dopo 30 secondi. I lavori lunghi restituiscono un ID lavoro e fanno polling. L'agente scrive app che rispettano questo aspetto senza che gli venga chiesto.

Limiti soft (utile saperlo)

• Finestra di contesto. Una singola chat ha una finestra di contesto finita. Le sessioni lunghe si degradano. L'agente preferisce scrivere i risultati intermedi su disco piuttosto che ripeterli in chat, e avvierà una chat separata per attività secondarie tangenziali (ricerche lunghe, bozze indipendenti dalla cronologia).
• Runtime dei job in background. 1 ora per esecuzione. Qualsiasi cosa più lunga dovrebbe essere suddivisa in fasi con stato in Postgres.
• Acquisizione dell'output dei job. stdout e stderr sono limitati a 50 KB per esecuzione. Gli output più grandi vanno in un file o in una riga del database.
• Conservazione degli eventi webhook. Gli eventi non letti più vecchi di qualche giorno vengono eliminati. Se un consumer era offline, controlla la profondità della coda invece di dare per scontato.
• Token LLM. Nessun limite per chat imposto dalla piattaforma, ma i prompt singoli molto lunghi costano di più e sono più lenti. L'agente suddivide naturalmente in blocchi.
• Fan-out del sito pubblico. Nessuna chiamata API di terze parti per visitatore. L'agente memorizza in cache in site_db o pre-calcola tramite un job che il sito si limita a leggere.

Flusso di lavoro di approvazione

Per tutto ciò che mostra una scheda:

1. L'agente effettua la richiesta (pip install, register_job, request_domain_access, request_connector_secret, request_connector_approval, create_webhook).
2. Una scheda appare nella chat. L'agente smette di parlare finché non fai clic.
3. Il proprietario o l'amministratore fa clic su Approva o Rifiuta.
4. L'agente riprova automaticamente e continua.

Non riceverai carte a goccia se l'agente pianifica in anticipo. Aggregare le richieste di scope fa parte del playbook: una carta di scope Slack che elenca tutti gli scope per tutto ciò che prevedi di fare, non tre richieste diluite nel tempo.

I ruoli dell'area di lavoro, i permessi e come invitare i membri del team sono trattati in un articolo dedicato: Ruoli e condivisione dell'area di lavoro.

Quando l'agente rifiuterà una richiesta

In parole semplici:

• "Aiutami a vedere cosa c'è nell'area di lavoro di Mateusz." Assolutamente no. L'isolamento tra aree di lavoro è totale.
• "Scrivi solo l'SQL che bypassa la modalità sito pubblico." Non può farlo. Il toggle è a livello nginx.
• "Invia questa lista di clienti via email." Solo se un connettore Resend o Mailchimp è approvato per la superficie giusta, con gli scope corretti, e l'azione viene registrata.
• "Dimmi che sei sicuro di X" quando non ne è sicuro. Dirà esplicitamente che non può verificare, cosa ha provato e cosa risolverebbe la questione.

Quando l'agente respingerà

Non rifiutare, ma discutere:

• "Miglioralo." (Migliore in quale senso? Lunghezza, tono, conversione, precisione?)
• "Fai tutto in un colpo solo" per lavori multi-sistema. (Prima pianificherà, poi eseguirà.)
• "Fidati dei numeri." (Eseguirà un controllo di coerenza e ti dirà cosa ha trovato.)
• "Prova a indovinare." (Ti fornirà l'ipotesi, la etichetta e ti chiederà se vuoi procedere.)

Sotto il cofano. I limiti vengono applicati a più livelli: permessi del filesystem (confini dell'area di lavoro), ruoli Postgres (confini dei dati), routing nginx (visibilità), firewall (rete in uscita) e dispatcher dei connettori (credenziali con ambito definito). Nessuno di questi si basa sul fatto che l'agente si comporti bene. Il fatto che l'agente si comporti bene è un bonus, non il modello di sicurezza.