A Letaido / docs
DOCUMENTATION

Limits & Grenzen

Was Letaido nicht tun wird, was es nicht kann und die Soft-Limits, die du kennen solltest.

Hartes „wird nicht" (nach Design)

Das sind bewusste Ablehnungen. Sie können nicht durch clevere Prompts überschrieben werden.

  • Wirkungsvolle Aktionen ohne ausdrückliche Genehmigung durchführen. Die Installation eines Python-Pakets, die Registrierung eines Jobs, das Hinzufügen einer neuen ausgehenden Domain zur Zulassungsliste und das Verbinden neuer Anmeldedaten zeigen alle Genehmigungskarten an. Der Eigentümer oder Admin klickt einmal.
  • Den öffentlichen Website-Modus umschalten. Aus / autorisiert / offen ist nur für Eigentümer oder Admins verfügbar und nur über die Workspace-Benutzeroberfläche. Der Agent schaltet ihn nicht programmatisch um.
  • Externe Dienste ohne genehmigten Connector erreichen. Das Versenden von E-Mails, das Aufrufen einer Zahlungs-API, das Posten auf Slack oder jede andere Schreibaktion in einen Drittanbieter erfordert einen Connector, der für die Oberfläche (Chat, Console oder Website) genehmigt wurde, die den Aufruf durchführt.
  • Einen anderen Workspace berühren. Jeder Workspace ist auf Betriebssystem-, Datenbank- und Secret-Store-Ebene isoliert.

Hartes „kann nicht" (erzwungen)

  • Der Konsolenprozess kann deine privaten Workspace-Dateien nicht lesen, außerhalb von ~/workspace/downloads/.
  • Die öffentliche Website kann keine internen Konsolendaten lesen. Postgres-Rollen REVOKE den Zugriff auf Datenbankebene; der Fehler ist laut, nicht still.
  • Keine Oberfläche kann das Plattform-Konfigurationsverzeichnis lesen (/opt/letaido/config/).
  • Kein ausgehendes HTTPS zu Nicht-Loopback-Hosts ohne eine explizite Domain-Allowlist.
  • nginx läuft nach 30 Sekunden ab. Lange Jobs geben eine Job-ID zurück und pollen. Der Agent schreibt Apps, die dies respektieren, ohne gefragt zu werden.

Weiche Grenzen (gut zu wissen)

  • Kontextfenster. Ein einzelner Chat hat ein begrenztes Kontextfenster. Lange Sitzungen verschlechtern sich. Der Agent bevorzugt es, Zwischenergebnisse auf die Festplatte zu schreiben, anstatt sie im Chat auszugeben, und wird einen separaten Chat für tangentiale Nebenaufgaben erstellen (lange Recherchen, verlaufsunabhängige Entwürfe).
  • Laufzeit von Hintergrundjobs. 1 Stunde pro Durchlauf. Alles, was länger dauert, sollte in Phasen mit Status in Postgres aufgeteilt werden.
  • Erfassung der Job-Ausgabe. stdout und stderr sind auf 50 KB pro Durchlauf begrenzt. Größere Ausgaben gehen in eine Datei oder eine Datenbankzeile.
  • Aufbewahrung von Webhook-Ereignissen. Ungelesene Ereignisse, die älter als ein paar Tage sind, werden verworfen. Wenn ein Consumer offline war, überprüfe die Warteschlangentiefe, anstatt davon auszugehen.
  • LLM-Token. Keine plattformbedingte Begrenzung pro Chat, aber sehr lange einzelne Prompts kosten mehr und sind langsamer. Der Agent teilt natürlich auf.
  • Verteilungsanfrage auf öffentlicher Website. Keine Drittanbieter-API-Aufrufe pro Besucher. Der Agent speichert in site_db zwischen oder berechnet über einen Job vor, den die Website nur liest.

Genehmigungsworkflow

Für alles, was eine Karte anzeigt:

  1. Der Agent stellt die Anfrage (pip install, register_job, request_domain_access, request_connector_secret, request_connector_approval, create_webhook).
  2. Eine Karte erscheint im Chat. Der Agent hört auf zu sprechen, bis du klickst.
  3. Der Inhaber oder Admin klickt auf Genehmigen oder Ablehnen.
  4. Der Agent versucht es automatisch erneut und fährt fort.

Du bekommst keine Karten häppchenweise, wenn der Agent vorausplant. Das Zusammenfassen von Scope-Anfragen ist Teil des Playbooks: eine Slack-Scope-Karte, die alle Scopes für alles auflistet, was du vorhast, nicht drei tröpfchenweise Anfragen.

Workspace-Rollen, Berechtigungen und wie du Teammitglieder einlädst, findest du in einem eigenen Artikel: Workspace-Rollen & Teilen.

Wann der Agent eine Anfrage ablehnt

In einfachem Deutsch:

  • „Hilf mir zu sehen, was in Mateusz' Workspace ist." Klares Nein. Die Workspace-Isolation ist absolut.
  • „Schreib einfach das SQL, das den Public-Site-Modus umgeht." Das kann es nicht. Der Schalter liegt auf der nginx-Ebene.
  • „Sende diese Kundenliste per E-Mail." Nur wenn ein Resend- oder Mailchimp-Connector für die richtige Oberfläche mit den richtigen Berechtigungen genehmigt ist und die Aktion protokolliert wird.
  • „Sag mir, dass du dir bei X sicher bist", wenn es sich nicht sicher ist. Es wird explizit sagen, dass es das nicht überprüfen kann, was es versucht hat und was die Frage klären würde.

Wann der Agent zurückweist

Nicht ablehnen, sondern argumentieren:

  • „Mach es besser." (Besser in welcher Hinsicht? Länge, Ton, Conversion, Genauigkeit?)
  • „Mach alles in einem Durchgang" für Multi-System-Arbeit. (Es wird zuerst planen und dann ausführen.)
  • „Vertrau mir bei den Zahlen." (Es wird eine Plausibilitätsprüfung durchführen und dir mitteilen, was es gefunden hat.)
  • „Rate einfach." (Es wird die Annahme anbieten, sie kennzeichnen und fragen, ob du fortfahren möchtest.)

Unter der Haube. Limits werden auf mehreren Ebenen durchgesetzt: Dateisystemberechtigungen (Workspace-Grenzen), Postgres-Rollen (Datengrenzen), nginx-Routing (Sichtbarkeit), Firewall (ausgehende Netzwerkverbindungen) und der Connectors-Dispatcher (begrenzte Zugangsdaten). Keine davon verlässt sich darauf, dass der Agent sich gut verhält. Dass der Agent sich zusätzlich gut verhält, ist ein Bonus, nicht das Sicherheitsmodell.

Last updated 2026-07-15