failproofai 1.0.1-beta.1 → 1.0.1

package/.next/standalone/docs-old/de/agenteye/python-sdk.mdx

@@ -0,0 +1,436 @@
+---
+title: "Python SDK"
+description: "Beobachte genau, was deine KI-Agenten in der Produktion getan haben: jeden Agentenlauf, Tool-Aufruf, Modellanfrage, Hook und menschlichen Eingriff."
+---
+
+
+Beobachte genau, was deine KI-Agenten in der Produktion getan haben: jeden Agentenlauf, Tool-Aufruf, Modellanfrage, Hook und menschlichen Eingriff. Das Failproof AI Observability Python SDK zeichnet diesen Verlauf direkt aus deinem Agenten-Code auf, damit du debuggen, auditieren und nachvollziehen kannst, was passiert ist. Verwende es immer dann, wenn Failproof AI Observability deine Agenten beobachten soll.
+
+Intern schreibt das SDK strukturierte Events in lokale JSONL-Dateien, und der Collector-Daemon liest diese und überträgt sie automatisch an die Plattform. Du musst diese Dateien nicht selbst verwalten.
+
+> **Tipp:** Neu bei Failproof AI Observability? Diese Seite ist die vollständige SDK-Event-Referenz.
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/VWxukZc5k7s?autoplay=1&mute=1&loop=1&playlist=VWxukZc5k7s&rel=0&playsinline=1" title="Watch: Agent Tracing by Failproof AI (2 min)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+---
+
+## Installation
+
+Das SDK wird Kunden als privates Wheel und nicht über einen öffentlichen Paketindex bereitgestellt. Dein Onboarding erklärt, wie du es erhältst, installierst und versionierst — wende dich an deinen Failproof AI-Ansprechpartner, wenn du Zugang benötigst.
+
+Sobald es installiert ist, überprüfe die Installation:
+
+```bash
+python -c "import agenteye; print(agenteye.__version__)"
+```
+
+Möchtest du die gesamte Integration von einem Coding-Agent erledigen lassen? Der [Python SDK Agent Skill](/de/agenteye/python-sdk-skill) kennt den Installationspfad, plant die Instrumentierungspunkte, schreibt sie und überprüft, ob die Events ankommen.
+
+---
+
+## Schnellstart
+
+```python
+import agenteye
+
+agenteye.configure(environment="production")
+
+agenteye.event.agent_start(session_id="run-001", agent_id="planner", goal="answer user query")
+
+agenteye.event.tool_use(
+    session_id="run-001",
+    agent_id="planner",
+    tool_name="web_search",
+    tool_call_id="toolu_01",
+    input={"query": "latest AI research"},
+)
+
+agenteye.event.tool_result(
+    session_id="run-001",
+    agent_id="planner",
+    tool_name="web_search",
+    tool_call_id="toolu_01",
+    output={"results": ["..."]},
+)
+
+agenteye.event.agent_end(session_id="run-001", agent_id="planner", outcome="success")
+```
+
+### Einen echten Aufruf instrumentieren
+
+In der Praxis umhüllst du deinen bestehenden Agenten-Code. Klammere einen Modellaufruf mit `model_request` davor und `model_response` danach ein, sodass die beiden Events die echte Anfrage umspannen und Failproof AI Observability sie zuordnen kann:
+
+```python
+import anthropic
+import agenteye
+
+agenteye.configure(environment="production")
+client = anthropic.Anthropic()
+
+messages = [{"role": "user", "content": "Summarise today's incidents."}]
+
+agenteye.event.model_request(
+    session_id="run-001",
+    agent_id="planner",
+    model="claude-sonnet-4-6",
+    messages=messages,
+)
+
+reply = client.messages.create(
+    model="claude-sonnet-4-6",
+    max_tokens=512,
+    messages=messages,
+)
+
+agenteye.event.model_response(
+    session_id="run-001",
+    agent_id="planner",
+    model=reply.model,
+    stop_reason=reply.stop_reason,
+    input_tokens=reply.usage.input_tokens,
+    output_tokens=reply.usage.output_tokens,
+    content=[block.model_dump() for block in reply.content],
+)
+```
+
+Umhülle Tool-Aufrufe auf dieselbe Weise mit `tool_use` und `tool_result`, wobei du eine `tool_call_id` für beide Events verwendest.
+
+So sehen diese Events aus, sobald sie das Dashboard erreichen — farblich nach Typ kodiert und filterbar nach Umgebung, Agent und Session:
+
+![Der Live-Events-Stream, farblich nach Event-Typ kodiert und filterbar nach Umgebung, Agent und Session](/agenteye/images/events-stream.png)
+
+---
+
+## configure()
+
+```python
+agenteye.configure(
+    base_dir=None,           # Path | str | None. Default: $AGENTEYE_HOME or ~/.agenteye
+    flush_interval=0.5,      # float, seconds between flush cycles
+    environment=None,        # str | None. Deployment environment label
+)
+```
+
+Einmalig vor jedem `event.*`-Aufruf aufrufen. Kann weggelassen werden; die Standardwerte funktionieren sofort. Alle Argumente sind nur als Schlüsselwortargumente zulässig; übergib sie wie oben gezeigt mit Namen.
+
+Wenn `base_dir` `None` ist (Standard), liest das SDK `$AGENTEYE_HOME` falls gesetzt,
+andernfalls wird auf `~/.agenteye` zurückgefallen. Dies entspricht der eigenen Auflösung des Collectors,
+sodass eine einzige `AGENTEYE_HOME`-Umgebungsvariable den gemeinsamen Event-Spool für
+SDK und Collector konfiguriert.
+
+---
+
+## Umgebung
+
+Zeichne jedes Event mit einer Deployment-Umgebung aus (`production`, `staging`, `qa`, `canary` usw.). Einmalig setzen; das SDK hängt sie automatisch an jedes Event an.
+
+**Option 1: über `configure()`:**
+
+```python
+agenteye.configure(environment="production")
+```
+
+**Option 2: über eine Umgebungsvariable:**
+
+```bash
+export AGENTEYE_ENVIRONMENT=production
+```
+
+**Priorität:** `configure(environment=...)` hat Vorrang vor der Umgebungsvariable. Wenn keines von beiden gesetzt ist, wird standardmäßig `"dev"` verwendet.
+
+Der Umgebungswert erscheint als erstklassiger Filter im Dashboard und wird serverseitig für schnelle Abfragen gespeichert.
+
+> **Warnung:** Umgebungswerte dürfen kein literales `,` Komma enthalten. Die Dashboard-Filter verwenden kommagetrennte Mehrfachauswahl in der URL (`?environment=prod,staging`), sodass eine Umgebung namens `prod,blue` in zwei Werte aufgeteilt würde. Events mit kommaenthaltenden Umgebungswerten werden beim Einlesen abgelehnt.
+
+---
+
+## Daten und Datenschutz
+
+Das SDK zeichnet nur die Felder auf, die du explizit übergibst. Prompts, Nachrichten, Tool-Eingaben und -Ausgaben sowie Modell-Inhalte werden ausschließlich deshalb erfasst, weil du sie an einen `event.*`-Aufruf übergibst. Es werden keine Informationen aus deinem Prozess gelesen oder implizit erfasst. Jedes Feld, das du nicht setzt, wird vollständig aus dem Event weggelassen und nicht auf Festplatte geschrieben.
+
+Das macht die Bereinigung zu deiner Wahl und Verantwortung. Wenn ein Prompt oder ein Tool-Payload personenbezogene Daten oder Secrets enthält, die du nicht speichern möchtest, entferne oder maskiere sie, bevor du sie an die Event-Methode übergibst.
+
+---
+
+## Event-Referenz
+
+Die meisten Events kommen in Start-/End-Paaren, die eine Korrelations-ID teilen: `tool_use` und `tool_result` teilen eine `tool_call_id`, `hook_triggered` und `hook_completed` teilen eine `hook_id`, und `human_wait` und `human_input` teilen eine `input_id`. Sende das Start-Event, führe die Arbeit aus und sende dann das End-Event mit derselben ID. Failproof AI Observability ordnet das Paar zu und berechnet `duration_ms` für dich, sodass du `duration_ms` nie selbst übergibst.
+
+![Der git-artige Ausführungsgraph einer Session neben ihrer Event-Zeitleiste, aus den gepaarten Events rekonstruiert, mit dem Tool/Modell/Hook-Aufschlüsselungspanel](/agenteye/images/session-detail.png)
+
+Alle Event-Methoden erfordern diese zwei Felder:
+
+| Feld | Typ | Beschreibung |
+|---|---|---|
+| `session_id` | `str` | Identifiziert den übergeordneten Agentenlauf |
+| `agent_id` | `str` | Identifiziert, welcher Agent innerhalb der Session das Event ausgelöst hat |
+
+Alle Methoden akzeptieren auch beliebige `**kwargs` für benutzerdefinierte Metadaten (siehe [Benutzerdefinierte Felder](#custom-fields)).
+
+---
+
+### `event.agent_start()`
+
+Wird ausgelöst, wenn ein Agent die Arbeit beginnt.
+
+```python
+agenteye.event.agent_start(
+    session_id="run-001",
+    agent_id="planner",
+    goal="answer user query",   # str | None
+    parent_id=None,             # str | None - parent agent_id for nested agents
+)
+```
+
+---
+
+### `event.agent_end()`
+
+Wird ausgelöst, wenn ein Agent die Arbeit beendet.
+
+```python
+agenteye.event.agent_end(
+    session_id="run-001",
+    agent_id="planner",
+    outcome="success",          # str | None
+    summary="Answered query",   # str | None
+)
+```
+
+---
+
+### `event.tool_use()`
+
+Wird ausgelöst, wenn ein Agent ein Tool aufruft. Wird mit `tool_result` gepaart; das SDK berechnet `duration_ms` automatisch.
+
+```python
+agenteye.event.tool_use(
+    session_id="run-001",
+    agent_id="planner",
+    tool_name="web_search",     # str, required
+    tool_call_id="toolu_01",    # str, required - correlation key for the matching tool_result
+    input={"query": "..."},     # dict | None
+)
+```
+
+---
+
+### `event.tool_result()`
+
+Wird ausgelöst, wenn ein Tool einen Wert zurückgibt. Korreliert mit `tool_use` über `tool_call_id`.
+
+```python
+agenteye.event.tool_result(
+    session_id="run-001",
+    agent_id="planner",
+    tool_name="web_search",
+    tool_call_id="toolu_01",        # must match the prior tool_use
+    output={"results": ["..."]},    # Any | None
+    error=None,                     # str | None - set if the tool raised
+    # duration_ms is computed automatically - do not pass it
+)
+```
+
+---
+
+### `event.model_request()`
+
+Wird ausgelöst, unmittelbar bevor ein Prompt an ein LLM gesendet wird.
+
+```python
+agenteye.event.model_request(
+    session_id="run-001",
+    agent_id="planner",
+    model="claude-sonnet-4-6", # str | None - any provider/model string; not validated
+    messages=[                   # list[dict] | None - conversation turns
+        {"role": "user", "content": "..."},
+    ],
+    system="You are helpful.",   # Any | None - str or list of content blocks
+    tools=[                      # list[dict] | None - tool schemas offered to the model
+        {"name": "search", "input_schema": {"type": "object"}},
+    ],
+)
+```
+
+`messages`-Einträge akzeptieren entweder einen einfachen String als `content` oder Anthropic-artige Listen von Content-Blöcken als `content`. Sampling-Parameter (`temperature`, `max_tokens` usw.) können als zusätzliche kwargs übergeben werden.
+
+---
+
+### `event.model_response()`
+
+Wird ausgelöst, wenn das LLM eine Antwort zurückgibt.
+
+```python
+agenteye.event.model_response(
+    session_id="run-001",
+    agent_id="planner",
+    model="claude-sonnet-4-6", # str | None - any provider/model string; not validated
+    stop_reason="end_turn",     # str | None
+    input_tokens=1024,          # int | None
+    output_tokens=256,          # int | None
+    content=[                    # Any | None - str, or list of content blocks
+        {"type": "text", "text": "..."},
+    ],
+    role="assistant",            # str | None
+)
+```
+
+`content` akzeptiert entweder einen einfachen String (generische Anbieter) oder eine Liste von Anthropic-artigen Content-Blöcken. Tool-Aufrufe befinden sich innerhalb von `content` als `{"type": "tool_use", ...}`-Blöcke, ohne ein separates `tool_calls`-Feld.
+
+---
+
+### `event.hook_triggered()`
+
+Wird ausgelöst, wenn ein Hook feuert. Wird mit `hook_completed` gepaart; das SDK berechnet `duration_ms` automatisch.
+
+```python
+agenteye.event.hook_triggered(
+    session_id="run-001",
+    agent_id="planner",
+    hook_name="pre_tool_use",   # str, required
+    hook_id="hook-abc",         # str, required - correlation key
+    trigger_event="tool_use",   # str | None
+    input={"tool": "search"},   # Any | None
+)
+```
+
+---
+
+### `event.hook_completed()`
+
+Wird ausgelöst, wenn ein Hook abgeschlossen ist. Korreliert mit `hook_triggered` über `hook_id`.
+
+```python
+agenteye.event.hook_completed(
+    session_id="run-001",
+    agent_id="planner",
+    hook_name="pre_tool_use",
+    hook_id="hook-abc",         # must match the prior hook_triggered
+    outcome="allow",            # str | None
+    output=None,                # Any | None
+    error=None,                 # str | None
+    # duration_ms is computed automatically - do not pass it
+)
+```
+
+---
+
+### `event.error()`
+
+Wird ausgelöst, wenn ein nicht behandelter Fehler auftritt.
+
+```python
+agenteye.event.error(
+    session_id="run-001",
+    agent_id="planner",
+    error_type="TimeoutError",  # str, required
+    message="timed out",        # str, required
+    traceback="Traceback...",   # str | None
+)
+```
+
+---
+
+## Human-in-the-Loop-Events
+
+Human-in-the-Loop-Events geben dir Kontrolle über die Momente, in denen eine Person in die Ausführung des Agenten eingreift (auf Genehmigung warten, Eingaben liefern, pausieren oder den Agenten stoppen). Sie ermöglichen es dir zu messen, wie lange Menschen für eine Antwort benötigen (das SDK berechnet `duration_ms` bei gepaarten Events automatisch), zu auditieren, wer einen Agenten pausiert oder unterbrochen hat, sowie Genehmigungs- und Aufsichts-Workflows aufzubauen, die im Dashboard sichtbar sind.
+
+### `event.human_wait()`
+
+Wird ausgelöst, wenn der Agent die Ausführung pausiert, um auf eine menschliche Eingabe zu warten. Wird mit `human_input` gepaart; das SDK berechnet `duration_ms` automatisch (wie lange der Mensch für eine Antwort brauchte).
+
+```python
+agenteye.event.human_wait(
+    session_id="run-001",
+    agent_id="planner",
+    input_id="inp-abc",                          # str, required - correlation key for the matching human_input
+    prompt="Do you approve this action?",        # str | None - the question shown to the human
+    options=["approve", "reject", "defer"],      # list[str] | None - choices presented to the human
+    reason="approval_required",                  # str | None - why the agent is waiting
+)
+```
+
+### `event.human_input()`
+
+Wird ausgelöst, wenn ein Mensch eine Eingabe macht und der Agent fortfährt. Korreliert mit `human_wait` über `input_id`. `duration_ms` wird automatisch berechnet und darf nicht vom Aufrufer übergeben werden.
+
+```python
+agenteye.event.human_input(
+    session_id="run-001",
+    agent_id="planner",
+    input_id="inp-abc",    # str, required - must match the prior human_wait
+    response="approve",    # str | None - the human's answer (free text or selected option)
+    # duration_ms is computed automatically - do not pass it
+)
+```
+
+### `event.human_pause()`
+
+Wird ausgelöst, wenn ein Mensch den Agenten aktiv pausiert (z. B. über eine Dashboard-Steuerung). Der Agent wird ausgesetzt, aber nicht beendet.
+
+```python
+agenteye.event.human_pause(
+    session_id="run-001",
+    agent_id="planner",
+    reason="user_requested",  # str | None
+    user_id="usr_42",         # str | None - who paused the agent
+)
+```
+
+### `event.human_interrupt()`
+
+Wird ausgelöst, wenn ein Mensch den Agenten mitten in der Ausführung aktiv stoppt. Im Gegensatz zu `human_pause` wird die Arbeit des Agenten beendet und nicht nur ausgesetzt.
+
+```python
+agenteye.event.human_interrupt(
+    session_id="run-001",
+    agent_id="planner",
+    reason="output_incorrect",       # str | None
+    user_id="usr_42",                # str | None - who interrupted the agent
+    at_step="tool_use:web_search",   # str | None - what the agent was doing when stopped
+)
+```
+
+---
+
+## Benutzerdefinierte Felder
+
+Alle zusätzlichen Schlüsselwortargumente werden nach den Standardfeldern an das Event angehängt:
+
+```python
+agenteye.event.tool_use(
+    session_id="run-001",
+    agent_id="planner",
+    tool_name="db_query",
+    tool_call_id="toolu_02",
+    tenant_id="acme",           # custom field
+    region="us-east-1",         # custom field
+)
+```
+
+`timestamp`, `type` und `environment` sind reserviert und lösen einen `ValueError` aus (`Reserved field names cannot be used as custom fields: [...]`), wenn sie als benutzerdefinierte Felder übergeben werden. `session_id` und `agent_id` sind erforderliche Parameter bei jeder Event-Methode und können nicht ein zweites Mal übergeben werden; Python löst einen `TypeError` aus, wenn du es versuchst. Setze die Umgebung mit `configure(environment=...)` (oder der `AGENTEYE_ENVIRONMENT`-Variable).
+
+Halte Payloads als strukturiertes JSON, wenn du ihre Felder abfragen möchtest. Werte, die JSON nicht nativ unterstützt — wie Datetimes, UUIDs, Dezimalzahlen, Sets, Bytes oder Modell-Objekte — werden in Strings umgewandelt, damit die Aufzeichnung sicher fortgesetzt werden kann.
+
+---
+
+## Wie Events geschrieben werden
+
+Events werden im Prozess gepuffert und alle `flush_interval` Sekunden auf Festplatte geschrieben (Standard: 500 ms). Jeder Flush schreibt eine JSONL-Datei:
+
+```text
+~/.agenteye/events/event-2026-04-01T12-00-00-000Z.jsonl
+```
+
+Der Collector überwacht dieses Verzeichnis und lädt Dateien automatisch hoch. Du musst diese Dateien nicht direkt verwalten.
+
+Jede Datei wird atomar geschrieben: Das SDK schreibt zunächst in eine temporäre Datei und benennt sie dann an ihren Zielort um, sodass der Collector niemals eine halb geschriebene Datei sieht. Ein abschließender Flush wird auch beim Beenden deines Prozesses ausgeführt, sodass Events, die im letzten Intervall gepuffert wurden, nicht verloren gehen. Wenn der Collector offline ist, sammeln sich Events einfach als Dateien auf der Festplatte an und werden übertragen, sobald er wieder verfügbar ist.
+
+---
+
+## Nächste Schritte
+
+- [Event-Stream](/de/agenteye/event-stream): Beobachte, wie diese Events live ankommen, farblich kodiert und filterbar nach Umgebung, Agent und Session.
+- [Sessions](/de/agenteye/sessions): Sieh, wie die gepaarten Events jeden Agentenlauf als Ausführungsgraph und Zeitleiste rekonstruieren.

package/.next/standalone/docs-old/de/agenteye/queries.mdx

@@ -0,0 +1,56 @@
+---
+title: "Abfragen"
+description: "Stellen Sie Ihren Agentendaten beliebige Fragen und erhalten Sie in Sekunden eine Antwort."
+---
+
+
+Stellen Sie Ihren Agentendaten beliebige Fragen und erhalten Sie in Sekunden eine Antwort. Failproof AI Observability bietet Ihnen eine Bibliothek gespeicherter, sofort ausführbarer Abfragen über Ihre Events und Auswertungen – damit starten Sie mit einem funktionierenden Beispiel statt vor einem leeren SQL-Editor.
+
+![Die Bibliothek gespeicherter Abfragen: ein Raster wiederverwendbarer Abfragen, sowohl eingebaute Vorlagen als auch eigene](/agenteye/images/queries.png)
+
+*Ihre Bibliothek gespeicherter Abfragen unter `/<org-slug>/queries`: eingebaute Vorlagen neben den Abfragen, die Ihr Team gespeichert hat.*
+
+## Mit einer Vorlage starten, nicht auf einer leeren Seite
+
+Sie müssen sich keine Tabellennamen merken oder SQL von Grund auf schreiben. Die Bibliothek öffnet sich mit eingebauten Vorlagen für die Fragen, die Teams am häufigsten stellen – direkt neben den Abfragen, die Ihr Team selbst gespeichert und benannt hat. Wählen Sie eine aus, die Ihrem Bedarf nahekommt, und Sie sind der Antwort schon einen großen Schritt näher.
+
+Jede gespeicherte Abfrage ist organisationsweit gültig und geteilt, sodass nützliche Abfragen Ihrer Teammitglieder auch Ihnen zur Verfügung stehen. Geben Sie einer Abfrage einmalig einen Namen und eine Beschreibung, und jede Person in Ihrer Organisation kann sie finden, ausführen oder ihre Ergebnisse später in ein Dashboard einbinden.
+
+Sie finden die Bibliothek unter `/<org-slug>/queries`.
+
+## Im SQL-Composer anpassen und ausführen
+
+Öffnen Sie eine beliebige Abfrage, und sie wird im SQL-Composer angezeigt, wo Sie sie anpassen und die Antwort sofort sehen können – kein Export, kein Umweg, kein Warten auf jemand anderen.
+
+![Der SQL-Abfrage-Composer mit einer gespeicherten Abfrage, einer Schema-Seitenleiste und einem Live-Ergebnisraster](/agenteye/images/query-lab.png)
+
+*Der SQL-Composer: Ihre Abfrage auf der linken Seite, eine Schema-Seitenleiste damit Sie nie einen Spaltennamen erraten müssen, und ein Live-Ergebnisraster darunter.*
+
+- **Eine Schema-Seitenleiste** zeigt die Analysetabellen und ihre Spalten übersichtlich an, sodass Sie eine Abfrage formulieren können, ohne nach Feldnamen suchen zu müssen.
+- **Ein Live-Ergebnisraster** liefert Zeilen sofort nach der Ausführung, sodass Sie in Sekunden iterieren können, anstatt zu raten und erneut zu raten.
+- **Nur-Lese-Design.** Abfragen werden gegen Ihren Event-Store ausgeführt und serverseitig validiert: Nur `SELECT`- und `WITH`-Anweisungen sind erlaubt, mit einem Anweisungs-Timeout und einer Zeilenbegrenzung. Eine explorative Abfrage kann Ihre Daten niemals verändern, und eine unkontrolliert laufende wird automatisch gestoppt.
+
+Zufrieden mit dem Ergebnis? Speichern Sie es in der Bibliothek, damit das gesamte Team davon profitiert, oder binden Sie die Ausgabe als Linien-, Balken-, Flächen- oder Kreisdiagramm-Kachel in ein Dashboard ein.
+
+## Über das Terminal ausführen oder vom Assistenten schreiben lassen
+
+Dieselben gespeicherten Abfragen folgen Ihnen überall hin:
+
+- **Über das Terminal.** Die `agenteye`-CLI listet, führt aus und speichert dieselben Abfragen, sodass Sie ein Ergebnis in ein Skript einfügen, in CI einbinden oder an einen Coding-Agenten weitergeben können.
+
+```bash
+agenteye query list                 # die gleichen gespeicherten Abfragen, aus Ihrem Terminal
+agenteye query run errs --arg prod  # eine ausführen und die Zeilen ausgeben (--json zum Weiterleiten hinzufügen)
+```
+
+  Siehe [CLI und Agenten](/de/agenteye/cli-and-agents) für den vollständigen Befehlssatz.
+
+- **Über den KI-Assistenten.** Sie sind unsicher, wie Sie das SQL formulieren sollen? Fragen Sie den [KI-Assistenten](/de/agenteye/assistant) im Dashboard auf normalem Deutsch, und er wird die Abfrage entwerfen und für Sie in Ihrer Bibliothek speichern.
+
+Das Ausführen einer gespeicherten Abfrage ist durch die Berechtigung `queries:run` geschützt, die getrennt von den Berechtigungen zum Erstellen oder Löschen von Abfragen verwaltet wird. So können Sie Lesezugriff erteilen, ohne allen zu erlauben, die Bibliothek umzuschreiben.
+
+## Verwandte Themen
+
+- [Dashboards](/de/agenteye/dashboards): Abfrageergebnisse in geteilte, organisationsweite Diagramme einbinden.
+- [KI-Assistent](/de/agenteye/assistant): Fragen auf normalem Deutsch stellen und eine fertige Abfrage erhalten.
+- [CLI und Agenten](/de/agenteye/cli-and-agents): Dieselben Abfragen über das Terminal ausführen und speichern.

package/.next/standalone/docs-old/de/agenteye/security.mdx

@@ -0,0 +1,68 @@
+---
+title: "Sicherheit"
+description: "Failproof AI Observability ist darauf ausgelegt, nah an Ihren Produktions-Agents zu laufen – das bedeutet, es sieht Ihre Prompts, Tool-Eingaben und Ausgaben."
+---
+
+
+Failproof AI Observability ist darauf ausgelegt, nah an Ihren Produktions-Agents zu laufen – das bedeutet, es sieht Ihre Prompts, Tool-Eingaben und Ausgaben. Diese Seite erklärt, wie die Daten isoliert, kontrolliert und in Ihren Händen bleiben. Wenn Sie Failproof AI Observability im Rahmen einer Sicherheitsprüfung evaluieren, beginnen Sie hier.
+
+---
+
+## Ihre Daten bleiben in Ihrer Umgebung
+
+Failproof AI Observability wird selbst gehostet. Events, Prompts, Modellantworten und Analysen werden in Ihren eigenen Datenbanken, in Ihrer eigenen Umgebung gespeichert. Es werden keine Daten zur Speicherung an einen Drittanbieter-SaaS übermittelt – Ihre Daten verbleiben in Ihrem eigenen Cloud-Account.
+
+---
+
+## Mandantenisolierung
+
+Eine Failproof AI Observability-Instanz kann viele Organisationen beherbergen, und jede ist auf Speicherebene isoliert – durchgesetzt von der Datenbank, nicht nur von der Benutzeroberfläche:
+
+- Die operativen Daten einer Organisation (Benutzer, Schlüssel, Dashboards, gespeicherte Abfragen) sind auf diese Organisation beschränkt, und organisationsübergreifende Lesezugriffe werden von der Datenbank selbst blockiert.
+- Jedes aufgenommene Event wird mit der zugehörigen Organisation gestempelt, sodass die Events einer Organisation niemals von einer anderen gelesen werden können.
+
+Jede Dashboard-Route ist unter einem Org-Slug (`/<org-slug>/…`) eingeschränkt.
+
+---
+
+## Anmeldung
+
+Failproof AI Observability verwendet passwortlose, E-Mail-basierte Anmeldung. Es gibt kein Passwort, das abgephisht oder geleakt werden könnte. Ein Benutzer fordert einen Einmalcode (oder einen Magic Link zum einmaligen Klicken) an, der per E-Mail zugestellt wird und schnell abläuft. Die Anmeldung ist durch eine **Allowlist** gesichert: Nur E-Mail-Adressen (oder Domains), die Sie freigeben, können sich authentifizieren.
+
+![Der Anmeldebildschirm von Failproof AI Observability, der einen Einmalcode an Ihre E-Mail-Adresse sendet](/agenteye/images/login.png)
+
+---
+
+## Eingeschränkter Zugriff mit API-Schlüsseln
+
+Jeder Client authentifiziert sich mit einem API-Schlüssel, der granulare, minimal privilegierte Berechtigungen trägt. Ein Collector benötigt lediglich `events:add`; ein Dashboard- oder Assistenten-Schlüssel kann schreibgeschützt sein; destruktive Aktionen (Löschen, Neugenerieren) sind separate Berechtigungen, die Sie gezielt vergeben.
+
+![Die API-Schlüssel-Seite: Berechtigungen jedes Schlüssels, farblich nach Lese-, Schreib- und destruktivem Umfang kodiert](/agenteye/images/api-keys.png)
+
+Behalten Sie den Admin-Bootstrap-Schlüssel für die Einrichtung, und vergeben Sie eingeschränkte Schlüssel für alles andere. Siehe [API-Schlüssel](/de/agenteye/api-keys).
+
+---
+
+## Ein schreibgeschützter, genehmigungspflichtiger Assistent
+
+Der [KI-Assistent](/de/agenteye/assistant) im Dashboard beantwortet Fragen über Ihre Daten, ist aber bewusst eingeschränkt:
+
+- Er ist **standardmäßig schreibgeschützt**: Sein SQL wird durch einen Guard geleitet, der nur `SELECT`/`WITH`-Abfragen, einzelne Anweisungen und eine Zeilenbegrenzung erlaubt.
+- Alles, was er erstellt (eine gespeicherte Abfrage, ein Dashboard), ist **genehmigungspflichtig**: Sie prüfen und genehmigen jeden Schreibvorgang, bevor er ausgeführt wird.
+- Er **kann niemals löschen**.
+
+So kann ein Teammitglied fragen „Welche Agents haben diese Woche am häufigsten Fehler gemeldet?" und auf die Antwort reagieren – ohne dass der Assistent Ihre Daten eigenständig ändern oder entfernen kann.
+
+---
+
+## Daten in Übertragung
+
+Der gesamte Datenverkehr läuft über HTTPS. Sie terminieren TLS mit Ihren eigenen Zertifikaten, sodass der Datenverkehr zwischen Collector und Server sowie zwischen Browser und Server verschlüsselt übertragen wird.
+
+---
+
+## Nächste Schritte
+
+- [Übersicht](/de/agenteye/overview): Wie Failproof AI Observability zusammenarbeitet.
+- [API-Schlüssel](/de/agenteye/api-keys): Zugriff für Collector, Dashboard und Assistent einschränken.
+- [Observability](/de/agenteye/observability): Was Failproof AI Observability von Ihren Agents erfasst.

package/.next/standalone/docs-old/de/agenteye/sessions.mdx

@@ -0,0 +1,57 @@
+---
+title: "Sessions & Ausführungsgraph"
+description: "Alle Ereignisse eines Runs in einer übersichtlichen Zeile zusammengefasst und als Git-ähnlicher Ausführungsgraph dargestellt, den du in Sekunden erfassen kannst."
+---
+
+
+Schluss mit dem Rätseln, warum ein Run fehlgeschlagen ist. Failproof AI Observability fasst alle Ereignisse eines Runs in einer lesbaren Zeile zusammen und zeichnet den gesamten Run als Git-ähnliches Diagramm, das du in Sekunden erfassen kannst – so siehst du genau, was dein Agent Schritt für Schritt getan hat.
+
+![Die Sessions-Liste: eine Zeile pro Run, über Umgebungen und Agents hinweg, mit Status-Pills und Bewertungsbadges](/agenteye/images/sessions-list.png)
+
+*Eine Zeile pro Run: der Status-Pill zeigt auf einen Blick, wie der Run geendet hat, und ein Score-Badge erscheint, sobald ein Evaluator verbunden ist.*
+
+<div style={{ position: "relative", width: "100%", paddingBottom: "56.25%", height: 0, overflow: "hidden", borderRadius: "12px", margin: "1.5rem 0" }}>
+  <iframe src="https://www.youtube.com/embed/VWxukZc5k7s?autoplay=1&mute=1&loop=1&playlist=VWxukZc5k7s&rel=0&playsinline=1" title="Watch: Agent Tracing by Failproof AI (2 min)" allow="autoplay; encrypted-media; picture-in-picture; fullscreen" allowFullScreen style={{ position: "absolute", top: 0, left: 0, width: "100%", height: "100%", border: 0 }}></iframe>
+</div>
+
+*Agent-Tracing: einem einzelnen Run Schritt für Schritt folgen, vom Ziel über die Tools bis zur finalen Antwort.*
+
+---
+
+## Alle Runs auf einen Blick
+
+Der rohe Ereignisverlauf ist die Wahrheit hinter jedem Schritt – aber wenn du Tausende von Schritten über Dutzende von Runs hinweg hast, brauchst du den Run, nicht den einzelnen Schritt. Die Sessions-Seite fasst alle Ereignisse eines Runs in einer Zeile zusammen, sodass ein ganzer Tag an Aktivität zu einer übersichtlichen Liste wird, anstatt einem Datenstrom, der kaum zu verfolgen ist.
+
+Jede Zeile trägt einen Status-Pill, sodass ein fehlgeschlagener Run sofort ins Auge fällt, bevor du überhaupt klickst. Filtere nach Datumsbereich, Umgebung, Agent oder Session, um mit wenigen Klicks von „alles" zu „genau der Run, der mich interessiert" zu gelangen.
+
+Sobald du einen Evaluator verbindest, wird jeder abgeschlossene Run automatisch bewertet und sein aktueller Score erscheint als Badge in der Zeile. Du kannst nach jedem Score-Bereich filtern – „zeig mir alle niedrig bewerteten Prod-Runs dieser Woche" ist ein Filter, kein manueller Review-Prozess. Solange du noch keinen Evaluator eingerichtet hast, erfassen Sessions trotzdem den vollständigen Run, sie tragen nur noch keinen Score.
+
+---
+
+## Den gesamten Run als Diagramm lesen
+
+![Der Git-ähnliche Ausführungsgraph einer Session neben ihrer Ereigniszeitleiste, mit dem Panel für Tool-, Modell- und Hook-Aufschlüsselung](/agenteye/images/session-detail.png)
+
+*Der Ausführungsgraph (links) liegt neben der Ereigniszeitleiste; die rechte Leiste schlüsselt Tools, Modelle, Hooks und Token-Verbrauch des Runs auf.*
+
+Klicke auf eine beliebige Session, um ihren Ausführungsgraph zu öffnen: eine Git-ähnliche Ansicht, die zeigt, wie Agents, Tools, Hooks und Modellaufrufe sich im Zeitverlauf entfaltet haben. Parallele Sub-Agents verzweigen sich jeweils auf ihre eigene Spur, sodass du siehst, welche Arbeit parallel lief, welcher Sub-Agent ins Stocken geraten ist und wo der Run vom Kurs abgekommen ist – ohne ihn gedanklich aus einem Wust von Logs rekonstruieren zu müssen.
+
+Die rechte Leiste liefert dir die Run-spezifische Aufschlüsselung: welche Tools und Modelle liefen, welche Hooks gefeuert haben und was der Run an Tokens gekostet hat. Das ist die Antwort auf „Warum hat dieser Run so viel gekostet?" oder „Welches Tool ist das langsame?" – direkt neben dem Graphen, der dazu geführt hat.
+
+Einzelne Ereignisse sind adressierbar, sodass du jemandem einen Link zu einem bestimmten Moment schicken kannst, anstatt „die Session, ungefähr zwei Drittel runter". Kopiere den Link aus einem beliebigen Ereignis, oder folge einem Link aus einem [Audit](/de/agenteye/audits)-Fund oder einem Fehler – die Session öffnet sich dann mit dem ausgewählten und angezeigten Ereignis. Das gilt auch für sehr lange Runs: Die Zeitleiste lädt aus Rücksicht auf deinen Browser ein begrenztes Fenster, und ein Link, der über dieses Fenster hinausweist, findet sein Ereignis trotzdem, anstatt dich am Anfang abzusetzen. Wenn das Ereignis aus deinem Aufbewahrungsfenster herausgefallen ist, teilt dir die Seite das mit, anstatt stillschweigend nichts auszuwählen.
+
+---
+
+## Wo du es findest
+
+Jede Dashboard-Seite ist auf deine Org beschränkt (`/<org-slug>/…`). Sessions findest du unter **Observe** in der linken Seitenleiste, neben Events, mit den Filtern für Datumsbereich, Umgebung, Agent und Session am oberen Rand der Liste. Jede Zeile ist einen Klick von ihrem vollständigen Ausführungsgraph entfernt.
+
+Um die Score-Badges und die Score-Bereich-Filterung zu aktivieren, verbinde einen Evaluator: siehe [Evaluations](/de/agenteye/evaluations).
+
+---
+
+## Verwandte Themen
+
+- [Event stream](/de/agenteye/event-stream): der rohe, schrittweise Verlauf, aus dem jede Session zusammengesetzt wird.
+- [Evaluations](/de/agenteye/evaluations): verbinde einen Evaluator, damit jeder Run einen Score-Badge erhält, nach dem du filtern kannst.
+- [Telemetry](/de/agenteye/telemetry): wie Runs von deinem Agent in diese Sessions gelangen.