Klassischer Agent, KI-Agent: derselbe Job, zwei völlig verschiedene Köpfe

Seit ungefähr zwei Jahren ist alles ein "Agent". Jede App, die mehr als einen API-Call hintereinander macht, verkauft sich als agentisch, und im selben Atemzug klingt es, als hätte die Menschheit das Konzept gerade erst erfunden. Beides ist schief. Agenten sind uralt, und "Agent" heißt nicht automatisch "KI". Ich wollte den Unterschied nicht behaupten, sondern sehen. Also habe ich eine kleine Elixir-App gebaut, in der zwei Agenten exakt dieselbe Aufgabe lösen: ein Ziel in eine To-do-Liste zerlegen. Der eine folgt festen Regeln, der andere fragt ein Sprachmodell. Beide sind derselbe Agent-Typ, nur mit einem anderen Kopf. Genau an dieser einen Stelle sitzt der ganze Unterschied.

Agenten gibt es länger, als es "KI" im heutigen Sinn gibt

Bevor es um den Kontrast geht, ein kurzer Blick zurück, denn er ordnet die ganze Debatte ein. In dem Lehrbuch, das seit den Neunzigern jeder KI-Kurs benutzt, definieren Russell und Norvig einen Agenten denkbar schlicht: etwas, das seine Umgebung über Sensoren wahrnimmt und über Aktoren auf sie einwirkt. Wahrnehmen, entscheiden, handeln, in einer Schleife. Mehr steckt im Begriff nicht drin. Von neuronalen Netzen ist da keine Rede.

Und die Beispiele sind entsprechend alt. Shakey, der Roboter, den das SRI zwischen 1966 und 1972 durch seine Flure schob, zerlegte einen Auftrag wie "schieb den Klotz von der Plattform" selbst in Schritte, Route planen, hinfahren, Rampe suchen, schieben, und plante das mit einem Verfahren namens STRIPS, purer symbolischer Logik. MYCIN diagnostizierte in den Siebzigern Blutinfektionen mit rund sechshundert Wenn-dann-Regeln und schlug dabei teils menschliche Ärzte. Rodney Brooks stellte 1986 seine Subsumption-Architektur vor, Roboter, die ohne inneres Weltmodell auf Reize reagieren. In den Neunzigern kamen BDI-Agenten dazu, die aus Belief, Desire und Intention handeln, und Etzioni und Weld tauften 1994 ihre Internet-Programme "Softbots". Alles Agenten. Keiner davon hatte ein Sprachmodell im Bauch.

Der Punkt ist nicht Nostalgie. Der Punkt ist: Die Schleife aus Wahrnehmen, Entscheiden und Handeln ist das Alte und Stabile. Neu ist einzig, was man in die "Entscheiden"-Box legt. Jahrzehntelang standen dort Regeln, Suchbäume, Logik. Seit Kurzem kann dort ein LLM stehen. Das ist ein echter Sprung, aber es ist ein Austausch eines Bauteils, nicht die Erfindung des Autos.

Genau das wollte ich sichtbar machen, indem ich die Box zweimal fülle und außenrum alles gleich lasse.

Der Aufbau: ein Agent-Framework, zwei Agenten

Beide Agenten laufen auf Jido, einem Agenten-Framework für Elixir. Das Framework gibt die Schleife vor: ein Agent hält Zustand, bekommt eine Instruktion, führt eine Action aus, der Zustand ändert sich. Für den Vergleich ist das ideal, weil beide Agenten dieselbe Hülle benutzen. Der Aufruf ist auf beiden Seiten identisch:

agent = ClassicAgent.new()
{agent, _} = ClassicAgent.cmd(agent, {ClassicPlan, %{goal: ziel}})

Was sich unterscheidet, ist einzig die Action dahinter. Beim klassischen Agenten ist das reine Elixir-Regellogik. Beim KI-Agenten ist es ein Aufruf an ein Sprachmodell. Sonst nichts.

Gleiche Schleife, gleiche Hülle. Nur der Entscheidungskern in der Mitte ist ausgetauscht.

Der klassische Agent: Regeln, und nur Regeln

Der regelbasierte Planer macht drei Dinge. Er trennt das Ziel an Kommas und Zeilenumbrüchen, ordnet jedem Stück per Stichwort eine Priorität und eine Kategorie zu, und sortiert. Die Priorität ist ein Blick in zwei Wortlisten:

defp priority(text) do
  cond do
    Enum.any?(@high, &String.contains?(text, &1)) -> {:hoch, "Stichwort für hohe Priorität"}
    Enum.any?(@medium, &String.contains?(text, &1)) -> {:mittel, "Stichwort für mittlere Priorität"}
    true -> {:niedrig, "kein Stichwort → Standard niedrig"}
  end
end

Bei sauber formuliertem Input funktioniert das erstaunlich gut. Gibt man ihm

Dringend: Rechnung bezahlen, Meeting vorbereiten, E-Mail an Kunde beantworten

