Was sind Agenten?

Neulich saß ich wieder in genau der Diskussion, die derzeit überall stattfindet: „Claude ist doch auch ein Agent. Wenn ich mir einen Agenten baue, ist das doch das Gleiche. Warum sollte ich den irgendwo deployen?“ Spoiler: Es ist nicht das Gleiche – aber die Übergänge sind fließend. Zeit, das mal sauber zu sortieren.

Chat, Code, Desktop: der interaktive Pol

Auf der einen Seite hast du deine Werkzeuge: Claude Desktop, Claude Code, ChatGPT – oder was auch immer auf deinem Rechner läuft. Du tippst etwas ein, das Modell arbeitet. Innerhalb dieser Session, in diesem Client, auf deinem Gerät. Und da ist schon die erste wichtige Erkenntnis: Klappst du den Rechner zu, ist Schluss. Deshalb laufen auf Konferenzen mittlerweile alle mit aufgeklappten Rechnern herum – die Session lebt nur so lange wie der Client.

Das ist das generische Werkzeug. Es kann alles Mögliche: ein Rezept, ein Skript, eine Recherche. Genau das ist gleichzeitig seine Grenze: Es kann alles – also nichts Spezielles.

Der Agent ist die Ausführungsumgebung

Ein Agent ist im Kern weder der Prompt noch das Modell – ein Agent ist die Laufzeitumgebung, in der das LLM arbeitet. Der sogenannte Harness: die Software, die die Loop ausführt, die Tools aufruft, Ergebnisse verarbeitet und entscheidet, wie mit Rückfragen umgegangen wird.

Und diese Umgebung muss nicht auf deinem Rechner laufen. Du kannst einen Agenten in eine Lambda-Funktion deployen, in einen Container, auf einen Server. Das entscheidende Merkmal: Er startet nicht, weil ein Mensch ihn öffnet, sondern weil ein Event eintritt.

Klassisches Beispiel: Es kommt eine E-Mail an. Du kannst nicht von außen auf deinem Rechner einen Claude-Prozess starten. Aber du kannst einen Agenten in einer Lambda-Funktion betreiben, der bei jeder eingehenden E-Mail getriggert wird, sie klassifiziert, verarbeitet – und danach wieder verschwindet. Eventgetrieben statt menschengesteuert. Das ist der Grundgedanke.

Was ist dann ein Skill?

Ein Skill ist keine Ausführungsumgebung. Ein Skill ist eine Anleitung, wie das LLM arbeiten soll – im Grunde ein Prompt oder ein Teil davon. „Lies dieses Dokument, prüfe es gegen diese Kriterien und erstelle einen strukturierten Bericht.“ Das ist ein Skill.

Skills laufen in einer Session – und Sessions laufen in einem Client. Auch in einem Agenten können Skills stecken. Aber: Der Skill sagt dem Modell, was zu tun ist. Er sagt nichts darüber, wie die Umgebung das tut.

Der Punkt, den viele übersehen: die Loop

Angenommen, dein Skill besagt: „Frag nicht nach, rate nicht.“ Gut. Aber wie genau das Nachfragen aussieht – ob ein Dialogfenster aufgeht, ob eine Mail verschickt wird, ob drei Leute eine Benachrichtigung mit Ja/Nein bekommen – das haben die Entwickler deiner jeweiligen Anwendung entschieden. Du hast darauf keinen Einfluss. Du kannst deiner Chat-App nicht per Prompt beibringen, dass die Oberfläche rosa sein soll.

Mit anderen Worten: Der Agent ist der Client, und der Skill läuft in der Session. Wenn du vollen Zugriff auf die Loop haben willst – wie Tools ausgeführt werden, wie der Agent mit Menschen interagiert, was er wo ablegt –, musst du den Agenten selbst bauen. Dann geht es eine Ebene tiefer: dein eigenes Python oder TypeScript, dein eigener Harness. Was im LLM passiert und was die Tools tun, bleibt dasselbe. Du schreibst im Grunde deine eigene, spezialisierte Version von Claude Chat.

Warum Eigenbau? Automatisierung und Unabhängigkeit

Dafür gibt es zwei handfeste Gründe:

• Automatisierung: Der Agent soll laufen, wenn niemand zusieht – nachts, bei jedem Event, ohne dass ein Rechner an ist.
• Unabhängigkeit: Wer sich nicht an einen Anbieter binden will, macht sein Tool vom Modell und vom Hersteller unabhängig. Heute läuft die Task mit dem einen Modell, nächste Woche mit einem anderen – oder lokal mit einem eigenen Inference-Setup.

Ein konkretes Beispiel: der Baustellentagesrapport

Stell dir eine App vor, in der Leute auf der Baustelle nur eine Sprachnotiz erfassen – mehr nicht. Aus dieser Notiz soll automatisch der Tagesrapport entstehen.

Legst du das Claude Desktop vor, kann es alles Mögliche – aber genau das willst du nicht. Du willst nicht, dass dort jemand nach dem Wetter oder einem Kochrezept fragt. Und du willst auch nicht, dass jeder erst eingibt: „Ich möchte jetzt einen Baustellenrapport für folgende Baustelle…“. Stattdessen: Sprachnotiz erfassen, fertig. Dahinter läuft ein Agent, der automatisch nachschaut, auf welcher Baustelle die Person ist, den Kontext zusammenbaut – und genau eine Sache tut: den Rapport generieren und in genau dieses Tool schreiben.

Das ist der Unterschied zwischen „Du kannst alles damit machen“ und „Es macht genau das“.

Und: Du musst nicht alles selbst schreiben

Natürlich geht es auch ohne eigenes TypeScript oder Python. Ich habe zum Beispiel in Notion einen Agenten, der – wenn jemand ein Kontaktformular ausfüllt – automatisch die Felder übernimmt und eine Recherche über die Person macht. Notion hat den Harness dafür gebaut, ich nicht. Er läuft halt dort statt in Claude Desktop. Es gibt schlicht verschiedene Clients, Agenten, Harnesses – nenn es, wie du willst. Quasi das Frontend, das die eigentliche Arbeit benutzt.

Fazit

• Chat / Desktop-Client: generisch, interaktiv, du startest es. Ende der Session, Ende der Arbeit.
• Skill: die Anleitung – ein Prompt, der sagt, wie das LLM arbeiten soll. Läuft in einer Session, egal ob im Client oder im Agenten.
• Agent: die Ausführungsumgebung. Eventgetrieben, automatisiert, ohne dass ein Mensch ihn startet – deployed in einer Lambda, einem Container oder als fertige Plattform wie Notion.

Es gibt fließende Übergänge zwischen all dem. Aber vom Prinzip her ist es einfach eine Ebene tiefer: Wenn du einen speziellen Use Case aus dem generischen Chat herausnimmst und dafür eine eigene Lösung baust, die genau das tut und automatisch läuft – dann baust du einen Agenten.

Die spannende Frage ist deshalb nicht „Was ist ein Agent?“, sondern: Welche deiner Prozesse sollen laufen, wenn niemand zusieht? Wenn du darauf eine Antwort hast, weißt du auch, wo du anfangen musst.