KI-Agenten
Einkaufsfragen für eine „KI-fähige“ Entwicklungsplattform
In einer Vorführung wirkt eine Entwicklungsplattform wie ein geschlossenes Ganzes: Ein Auftrag wird formuliert, Werkzeuge werden aufgerufen, eine plausible Antwort erscheint. Im Einkauf zerfällt dieses Bild jedoch in einzelne Verpflichtungen. Welche davon übernimmt der Anbieter tatsächlich? Welche muss Ihr Team selbst erfüllen? Für diese Fragen lohnt sich ein Blick hinter die Oberfläche, bevor aus einer gelungenen Demonstration eine langfristige Abhängigkeit wird.
Zuerst klären, was überhaupt geliefert wird
In meinem Open-Source-Projekt architecture-kit beschreibe ich Verträge, Datenstrukturen und Prüfanforderungen für portable Agentensysteme. Das Projekt ist ein Spezifikations- und Verifikationspaket, keine fertig betriebene Plattform. Es liefert weder die Modellsteuerung noch die ausführenden Dienste oder eine Datenbank. Genau diese Unterscheidung sollte auch in einem Angebot sichtbar sein, statt hinter dem Wort „Integration“ zu verschwinden.
Ein ausgewähltes Profil sagt dort, welche Anforderungen gelten. Es installiert keinen Dienst und erteilt keine Berechtigung. Übertragen auf den Einkauf bedeutet das: Lassen Sie sich für jede zugesagte Fähigkeit zeigen, welcher Baustein sie implementiert, wer ihn betreibt und welches Ergebnis seine Funktionsfähigkeit belegt. Eine Architekturzeichnung beantwortet diese Fragen noch nicht.
Verträge sind nützlich, aber noch kein Betrieb
Ein sauber definierter Werkzeugvertrag macht Erwartungen diskutierbar: Welche Eingabe wird akzeptiert, welche Antwort ist zu erwarten, was gilt als Fehler? Im architecture-kit helfen synthetische Beispiele und negative Vertragstests bei dieser Prüfung. Sie belegen aber weder eine laufende Installation noch eine Sicherheitsgrenze oder eine bestimmte Leistung unter realen Bedingungen.
Für eine Beschaffung würde ich deshalb eine kleine Nachweismatrix verlangen. Neben jeder wichtigen Anforderung stehen Implementierung, verantwortliche Stelle und passender Beleg. Eine Funktion darf darin ausdrücklich noch offen sein. Problematisch ist nicht die sichtbare Lücke, sondern die stillschweigende Umdeutung eines Beispiels in eine bereits gelieferte Eigenschaft, die später Ihr Betriebsteam herstellen muss.
Gute Anweisungen sind kein Leistungsversprechen
Mein Open-Source-Projekt unix-agent-skills sammelt kurze, unabhängig ladbare Arbeitsanweisungen für Agenten auf Unix-artigen Systemen. Sie behandeln etwa Werkzeugwahl, Prüfungen und Sicherheitsgrenzen. Dazu gehören Beispiele dafür, wann eine Anleitung passt und wann nicht. Solche wiederverwendbaren Regeln machen Arbeitsweisen sichtbar, ohne einen bestimmten Anbieter zur Voraussetzung zu machen oder dessen gesamte Plattform übernehmen zu müssen.
Der dokumentierte Stand benennt jedoch auch Grenzen: Ein Modellvergleich für die überarbeiteten Anweisungen war nicht durchgeführt, und bestimmte plattformspezifische Wege waren nicht auf der Zielplattform erprobt. Das ist eine wichtige Einkaufslektion. Gute Dokumentation und bestandene Zuordnungsfälle sind andere Belege als nachgewiesene Verhaltensverbesserungen in Ihrem Arbeitsalltag. Fragen Sie immer, welche Aussage eine Prüfung tatsächlich trägt.
Wissenszugang von richtigen Antworten unterscheiden
Mit mcp-nixos-rust pflege ich einen öffentlichen Rust-Fork eines bestehenden MCP-Servers. Er macht Informationen aus dem NixOS-Umfeld für KI-Clients abfragbar, etwa Paket- und Konfigurationsquellen oder Paketverläufe. Das ist eine Möglichkeit, Infrastrukturentscheidungen auf auffindbare Quellen zu stützen, statt ausschließlich auf die Erinnerung eines Modells. Die Herkunft als Fork gehört zur ehrlichen Beschreibung dieses Beitrags.
Eine erreichbare Quelle garantiert trotzdem keine richtige Schlussfolgerung. Lassen Sie sich zeigen, wie eine Plattform Aktualität, fehlende Quellen und widersprüchliche Ergebnisse behandelt. Ebenso wichtig ist die Unterscheidung zwischen externen Abfragen und Funktionen, die lokale Werkzeuge benötigen. Eine Vorführung auf dem Rechner des Anbieters beweist noch nicht, dass dieselbe Fähigkeit in Ihrer eingeschränkten Umgebung verfügbar ist.
Den späteren Betrieb mit einkaufen
Die entscheidende Frage ist oft nicht, ob ein Agent eine Aufgabe einmal erledigen kann, sondern wer ihn nach einer Änderung wieder arbeitsfähig macht. Abhängigkeiten, Berechtigungen und Datenquellen ändern sich. Ein Angebot sollte deshalb beschreiben, wer Störungen untersucht, wer Aktualisierungen freigibt und welche Nachweise nach einem Wechsel der Umgebung erneuert werden müssen. Ohne diese Zuordnung bleibt Verantwortung zwischen Einkauf und Technik liegen.
Ich würde eine begrenzte Erprobung mit eigenen Aufgaben einer breiten Funktionsliste vorziehen. Vereinbaren Sie vorher, welche Ergebnisse zählen und welche Unsicherheiten akzeptabel sind. Halten Sie außerdem fest, welche Konfigurationen und Arbeitsanweisungen bei einem Anbieterwechsel verfügbar bleiben. So entsteht eine Entscheidung über einen betreibbaren Dienst statt über ein überzeugendes Bild seiner möglichen Zukunft.
Fragen an Ihr Team oder Ihren Anbieter
- Welche angebotenen Fähigkeiten sind heute implementiert, und welche bestehen bislang nur als Spezifikation oder Beispiel?
- Welcher Nachweis zeigt die Kompatibilität mit unserer tatsächlichen Plattform und unseren Berechtigungen?
- Wie werden fehlende, veraltete oder widersprüchliche Wissensquellen für uns sichtbar?
- Welche Leistungsbehauptungen beruhen auf realen Aufgaben statt ausschließlich auf synthetischen Prüfungen?
- Wer übernimmt Betrieb, Störungsanalyse und erneute Freigabe nach Änderungen?
- Welche Konfigurationen und Arbeitsanweisungen können wir bei einem Anbieterwechsel weiterverwenden?