dann zerlegt er das in drei Aufgaben, erkennt "dringend" und zieht die Rechnung nach oben, sortiert "Finanzen", "Termine", "Kommunikation" auseinander. Kein Modell, keine Kosten, keine Wartezeit, und das Ergebnis ist zu hundert Prozent nachvollziehbar. Für genau diese Art von Eingabe ist der klassische Agent nicht nur ausreichend, er ist die bessere Wahl.

Das Verfahren stößt an seine Grenze beim ersten Satz, der nicht in dieses Schema passt:

Ich will diesen Sommer fitter werden, ohne dabei die Arbeit zu vernachlässigen.

Kein Komma, also für den Agenten eine einzige Aufgabe. Kein bekanntes Stichwort, also Priorität niedrig, Kategorie "Sonstiges". Der Agent liefert eine To-do-Liste mit genau einem sinnlosen Eintrag zurück und ist dabei völlig fehlerfrei. Er hat exakt getan, was ihm gesagt wurde. Er versteht den Satz nur nicht, weil Verstehen nicht in seiner Regelmenge vorgesehen ist. Das ist kein Bug, das ist die Bauart.

Der KI-Agent: dieselbe Hülle, ein Modell als Kern

Der KI-Agent bekommt denselben Satz und gibt ihn an ein Backend weiter. In der Demo ist das umschaltbar: ein simuliertes Backend ohne API-Key für die reine Vorführung, oder ein echter Aufruf an Claude. Der echte Aufruf ist unspektakulär, ein HTTP-Request, der eine strukturierte JSON-Antwort erzwingt:

body = %{
  model: "claude-opus-4-8",
  system: "Zerlege ein frei formuliertes Ziel in konkrete Teilaufgaben. " <>
          "Verstehe die Absicht, auch wenn der Text vage ist.",
  messages: [%{role: "user", content: goal}],
  output_config: %{format: %{type: "json_schema", schema: @schema}}
}

Req.post("https://api.anthropic.com/v1/messages", json: body, headers: headers)

Aus dem Fitness-Satz macht das Modell eine echte Zerlegung: ein realistisches Trainingsziel definieren, feste Zeiten in den Kalender eintragen, Arbeits- und Trainingszeiten aufeinander abstimmen, jeweils mit Priorität und einer kurzen Begründung. Es hat nirgends ein Stichwort gematcht. Es hat die Absicht hinter dem Satz gelesen und in Handlungen übersetzt. Genau das, woran der Regelagent scheitert, ist hier der Normalfall.

Nur, und das gehört zur Ehrlichkeit dazu: Derselbe Vorteil ist die Schwäche. Der Regelagent ist stur, aber berechenbar. Das Modell ist flexibel, aber nicht deterministisch. Es kann bei gleicher Eingabe unterschiedlich planen, es braucht Sekunden statt Millisekunden, es kostet pro Aufruf, und wenn es danebenliegt, tut es das mit voller Überzeugung und einer plausibel klingenden Begründung. Der Regelagent scheitert sichtbar. Das Modell scheitert überzeugend. Das ist ein Unterschied, mit dem man beim Bauen rechnen muss.

Wann ist es wirklich ein KI-Agent?

Die saubere Zweiteilung von eben ist eine Idealisierung. In echten Systemen sitzt selten das eine oder das andere in Reinform, und dann kommt die Frage, die sich an meiner Demo sofort stellt: Wenn mein regelbasierter Agent an einer Stelle ein LLM aufruft, kippt er damit schon zum KI-Agenten?

Die naheliegende, aber falsche Antwort wäre "ja, er enthält jetzt ein Modell". Enthalten sagt nichts. Die Frage ist, wer die Reihenfolge der Schritte bestimmt. Ruft feste Logik das Modell an einer fest verdrahteten Stelle als Unterprogramm auf, etwa "welche Kategorie hat dieser Eintrag?", dann ist das Modell nur eine schlauere Nachschlagefunktion, nicht anders als ein OCR-Tool. Der Steuerungsfluss bleibt regelbasiert. Strukturell ist das ein klassischer Agent mit einem smarten Baustein, mehr nicht.

Zum KI-Agenten wird es erst, wenn das Modell an der Spitze sitzt und die Entscheidungsgewalt über die Sequenz der Schritte übernimmt: welche Aktion als Nächstes, in welcher Reihenfolge, ob eine Schleife nötig ist. Das ist die schärfste Grenze, die man ziehen kann, und sie hat einen hübschen Test: Nimm das LLM weg. Bleibt ein Entscheider übrig, war es ein Werkzeug. Bleibt niemand mehr, der die Sequenz bestimmt, dann war das LLM der Agent.

Zwei Dinge gehören zu dieser Grenze dazu, sonst stimmt sie nur halb.

