Ich setze meine Firma auf proaktive Agenten

Agenten können fast alles tun, worum du sie bittest, und genau das ist das Problem: Du musst immer noch bitten.

Ich höre immer wieder, wie Leute Agenten „digitale Kollegen“ nennen. Dieses Bild ist falsch. Ein Kollege, der schweigend dasitzt, bis du ihm eine perfekt zugeschnittene Aufgabe gibst, sie erledigt und dann wieder wartet, ist kein Kollege. Jeder Agent, den du je benutzt hast, funktioniert genau so. Die Modelle wurden schlauer, die Harnesses besser, die Runs länger, aber die Schnittstelle hat sich nie geändert: Du bringst die Arbeit, der Agent bringt die Ausführung.

Und die meisten haben es nicht bemerkt, weil das Prompt-Feld in unseren Köpfen leise zu dem geworden ist, was KI ist.

Ask anything about your stack...

Jede Schnittstelle ist immer noch ein Prompt-Feld

Mit dem Eingabefeld hat diese ganze Ära angefangen. ChatGPT hat eines auf ein Modell gesetzt und wurde zum am schnellsten wachsenden Produkt der Geschichte, und wir haben es alle kopiert. Jedes KI-Produkt seitdem ist eine Variation derselben Interaktion: Mensch tippt, Maschine antwortet, Maschine wartet.

Claude Code war die nächste Evolution. Der Agent ist in dein Terminal gezogen, hat deine Dateien, deine Shell und deine Git-Historie in die Hand genommen und angefangen, echte Arbeit zu machen, statt darüber zu reden. Das hat verändert, was Agenten können, aber nicht, wie sie anfangen: Du tippst, er arbeitet, er hält an, und er wartet, bis du wieder tippst.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Dann sind Agenten in die Cloud gezogen. Codex, Devin, Claude Code im Web. Sie laufen Stunden statt Minuten, starten Sub-Agenten, um die Arbeit zu parallelisieren, und sterben nicht, wenn du deinen Laptop zuklappst. Du gibst einem vor dem Mittagessen eine Aufgabe und kommst zu einem Pull Request zurück.

Der Prompt hat sogar aufgehört, eine reine Tastatursache zu sein. Hintergrund-Agenten lassen sich von einem Alert oder einem Webhook anstoßen, und die meisten Agenten-Plattformen bieten inzwischen Automationen: Wenn dieses Event feuert oder dieser Cron tickt, führe einen Agenten mit diesen Anweisungen aus.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Aber was ist eine Automation? Sie ist ein Prompt, den du im Voraus geschrieben hast. Du hast den Fehlermodus vorhergesagt, das Event ausgewählt und aufgeschrieben, was zu tun ist. Der Trigger startet den Agenten, aber das Urteil darin ist deins, eingefroren zum Zeitpunkt der Einrichtung. Eine Automation fängt genau das, was du vorhergesehen hast, und nichts sonst.

Du bist der Scheduler

Zieh das Tooling ab, und die Arbeitsteilung hat sich in drei Jahren nicht bewegt. Der Agent macht die Arbeit. Zu entscheiden, was die Arbeit ist, bleibt dein Job.

Du liest die Dashboards, du hörst den Nutzern zu, du findest heraus, was zählt, und du komprimierst alles, was du gelernt hast, in einen Prompt, entweder live an der Tastatur oder im Voraus in einem Trigger. Der Agent führt brillant aus, aber jedes Stück Urteilsvermögen im System stammt von dir.

Die nächste Evolution: Agenten, die die Arbeit finden

Ich setze darauf, dass die nächste Evolution Agenten sind, die selbst herausfinden, was zu tun ist. Kein Prompt, kein Trigger zum Konfigurieren, keine im Voraus geschriebenen Anweisungen. Du verbindest deinen Stack, und der Agent findet die Arbeit von selbst: Er beobachtet dieselben Signale wie du, bemerkt, was nicht stimmt, entscheidet, ob es zählt, und fängt eigenständig an, daran zu arbeiten.

