# Übergabe von AI-Agents: Aktive Sitzungen über Nacht kontrollieren Eine Übergabe eines AI-Agents scheitert, wenn der abgehende Engineer eine Geschichte statt der Zuständigkeit weitergibt. «Der Agent arbeitet noch am Deployment» sagt der nächsten Person fast nichts. Sie muss wissen, welcher Prozess noch über Berechtigungen verfügt, worauf er zugreifen kann, welche Anfrage auf einen Menschen wartet, wo die Belege liegen und wie sich die Arbeit stoppen oder wiederherstellen lässt. Der schwierige Teil: Ein Agent kann handeln, während niemand das Terminal beobachtet. Er kann eine aktive SSH-Verbindung, eine dauerhafte Hintergrundaufgabe, ein Token in seiner Umgebung, eine auf einem Laptop wartende Genehmigungsabfrage oder eine teilweise entfernte Änderung haben, die erst später sichtbar wird. Eine gute Übergabe macht daraus einen klar begrenzten Betriebszustand. Eine schlechte überträgt Unsicherheit und nennt das Kontinuität. ## Eine Übergabe braucht einen Zuständigkeitsdatensatz, keine Chat-Zusammenfassung Eine brauchbare Übergabe dokumentiert Zuständigkeit und Zustand getrennt, weil beide auf unterschiedliche Weise scheitern. Der Zustand zeigt dem übernehmenden Engineer, was der Agent getan hat und tun will. Die Zuständigkeit zeigt, was der Agent noch tun kann. Teams dokumentieren oft den ersten Punkt und lassen den zweiten aus. So wird aus einer harmlos wirkenden Fortsetzung ein ungeprüfter Schreibzugriff auf die Produktion. Erstelle den Datensatz, solange der abgehende Engineer die Maschine noch prüfen und Entscheidungen erklären kann. Rekonstruiere ihn nicht erst aus dem Gedächtnis, nachdem ein Alarm jemanden geweckt hat. Ein kurzes Dokument mit exakten Kennungen ist besser als eine lange, von Zuversicht geprägte Erzählung. Halte für jeden aktiven Lauf folgende Fakten fest: - Prozess-ID des Agents, Sitzungs-ID, Arbeitsverzeichnis und Startzeit. - Abgehender menschlicher Besitzer der Schicht, übernehmender Besitzer und Zeitpunkt des Zuständigkeitswechsels. - Vorgesehene Aufgabe, letzte abgeschlossene externe Aktion und nächste vorgeschlagene externe Aktion. - Jedes erreichbare Ziel, etwa Host-Alias, API-Basis-URL, Repository, Ticket oder Deployment-Umgebung. - Stop-Befehl, Wiederherstellungsbefehl und Ort der Belege. Schreibe nicht «hat Zugriff auf Staging», wenn du schreiben kannst: «Prozess 4182 kann über die genehmigte Sitzung S-204 die Staging-Deployment-API aufrufen.» Allgemeine Bezeichnungen verbergen die Details, die entscheiden, ob ein Nachfolger sicher fortfahren kann. Der Zuständigkeitsdatensatz braucht außerdem für jeden Lauf eine eindeutige Entscheidung: fortsetzen, pausieren, abbrechen oder vor jeder Aktion prüfen. «Überwachen» ist keine Entscheidung. Der nächste Engineer müsste sonst selbst ableiten, ob er eingreifen darf. Eine Übergabe ist erst abgeschlossen, wenn der eingehende Engineer den Datensatz bestätigt und den laufenden Prozess selbst findet. Eine Nachricht in einem vollen Kanal ist Zustellung, keine Übertragung. Wenn niemand die Zuständigkeit übernimmt, sollte der abgehende Engineer die externe Berechtigung pausieren oder widerrufen, soweit die Arbeit das zulässt. ## Finde aktive Berechtigungen, bevor du Besitzer wechselst Du kannst die Kontrolle über eine Sitzung nicht übertragen, die du nicht gefunden hast. Beginne mit dem lokalen Prozessbaum und prüfe anschließend Verbindungen, Umgebungsvariablen und Jobs, die außerhalb des unmittelbaren Terminals erstellt wurden. Die Agent-Oberfläche kann eine Aufgabe als abgeschlossen anzeigen, während ein Kindprozess, ein Fenster in einem Terminal-Multiplexer oder eine SSH-Master-Verbindung noch aktiv ist. Beginne unter macOS oder Linux mit einfachen Befehlen und speichere ihre Ausgabe als Teil der Übergabebelege. Ersetze die Beispielkennungen durch den tatsächlichen Agent-Prozess oder das tatsächliche Konto. ```sh ps -axo pid,ppid,user,lstart,command | grep -E '[a]gent|[c]laude|[m]cp' pgrep -P 4182 -alf lsof -nP -p 4182 ``` Der erste Befehl liefert eine Prozesszeile wie diese: ```text 4182 901 alex Tue Mar 18 22:14:07 2025 agent-runner --task deploy-api ``` Der zweite zeigt Kindprozesse. Der dritte listet offene Dateien und Netzwerkendpunkte auf. Suche nach geerbten Shells, offenen Unix-Sockets, TCP-Verbindungen, lokalen Zugangsdaten-Dateien und Pipes zu Genehmigungshelfern. Füge keine Befehlsausgabe mit Geheimnissen in ein Ticket ein. Bewahre sie im genehmigten Incident-Datensatz auf oder schwärze den sensiblen Wert, während du Dateipfad und Verbindungsdetails beibehältst. SSH muss separat geprüft werden, weil seine Verbindungsstruktur über einen einzelnen Befehl hinaus bestehen kann. Das Handbuch zu OpenSSH `ssh_config` sagt, dass `ControlPersist` eine Master-Verbindung offen halten kann, nachdem der ursprüngliche Client beendet wurde. Das spart bei wiederholten Befehlen Zeit. Bei einer Übergabe bedeutet es aber auch: «Der Befehl ist beendet» beweist nicht, dass der entfernte Zugriff beendet ist. Prüfe Master-Sockets und Weiterleitungsprozesse: ```sh ps -axo pid,ppid,command | grep '[s]sh' find ~/.ssh -type s -name '*control*' -print lsof -nP -iTCP -sTCP:ESTABLISHED | grep '[s]sh' ``` Stelle danach eine wichtigere Frage als «Ist die Verbindung aktiv?»: Was kann die entfernte Seite noch ausführen? Ein entfernter Build kann weiterlaufen, nachdem der lokale Client verschwunden ist. Ein Deployment-Befehl kann eine Änderung angewendet haben und vor der Meldung der nächsten Änderung fehlgeschlagen sein. Erfasse die Kennung des entfernten Jobs, den Deployment-Datensatz oder den Dienststatus, bevor du entscheidest, ob du fortsetzt. Setze einen offenen Port nicht mit böswilliger Aktivität gleich. Behandle aber jeden unerklärten offenen Kanal als ungeklärte Berechtigung. Der eingehende Engineer muss ihn verstehen, schließen oder eskalieren. ## Offene Genehmigungen brauchen eine Entscheidung und ein Ablaufdatum Eine offene Genehmigung ist eine vorgeschlagene Aktion, keine Reservierung des abgehenden Engineers. Die übernehmende Person sollte niemals eine Genehmigungsabfrage mit einer Nachricht erben, die nur sagt: «Klicke hier, wenn sie erscheint.» Damit soll sie eine Entscheidung ohne Kontext absegnen. Füge jeder offenen Anfrage fünf Angaben hinzu: 1. Die genaue Aktion einschließlich Methode und Ziel. «Dienst aktualisieren» reicht nicht. «POST an den Deployment-Endpunkt für production-api» gibt einen konkreten Ausgangspunkt. 2. Der Grund für die Aktion und die Bedingung, die sie erforderlich gemacht hat. 3. Das erwartete Ergebnis und der sichtbare Beleg, der es bestätigt. 4. Die Frist, nach der die Anfrage ablaufen und neu erstellt werden muss. 5. Die namentlich genannte Person, die sie genehmigen oder ablehnen darf. Eine Genehmigung ohne diese Angaben sollte ablaufen. Eine Anfrage neu zu stellen ist günstiger, als einen blinden Schreibzugriff wiederherzustellen. Während einer ruhigen Schicht wirkt diese Regel vielleicht übertrieben. Sie wirkt selbstverständlich, nachdem eine Genehmigung eine Laptop-Sperre, eine erneute Verbindung und eine Änderung des Incident-Umfangs überlebt hat. Nutze eine Übergabe nicht, um den Genehmigungsumfang zu erweitern. Wenn der abgehende Engineer eine Änderung in Staging genehmigen durfte, ist der eingehende Engineer dadurch nicht berechtigt, die Produktionsversion derselben Änderung zu genehmigen. Während die Anfrage wartete, kann sich der Umfang geändert haben. Prüfe Ziel, Payload und aktuellen Incident-Zustand erneut, bevor ein Mensch handelt. Auch der Zeitpunkt spielt eine Rolle. Wenn ein Tool lange nach der Erstellung einer Anfrage durch den Agent zu einer Aktion auffordern kann, muss ein Ablaufdatum Teil des Anfragedesigns sein. Eine veraltete Genehmigung kann auf ein System angewendet werden, das sich erholt, einen Failover durchgeführt oder manuell geändert wurde. Der Prompt kann einen technisch gültigen Vorgang beschreiben, der operativ nicht mehr die richtige Entscheidung ist. Ich bevorzuge eine kurze Genehmigungsnotiz gegenüber einem umfangreichen Transkript. Der nächste Engineer sollte innerhalb einer Minute drei Fragen beantworten können: Was passiert? Wo passiert es? Warum muss es gerade jetzt noch passieren? Wenn das nicht möglich ist, lehne die Anfrage ab und bitte den Agent, den aktuellen Zustand zu prüfen, bevor er eine neue Aktion vorschlägt. ## Sitzungsbesitz und Besitz von Geheimnissen müssen getrennt bleiben Wer eine Sitzung überwacht, braucht keine Kopie jeder Zugangsdaten, die diese Sitzung verwenden kann. Die Verwechslung dieser Rollen führt zu einem bekannten und teuren Problem: Jemand exportiert «nur für die Übergabe» ein Token in das Shell-Profil. Danach überlebt das Token den Incident, die Rolle des Engineers und die Erinnerung daran, warum es existierte. Eine ordnungsgemäße Übertragung ändert, wer eine Aktion überwachen, genehmigen, pausieren oder widerrufen darf. Sie liefert keine API-Tokens, privaten SSH-Schlüssel, Browser-Cookies oder temporären Cloud-Zugangsdaten über Chat, Notizen oder einen Agent-Prompt. Der Nachfolger erhält die Sitzungsreferenz und die für den Betrieb erforderlichen Belege. Der ausführende Prozess behält das Geheimnis. Diese Unterscheidung ist besonders wichtig, wenn der abgehende Engineer ein Terminal offen lässt. Eine entsperrte Shell ist kein legitimer Übertragungsweg. Sie gibt der nächsten Person einen Stapel geerbter Zustände: exportierte Variablen, Befehlsverlauf, zwischengespeicherte Zugangsdaten, Shell-Funktionen, Port-Weiterleitungen und halb fertige Befehle. Ein Teil davon kann nützlich sein. Nichts davon schafft eine klare Zuständigkeit. Nutze einen von zwei Ansätzen: - Setze die bestehende Sitzung nur fort, wenn die aktive Aktion verstanden ist, ihr Umfang begrenzt ist, der eingehende Engineer sie übernommen hat und ein Stoppen ein schlechteres operatives Ergebnis verursachen würde. - Stoppe die alte Sitzung und starte unter dem eingehenden Engineer eine neue, wenn die Aufgabe untersuchend ist, die Berechtigungen weit reichen, der Prompt-Verlauf wichtig ist oder der Agent untätig geworden ist. Der zweite Ansatz ist meist sicherer, als Teams zugeben. Viele scheuen ihn, weil sie den Kontextverlust fürchten. Bewahre den Kontext im Übergabepaket auf, nicht in einem ungeprüften Prozess. Ein neuer Prozess hat eine klare Genehmigungsgrenze und macht die Verantwortung des neuen Besitzers eindeutig. Bei Teams, die Sallyport verwenden, kann der Agent HTTP- und SSH-Aktionen ausführen, ohne die zugrunde liegenden Geheimnisse zu erhalten. Ein Schichtwechsel kann damit die Überwachung statt des Credential-Materials übertragen. Die Tresorsperre verweigert Aktionen, solange der Tresor gesperrt ist, und schafft für den eingehenden Engineer eine bewusste Pause, bevor er eine Fortsetzung autorisiert. Verwechsle die Trennung nicht mit Immunität. Wenn ein Nachfolger Aktionen in einer Sitzung genehmigen kann, braucht er weiterhin dieselbe Disziplin bei Umfang und Belegen. Ein Geheimnis aus einem Prompt herauszuhalten verhindert eine Fehlerklasse. Eine unsichere Anfrage wird dadurch nicht sicher. ## Wiederherstellung beginnt mit Eindämmung, nicht mit Fortsetzung Wenn ein Agent-Lauf verstummt oder der abgehende Engineer nicht erreichbar ist, sollte der eingehende Engineer zuerst neue externe Änderungen verhindern. Er sollte nicht zehn Minuten damit verbringen, den exakten Gesprächskontext wiederherzustellen, während ein Hintergrundprozess weiter schreibt. Die Wiederherstellung hat zwei Spuren: Belege bewahren und den aktuellen Zustand feststellen. Führe sie in dieser Reihenfolge aus, sobald die Möglichkeit besteht, dass Prozess oder Host verschwinden. Kopiere Sitzungskennungen, Terminalausgabe, Aufgabendefinitionen, Genehmigungen, Prozesslisten und Audit-Referenzen in den Incident-Datensatz. Stoppe, widerrufe oder sperre anschließend den Aktionspfad gemäß den normalen Kontrollen des Systems. Prüfe nach der Eindämmung das Zielsystem. Die Behauptung des Agents, ein Aufruf sei fehlgeschlagen, ist schwächer als ein Datensatz auf der Zielseite. Ein HTTP-Timeout kann bedeuten, dass der Server eine Anfrage abgewiesen, einmal angenommen oder angenommen und die Antwort verloren hat. Ohne Idempotenzmechanismus kann ein erneuter Versuch die Aktion duplizieren. Nutze die naheliegenden Belege des Ziels: - Bei einem API-Schreibzugriff prüfst du Objekt, Änderungsdatensatz, Request-ID oder Idempotenzdatensatz. - Bei SSH-Arbeiten prüfst du entfernten Prozess, Dienststatus, Paketmanager-Verlauf oder Deployment-Markierung. - Bei einer Codeänderung prüfst du Repository-Diff, Commit, CI-Lauf und Deployment-Status getrennt voneinander. - Bei einer eingereihten Aktion prüfst du Warteschlange und Worker-Status, bevor du einen weiteren Job sendest. Der Unterschied zwischen dem erneuten Senden einer Anfrage und der Wiederherstellung eines Vorgangs ist wichtig. Ein erneuter Versuch wiederholt den Transportversuch. Eine Wiederherstellung stellt fest, ob sich der zugrunde liegende Zustand geändert hat, und wählt danach die nächste Aktion. Teams vermischen diese Begriffe, wenn ein Agent ein Timeout als Einladung präsentiert, auf «erneut ausführen» zu klicken. Das ist es nicht. Eine Wiederherstellungsnotiz sollte die letzte vertrauenswürdige Beobachtung nennen, nicht das Letzte, was der Agent gesagt hat. Zum Beispiel: «Der Agent lief nach der Anforderung des Deployments D42 in einen Timeout. Der Deployment-Dienst führt D42 auf zwei Instanzen als laufend. Neue Einreichungen wurden um 02:17 pausiert.» Damit erhält der nächste Operator einen sachlichen Ausgangspunkt. Wenn du den Zustand nicht feststellen kannst, eskaliere den Incident und halte die Berechtigungen eingeschränkt. Ein angehaltenes Deployment ist oft tolerierbar. Eine doppelte Schema-Migration, eine wiederholte Zahlungsaktion oder eine versehentliche Löschung in der Produktion möglicherweise nicht. ## Prüfe den Datensatz anhand der Belege, bevor du ihn annimmst Ein Übergabedokument ist die Interpretation eines Operators. Ein Audit-Datensatz ist ein Beleg dafür, was das System aufgezeichnet hat. Du brauchst beides, darfst sie aber nicht gleichsetzen. Bevor ein eingehender Engineer eine aktive Sitzung übernimmt, vergleiche den Zuständigkeitsdatensatz mit Belegen, die der abgehende Engineer nicht von Hand bearbeiten konnte. Prüfe Start- und Endzeiten der Sitzung, Zielnamen, Aktionsfolge und die angegebene Genehmigungsentscheidung. Untersuche Abweichungen, bevor jemand den Lauf fortsetzt. Eine Hashkette hilft dabei, weil sie das Erkennen von Entfernen und Umordnen von Datensätzen ermöglicht. Sie beweist weder Absicht noch Korrektheit noch die Sinnhaftigkeit einer Genehmigung. Diese Grenze sollte klar ausgesprochen werden. Kryptografische Kontinuität beantwortet die Frage: «Ist diese aufgezeichnete Sequenz intakt geblieben?» Sie beantwortet nicht: «Hätten wir diese Anfrage senden sollen?» Mit Sallyport können Teams die verschlüsselte Audit-Kette offline mit diesem Befehl prüfen: ```sh sp audit verify ``` Speichere das Ergebnis des Prüfers neben dem Übergabedatensatz, zusammen mit dem Zeitpunkt der Prüfung und dem geprüften Log-Bereich. Die Prüfung benötigt keinen Zugriff auf den Tresor. Das ist hilfreich, wenn ein eingehender Engineer die Kontinuität prüfen muss, bevor er eine Aktionsberechtigung freigibt. Mache es nicht zur Gewohnheit, große Audit-Auszüge in den Chat zu kopieren. Logs enthalten oft sensible operative Metadaten, auch wenn sie keine Geheimnisse enthalten. Speichere eine Referenz auf den genehmigten Datensatz, zitiere nur den kleinen Abschnitt, der die Übergabe erklärt, und verschaffe dem eingehenden Engineer über den normalen Incident-Weg Zugriff. Eine Audit-Prüfung entdeckt auch ein alltägliches, aber ernstes Problem: Ein Engineer kann zwei Agents mit ähnlichen Aufgaben gestartet und einen davon vergessen haben. Eine Prozessliste zeigt, was jetzt läuft. Die Audit-Sequenz zeigt, was jeder Lauf bereits versucht hat. Lies beides, bevor du die Verantwortung übernimmst. ## Ein Übergabepaket sollte funktionieren, wenn sich niemand an den Incident erinnert Ein brauchbares Paket ermöglicht es einem Engineer, der vor fünf Minuten noch geschlafen hat, eine sichere Entscheidung zu treffen. Es sollte nicht erfordern, Hunderte von Chatnachrichten zu durchsuchen oder ein unbegrenztes Prompt-Transkript erneut zu öffnen. Bewahre das Paket beim Incident-Datensatz auf, verwende jedes Mal dieselbe Reihenfolge der Felder und aktualisiere es, wenn sich Berechtigungen ändern. Nutze diese Vorlage als Ausgangspunkt: ```text Incident oder Änderung: Abgehender Besitzer / eingehender Besitzer / Zeitpunkt der Übergabe: Agent-Lauf: - Sitzungs-ID und lokale PID: - Arbeitsbereich und Aufgabenreferenz: - Aktueller Zustand: fortsetzen | pausieren | abbrechen | prüfen - Letzte bestätigte externe Aktion: - Nächste vorgeschlagene Aktion: Berechtigungen: - Für diesen Lauf erreichbare Ziele: - Genehmigungsstatus und Ablaufzeit: - Methode zum Widerrufen oder Stoppen der Sitzung: - Zugangsdaten bleiben im Besitz von: Belege: - Referenz auf Aktivitäts- oder Audit-Datensatz: - Geprüfte Belege auf der Zielseite: - Erfassung von Prozessen und Verbindungen: Wiederherstellung: - Bekannter Teilzustand: - Sichere erste Aktion für den eingehenden Besitzer: - Eskalationsverantwortlicher und Auslöser: ``` Die Zeile «Sichere erste Aktion» verdient ihren Platz. Formuliere eine Aktion, die den Zustand erfasst, ohne die Auswirkungen zu vergrößern, etwa das Prüfen eines Deployment-Datensatzes, das Lesen der Warteschlangentiefe oder den Vergleich einer Dienstversion. Schreibe nicht «Untersuchung fortsetzen». Diese Formulierung hat keine operative Grenze. Das Paket sollte außerdem nennen, was sich seit dem Start des Agents geändert hat. Vielleicht wurde ein Release-Freeze begonnen, eine Datenbankreplik hat Verzögerung, ein Kunde hat ein Symptom gemeldet oder ein anderer Engineer hat eine manuelle Korrektur vorgenommen. Agents handeln auf Basis des Kontexts, den sie erhalten. Der eingehende Mensch braucht auch den Kontext, der nach Beginn des Prompts hinzugekommen ist. Halte die Sprache sachlich. «Der Agent wirkt verwirrt» fordert den Nachfolger auf, ihm zu misstrauen, bietet aber nichts zur Prüfung. «Der Agent hat denselben POST vorgeschlagen, nachdem der Dienst die Request-ID 7f3 als angenommen meldete» beschreibt ein Risiko für eine doppelte Aktion und weist auf die richtige nächste Prüfung hin. ## Schichtwechsel erzeugen eine Berechtigungslücke, wenn du den Zeitpunkt ignorierst Die Lücke entsteht, wenn der abgehende Engineer gedanklich bereits Feierabend hat, seine Sitzung aber noch handeln kann. Sie wird größer, wenn der eingehende Engineer die Zuständigkeit noch nicht angenommen hat, den Genehmigungsstatus nicht sehen kann oder annimmt, der Agent lese lediglich Daten. Während dieser Lücke verfügt der Prozess über Berechtigungen, ohne dass ein aufmerksamer Mensch für ihre Nutzung verantwortlich ist. Ein typischer Fehler sieht so aus: Am Ende einer Schicht bittet ein Engineer einen Agent, ein fehlerhaftes Deployment zu reparieren. Der Agent öffnet eine SSH-Verbindung, bearbeitet eine Konfigurationsdatei und wartet auf die Genehmigung, einen Dienst neu zu starten. Der Engineer schreibt im Chat «Neustart ausstehend, sollte passen» und meldet sich ab. Der nächste Engineer sieht den Prompt eine Stunde später. In dieser Stunde hat eine manuelle Gegenmaßnahme die Diensttopologie geändert. Der ausstehende Neustart betrifft nun einen Knoten, der Datenverkehr trägt, von dem der vorherige Engineer nichts wusste. Die Genehmigung beschreibt weiterhin einen gültigen Befehl, aber die Situation, die ihn gerechtfertigt hat, ist eine andere. Für diesen Fehler braucht es weder ein kompromittiertes Tool noch eine nachlässige Person. Er entsteht, weil Berechtigung als dauerhaft behandelt wird, während sich der operative Kontext bewegt. Eine Genehmigung sollte an eine kurzlebige Anfrage und einen aktuellen Besitzer gebunden sein. Eine Sitzung sollte ihre Berechtigungen verlieren, wenn keine dieser beiden Bedingungen erfüllt ist. Lege eine eindeutige Frist für die Übergabe fest. Wenn der eingehende Engineer die Sitzung bis dahin nicht angenommen hat, pausiere den Agent und mache offene Genehmigungen ungültig. Wenn eine Aufgabe nicht sicher pausieren kann, halte das vor dem Incident im Runbook fest, definiere, wer sie annehmen darf, und richte einen direkten Eskalationsweg ein. Entdecke diese Ausnahme nicht erst beim Schichtwechsel. Teams lassen Sitzungen manchmal immer aktiv, weil der Neustart von Agents Zeit kostet. Diese Empfehlung ist beliebt, weil sie lokalen Kontext bewahrt und eine erneute Erklärung der Aufgabe vermeidet. Für weitreichende oder unklare Berechtigungen ist sie falsch. Die wenigen Minuten für den Start einer sauberen Sitzung sind günstig im Vergleich zu dem Versuch, zu erklären, warum ein verwaister Prozess ein System geändert hat, nachdem sein Besitzer offline gegangen war. ## Der eingehende Engineer sollte die Verantwortung in einer festen Reihenfolge übernehmen Der eingehende Engineer braucht eine wiederholbare Annahmesequenz, weil Übergaben stattfinden, wenn die Aufmerksamkeit geteilt ist. Das ist keine Bürokratie für ruhige Tage. Sie verhindert, dass eine Person, die von einem Alarm geweckt wurde, eine Aktion genehmigt, bevor sie weiß, welche Berechtigungen noch aktiv sind. Nutze diese Reihenfolge: 1. Lies den aktuellen Incident-Zustand und den Zuständigkeitsdatensatz, und bestätige dann den abgehenden Engineer und den Zeitpunkt der Übergabe. 2. Finde den genannten Prozess oder die Sitzung und prüfe aktive Verbindungen, Kindprozesse und offene Anfragen. 3. Vergleiche den Datensatz mit Audit-Belegen und dem Zustand auf der Zielseite. 4. Entscheide dich für Fortsetzen, Pausieren oder Abbrechen. Lehne jede offene Genehmigung ab, für die es keine klare und aktuelle Begründung mehr gibt. 5. Dokumentiere die Übernahme, die erste sichere Aktion und den Zeitpunkt der nächsten Prüfung. Die Reihenfolge ist wichtig. Wenn du zuerst genehmigst und später prüfst, hast du das größte Risiko bereits akzeptiert. Wenn du das Ziel prüfst, bevor du den Sitzungsdatensatz sicherst, können Belege verloren gehen, sobald ein Prozess endet oder eine Maschine neu startet. Eine feste Abfolge schützt vor dem natürlichen Impuls, «es einfach wieder zum Laufen zu bringen». Auch der abgehende Engineer hat eine feste Pflicht: verfügbar zu bleiben, bis der Nachfolger die Zuständigkeit übernimmt oder die Sitzung beendet wird. Endet die Abdeckung vorher, muss er eskalieren, statt still einen laufenden Agent zurückzulassen. Ein Bereitschaftsplan weist eine Person zu, keine vage Hoffnung, dass jemand einen Prompt bemerkt. Verankere diese Regeln in deiner Incident-Praxis, bevor ein nächtlicher Ausfall dich dazu zwingt. Beginne damit, die Zuständigkeitsfelder in eine bestehende Übergabenotiz aufzunehmen und für jeden Agent-Lauf eine Entscheidung zu verlangen. Wenn du zum ersten Mal eine unerklärte SSH-Verbindung oder eine Genehmigung ohne Besitzer findest, hast du eine reale Lücke entdeckt und keine theoretische.