Falsches Vokabular kostet dich zwei Agent-Verträge statt einem

Letzte Woche erschien ein neues Hugging Face Glossar zu KI-Agent-Terminologie — leise, fast unbemerkt. Als Tutorial ist es nett. Als Procurement-Filter ist es Gold wert. Wenn dein Team sich nicht einigen kann, welche Schicht ein Anbieter eigentlich verkauft, kaufst du überlappende Infrastruktur — und hast das wahrscheinlich schon getan. Im Vokabular-Gap zwischen "harness", "scaffold" und "runtime" versteckt sich doppelter Spend.

Was sich an der Definition von Agent-Infrastruktur geändert hat

Das Hugging Face Agent Glossary zieht klare Grenzen zwischen Begriffen, die die Branche bislang synonym verwendet hat. Ein harness ist ein Test- und Evaluation-Wrapper — er schickt deinen Agenten durch Szenarien und misst das Verhalten. Ein scaffold ist die strukturelle Schicht, die Agent-Schritte sequenziert, Tool Calls verwaltet und den Control Flow steuert. Ein runtime ist die Ausführungsumgebung: Memory-Management, Concurrency, State Persistence. Das sind drei verschiedene Probleme, drei verschiedene Anbieter-Kategorien und drei verschiedene Build-vs-Buy-Entscheidungen.

Die Verwirrung ist kein Zufall. Die meisten Anbieter, die "Agent-Plattformen" verkaufen, bündeln zwei oder drei dieser Schichten — ohne sie separat zu kennzeichnen. Ein Anbieter, der eine "Agent Orchestration Platform" pitcht, verkauft dir vielleicht einen scaffold, einen runtime oder beides — und sein Sales Deck wird den Unterschied nicht freiwillig offenlegen. Dieselbe Vermischung findet sich in Open-Source-Projekten: Frameworks wie LangGraph, AutoGen und CrewAI betonen jeweils unterschiedliche Schichten. Genau deshalb stellen Teams, die zwei davon einsetzen, erhebliche Überschneidungen erst fest, wenn die Integration bereits läuft.

Das Glossar klärt außerdem zwei angrenzende Begriffe: Tool Use (der Mechanismus, mit dem ein Agent externe APIs oder Funktionen aufruft) und Agent Memory (Kurzzeit-Kontext versus Langzeit-Retrieval). Das sind Fähigkeiten, keine Schichten — sie leben je nach Implementierung im scaffold oder runtime. Wer sie als eigene Schichten behandelt, landet in einer dritten Kategorie redundanter Käufe: Man kauft eine "Memory-Lösung" bei einem Anbieter, obwohl der scaffold sie längst mitbringt.

Warum das die Rechnung zur Agent-Eigenverantwortung für 50–500-FTE-Teams verändert

In eurer Größenordnung baut ihr nicht alles von Grund auf — und kauft auch keine monolithische Enterprise-Suite. Ihr assembliert. Das bedeutet: Die Build-vs-Buy-Entscheidung ist keine eine Entscheidung, sondern drei — auf drei verschiedenen Schichten, mit drei verschiedenen Risikoprofilen.

Die harness-Schicht ist fast immer eine Buy- oder Open-Source-Entscheidung. Evaluation-Frameworks sind Commodity-Infrastruktur. Eine eigene zu bauen lohnt sich selten, außer wenn die Domain Compliance-Anforderungen hat, die Off-the-Shelf-Tools nicht erfüllen können. Die runtime-Schicht ist heikel: Fehler bei State Management, Persistence und Concurrency zeigen sich in Produktion, nicht in Demos. Hier unterschätzen die meisten Teams die Build-Kosten. Ein scaffold hingegen ist dort, wo eure Business-Logik lebt — die Sequenzierung von Schritten, die widerspiegelt, wie euer Prozess tatsächlich funktioniert. Diese Logik ist oft es wert, selbst zu besitzen, auch wenn der runtime darunter es nicht ist.