Erstens muss die Kontrolle iterativ gegen Rückmeldung ausgeübt werden, nicht einmal deklariert. Ein Modell, das einmal einen kompletten Plan ausspuckt, den dann eine feste Schleife stur abarbeitet, bestimmt formal auch die Reihenfolge, aber das ist ein Planer mit nachgelagerter Ausführung, kein Agent. Das eigentlich Agentische ist der geschlossene Kreis: Das Modell entscheidet den nächsten Schritt aus dem Ergebnis des vorigen. Genau der alte Wahrnehmen-Entscheiden-Handeln-Loop von oben. "An der Spitze sitzen" heißt also nicht "einmal die Reihenfolge festlegen", sondern "bei jedem Schritt neu entscheiden dürfen".

Zweitens ist "Spitze der Pyramide" eine Skala, kein Thron. Fast niemand gibt dem Modell uneingeschränkte Gewalt. Es wählt aus einem festen Tool-Set, innerhalb eines Zustandsautomaten, mit Budget-Limits und Abbruchbedingungen. Es entscheidet die Sequenz, aber auf Schienen. Das ist trotzdem ein KI-Agent, und zwar der Normalfall, nicht die verwässerte Ausnahme. Zwischen "Modell wählt aus fünf Tools im Rahmen" und "Modell schreibt sich beliebigen Code und eigene Ziele" liegen Welten an Autonomie. Beide sitzen an der Spitze, sind aber sehr verschiedene Tiere. Die Grenze trennt sauber den KI-Agenten von der regelgesteuerten Pipeline. Über den Grad der Autonomie sagt sie nichts, und der ist in der Praxis die interessantere Größe.

Kein Schalter, sondern ein Verlauf: Ab der Stelle, an der das Modell die Schrittfolge bestimmt, beginnt der KI-Agent – von eng geführt bis voll autonom.

Die zwei nebeneinander

Wenn man die Eigenschaften nebeneinanderlegt, wird deutlich, dass hier nicht "alt gegen neu" oder "schlecht gegen gut" steht, sondern zwei Werkzeuge mit gegensätzlichen Stärken:

Eigenschaft	Klassischer Agent	KI-Agent
Entscheidungskern	feste Regeln, Suchlogik	Sprachmodell
Erwartete Eingabe	strukturiert, bekanntes Format	beliebiger Freitext
Gleiche Eingabe, gleiche Ausgabe?	ja, immer	nicht garantiert
Nachvollziehbarkeit	vollständig, Regel für Regel	nur Begründung im Nachhinein
Unerwarteter Input	scheitert oder landet im Fallback	interpretiert, rät plausibel
Kosten pro Aufruf	praktisch null	Tokens / API-Kosten
Latenz	Millisekunden	Sekunden
Typischer Fehlermodus	zu starr, übersieht Bedeutung	erfindet Plausibles
Wartung	Regeln von Hand pflegen	Prompt und Modell justieren
Reifegrad	seit Jahrzehnten erprobt	jung, schnelllebig

Man liest die Tabelle am besten spaltenweise als Charakterzug, nicht zeilenweise als Wettkampf. Der klassische Agent ist der zuverlässige Beamte: erwartet das richtige Formular, arbeitet es fehlerfrei ab, hält sich nie für schlauer, als er ist. Der KI-Agent ist der findige Praktikant: versteht auch krude formulierte Aufträge, denkt mit, und erzählt einem gelegentlich mit fester Stimme etwas Falsches.

Was ich daraus mitnehme

Der Agent ist nicht das Neue. Die Wahrnehmen-Entscheiden-Handeln-Schleife ist Jahrzehnte alt und in Jido genauso zu sehen wie in Shakey. Wer heute "Agent" sagt und "KI" meint, verwechselt das Gehäuse mit dem einen Bauteil, das ausgetauscht wurde. Das macht die Sache nicht kleiner, aber es rückt sie gerade.

Der Bruch verläuft an genau einer Stelle. In meiner Demo unterscheiden sich die beiden Agenten in einer einzigen Datei: der Action. Alles andere drumherum, der Agent, das Framework, die Oberfläche, ist identisch. Das ist die praktische Lehre aus der Geschichte: Man muss nicht agentisch neu denken, um KI einzusetzen. Man tauscht den Entscheidungskern.

Beide haben ihren Platz. Bei strukturierter Eingabe mit klaren Regeln ist der klassische Weg schneller, billiger und prüfbar, und ihn durch ein Modell zu ersetzen wäre Angeberei. Sobald die Eingabe unstrukturiert und mehrdeutig ist, kippt es, und die festen Regeln werden zur Sackgasse. Die interessanten Systeme sind selten reines Entweder-oder, sondern lassen den Regelteil machen, was er gut kann, und rufen das Modell nur dort, wo Verstehen wirklich nötig ist.

Der Code ist bewusst klein gehalten, damit man beide Agenten nebeneinander laufen lassen und den Unterschied direkt am selben Ziel beobachten kann. Das ganze Projekt liegt offen auf GitLab: gitlab.com/public_elixir/agent_demo. Wenn euch eine Stelle genauer interessiert, wie Jido die Action an den Agenten hängt, warum der echte Modellaufruf ein erzwungenes JSON-Schema benutzt, oder wo die Grenze zwischen simuliertem und echtem Backend verläuft, schreibt es in die Kommentare. Ich gehe gerne tiefer.