Das ist leicht gesagt und brutal schwer zu bauen, weil Proaktivität drei Probleme sind, die aufeinander gestapelt sind, und wer eines davon überspringt, bekommt etwas Schlimmeres als den Agenten hinter einem Eingabefeld.

Kontext. Natürlich braucht der Agent ein lebendes Modell der Welt, in der er operiert, keinen Snapshot, den du zur Prompt-Zeit ins Kontextfenster kopiert hast. Ein reaktiver Agent mit schlechtem Kontext gibt dir eine schlechte Antwort. Ein proaktiver Agent mit schlechtem Kontext löscht deine Produktionsdatenbank, weil er dachte, es sei Staging.

Urteilsvermögen. Das hat mir am meisten zu schaffen gemacht. In jedem Moment sind in einem Produktionssystem tausende Dinge ein bisschen daneben. Ein Agent, der alle meldet, ist eine Rauschmaschine, Rauschmaschinen werden stummgeschaltet, und stummgeschaltete Agenten sind tote Agenten. Der gesamte Wert von Proaktivität liegt in der Lücke zwischen „etwas hat sich geändert“ und „etwas zählt“:

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

Handeln. Bemerken ohne zu handeln ist nur ein schlauerer Alert, und Alerts sind genau das, was ich abschaffen will. Der Agent muss den Job zu Ende bringen, innerhalb von Grenzen, die Autonomie sicher machen: umkehrbare Aktionen, Belege für alles und ein hartes Gate, bevor irgendetwas Unumkehrbares passiert.

Keines dieser drei verlangt vom Agenten zu entscheiden, wie gut aussieht. Er entscheidet, was daneben ist, ob es zählt und was dagegen zu tun ist, und das ist die ganze Liste, denn in der Produktion muss niemand gut definieren: Fehler bei null, Latenz auf der Baseline, Queues leer, Zertifikate gültig. Der Sollzustand kommt mit dem Gelände.

Das heißt, die eigentliche Verschiebung ist nicht von „du promptest“ zu „der Agent promptet sich selbst“. Sie ist von imperativem Betrieb zu deklarativem Betrieb. Eine Automation ist imperativ: Du zählst die Fehlermodi im Voraus auf und skriptest eine Reaktion auf jeden. Ein proaktiver Agent ist eine Abgleichschleife: Er hält das System, das du hast, gegen das System, das du haben solltest, und arbeitet daran, die Lücke zu schließen. Kubernetes hat das vor einem Jahrzehnt für Infrastruktur getan, du schreibst drei Replikas auf, und ein Controller tut, was nötig ist, um drei Replikas am Leben zu halten. Niemand hat es für den Betrieb von Software selbst getan. Und hier gibt es nicht einmal YAML zu schreiben, weil der Sollzustand schon bekannt ist. Es funktioniert von Haus aus.

Ich habe mit dem Betrieb angefangen

Bitte einen proaktiven Agenten, deine Produkt-Roadmap zu wählen, und du bekommst einen Praktikanten mit Meinung, weil Produktrichtung Geschmackssache ist. Produktion ist es nicht. Sie ist die eine Domäne, in der alle drei Probleme heute lösbar sind.

Die Arbeit kündigt sich selbst an: Fehlerraten steigen, ein Deploy geht schief, ein Zertifikat läuft ab, eine Queue staut sich. Die Arbeit liegt schon in der Telemetrie und wartet darauf, dass jemand sie bemerkt. Und anders als in geschmacksgetriebenen Domänen gibt es eine Ground Truth: Die Fehlerrate ist entweder hochgeschossen oder nicht, der Rollback hat die Baseline entweder wiederhergestellt oder nicht, also wird das Urteil des Agenten vom System selbst bewertet, laufend, ohne Raum für Bauchgefühl.

Vor allem aber besetzen wir diesen Job schon mit Menschen. Wir nennen es On-Call: eine Person, die neben einem Telefon schläft und darauf wartet, dass eine Maschine sagt, dass eine andere Maschine unglücklich ist. Ich habe Jahre in der Observability verbracht, ein Observability-Unternehmen gegründet, das Cloudflare übernommen hat, und ein ganzes Manifest darüber geschrieben, wie man Telemetrie strukturiert, damit die Antwort eine Query entfernt ist. Seine These ist der Grund, warum es dieses Unternehmen gibt: 2026 sollte niemand mehr On-Call sein.