Die praktische Konsequenz: Wenn ein Anbieter anbietet, "eure Agent-Infrastruktur zu übernehmen", lautet die richtige Frage nicht "Was kostet das?", sondern: "Welche der drei Schichten deckt das ab — und was sagt der Vertrag über die anderen?" Teams, die diese Frage überspringen, kaufen einen scaffold bei Anbieter A, stellen fest, dass sie noch einen runtime brauchen, kaufen den bei Anbieter B — und entdecken sechs Monate später, dass Anbieter As scaffold einen eigenwilligen runtime mitbringt, der jetzt Konflikte verursacht. Wir haben das in mehreren Kundenprojekten erlebt. Das Vokabular ist die Due Diligence.

Sprich mit Domani AI darüber, wie wir das gemeinsam angehen →

Was ein CTO diese Woche tut, um Infrastruktur nicht zweimal zu kaufen

Mach ein 90-minütiges internes Audit, bevor du den nächsten Anbieter-Call führst. Das Ziel: eine einseitige Layer Map — was besitzt oder betreibt ihr aktuell auf der harness-, scaffold- und runtime-Schicht? Die meisten Teams stellen fest, dass sie auf zwei Schichten teilweise Abdeckung haben und auf der dritten gar nichts. Genau diese Lücke sollte dein nächster Anbieter-Call adressieren — gezielt und nur diese Lücke.

Dann wende diesen Entscheidungsbaum auf jeden Anbieter-Vorschlag in deiner Pipeline an:

• Benennt der Anbieter klar, welche Schicht(en) sein Produkt abdeckt? Falls nicht: verlange es schriftlich vor dem nächsten Call.
• Hast du auf einer der angebotenen Schichten bereits Teilabdeckung? Falls ja: fordere einen eingeschränkten Vertrag, der das bereits Vorhandene ausschließt.
• Hat der scaffold des Anbieters eine feste Meinung zum runtime? Falls ja: das ist ein Lock-in-Risiko. Hol dir die Entkopplungs-Bedingungen in den Vertrag oder kalkuliere die Migrationskosten ein.
• Ist eure Kern-Business-Logik im scaffold eingebettet? Falls ja: besitzt diese Schicht selbst. Vertragt harness und runtime.
• Geht es primär um Testing und Evaluation? Dann brauchst du einen harness, keine Plattform — und kannst das wahrscheinlich mit einem Open-Source-Tool in unter 2 Wochen lösen.

Wenn du gerade mitten in einer Evaluation mit einem Agent-Anbieter steckst und deren Produkt noch nicht auf diese drei Schichten gemappt hast: Pause das kommerzielle Gespräch und mach das Mapping zuerst. Eine Stunde interner Abstimmung spart 6 Monate Re-Architektur.

Was das kostet — und was es spart

Das Mapping-Exercise kostet grob 4 Stunden von einem Senior Engineer und 90 Minuten von dir. Wenn ihr einen externen Architektur-Reviewer einbezieht, rechnet mit einem halben Tag Beratungszeit. Das sind die vollständigen Kosten, wenn du es vor der Unterschrift machst. Wenn du es danach machst, sind die Kosten: der doppelte Vertrag, die Integrationsarbeit zur Abstimmung zweier runtimes und die Engineering-Zeit, die für eine Migration verloren geht, die ihr hättet vermeiden können — typischerweise 3 bis 8 Wochen Kapazität eines kleinen Teams, basierend auf dem, was wir in Post-Mortem-Projekten sehen.

Die Ersparnis ist nicht nur Geld. Es ist Optionalität. Teams, die ihre scaffold-Schicht selbst besitzen und alles andere vertraglich regeln, behalten die Fähigkeit, Runtime-Anbieter zu wechseln, wenn sich die Preise ändern oder eine bessere Option erscheint. Teams, die eine gebündelte Plattform kaufen, ohne die Schichten zu verstehen, stellen oft fest, dass sie nichts Trennbares besitzen — und verhandeln aus einer schwachen Position nach. In einem Markt, in dem Agent-Infrastruktur-Preise noch volatil sind und die Konsolidierung unter Anbietern anhält, hat diese Optionalität einen wachsenden Wert.