Denn die unbequeme Wahrheit über das letzte Jahrzehnt Observability ist, dass wir Systeme für Menschen um 3 Uhr nachts leichter befragbar gemacht und dann den Sieg erklärt haben, während immer noch Menschen geweckt wurden. Die Dashboards wurden hübscher, und der Pager blieb auf dem Nachttisch. Observability ohne Handeln ist nur teurer Speicher.

Wie es aussieht

Das ist, was Polylane tut. Hier ist ein konkreter Dienstag:

Niemand hat einen Check für diesen Fehlermodus konfiguriert. Es gibt keine Regeln zu schreiben und keine Schwellenwerte zu tunen: Agenten bewerten jede verbundene Ressource in laufendem Takt, und deine bestehenden Dashboards und gespeicherten Queries werden zu ihrer Checkliste. Beim Urteilsvermögen bin ich am strengsten. Das Standardurteil lautet keine Auffälligkeit, weil es viel besser ist, ein Grenzfall-Issue zu verpassen, als jemanden wegen Rauschen zu wecken. „Ein Deploy könnte einen Bug einführen“ gilt für jeden Deploy und ist nie ein Grund, jemanden zu wecken.

Wenn etwas echt ist, verfolgt die Untersuchung mehrere konkurrierende Hypothesen parallel, und die Aufgabe jedes Agenten ist es, seine Hypothese zu widerlegen statt zu bestätigen, damit Korrelation sich nie als Ursache ausgeben kann. Ist die bestätigte Grundursache eine Codeänderung, kommt der Fix als Pull Request mit der Untersuchung dabei:

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proaktiv heißt nicht unbeaufsichtigt

Die Autonomie liegt im Bemerken, in der Triage, in der Archäologie um 3 Uhr nachts und in der Eindämmung. Alles, was einen bekannt guten Zustand wiederherstellt, macht der Agent von selbst: den schlechten Deploy zurückrollen, das Flag wieder ausschalten. Diese Aktionen sind von Haus aus umkehrbar, und sie sind es, die den Pager tatsächlich zum Schweigen bringen. Hinter dem Gate bleibt alles, was einen neuen Zustand erzeugt: Eine Codeänderung geht durch dein Review und deine CI, nie daran vorbei.

Die Linie verläuft nicht zwischen Mensch und Agent. Sie verläuft zwischen umkehrbar und nicht umkehrbar. Und deshalb bist du nicht heimlich doch noch On-Call: Der Rollback hat den Incident um 02:33 beendet, sechs Stunden bevor du den Pull Request gemergt hast. Der PR war nie das, was die Blutung gestoppt hat. Er ist das, was verhindert, dass es wieder passiert, und das kann bis zum Kaffee warten.

Und das Gate kannst du delegieren. Code-Review-Agenten lesen schon heute jeden Pull Request in deinem Repo. Es gibt eine Welt, nicht weit von dieser, in der dein Review-Agent den Fix um 02:41 liest, ihn gegen die Untersuchung prüft, ihn freigibt und deine CI in die Produktion deployt, bevor du aufwachst. Nichts am Kreislauf ändert sich, außer wer den Freigabe-Button hält. Dort endet das: Software, die sich selbst repariert, während du die Policy schreibst, statt auf Merge zu klicken.

Achte darauf, was in diesem Kreislauf fehlt:

Ask anything about your stack...

Das Prompt-Feld war ein großartiger Weg, diesen Systemen vertrauen zu lernen, und es ist ein schrecklicher Weg, Produktion zu betreiben. Der Agent hat jeden Deploy, jede Logzeile und jede Metrik über jeden Service gleichzeitig gesehen. Ihn hinter einem Prompt zu halten heißt, dass das bestinformierte Mitglied deines Teams nur spricht, wenn es angesprochen wird.

2026 sollte niemand mehr On-Call sein.