Eine KI-Demo läuft immer. Produktion stellt die anderen Fragen: Wer darf welches Tool im Namen welches Nutzers aufrufen? Was passiert bei einem Fehlschlag? Was kostet ein Nutzer im Monat? Ich baue die Infrastruktur hinter agentischen Systemen. MCP-Server, sichere Tool-Anbindung und LLM-Integration in bestehende Backends.
Machbarkeit als abgeschlossenes Ein- bis Zwei-Wochen-Mandat. Produktivbau danach typisch 2–4 Monate, mit der ausdrücklichen Option, nach der Machbarkeit nicht weiterzumachen.
Remote aus Deutschland. Direkt mit mir, ohne Agentur dazwischen.
Ein Agent der im Notebook funktioniert ist kein Produkt. Sobald echte Nutzer, echte Daten und echte Berechtigungen dazukommen verschiebt sich das Problem: Es geht nicht mehr um Prompts, sondern um Identität, Zugriffsrechte, Nachvollziehbarkeit, Fehlerverhalten und Kosten pro Anfrage.
Der kritische Teil eines agentischen Systems ist selten das Modell. Es sind die Tools: Was darf ein Agent im Namen eines Nutzers tun, wie wird das technisch durchgesetzt und wie sehen Sie hinterher was tatsächlich passiert ist. Genau dort setze ich an.
Typische SymptomeZuerst die unbequeme Frage: Braucht es dafür wirklich ein Modell? Manches ist eine Suchfunktion, manches eine Regel. Wenn ein LLM die richtige Antwort ist, definieren wir vorab was „gut genug" heißt und woran es gemessen wird.
Ihre bestehenden Systeme werden als Tools verfügbar gemacht, über MCP und mit klar umrissenen Fähigkeiten. Jedes Tool hat eine Signatur, eine Berechtigungsprüfung und ein definiertes Fehlerverhalten. Kein direkter Datenbankzugriff für Modelle.
Der Agent handelt im Namen eines Nutzers, nicht anstelle aller. OAuth 2 über Cognito, ein Token-Broker für nachgelagerte Systeme und Berechtigungen die dort geprüft werden wo sie hingehören. Jeder Tool-Aufruf ist einem Nutzer zuordenbar.
Token-Verbrauch pro Nutzer und Anwendungsfall, Limits und Budgets, Caching wiederkehrender Anfragen, kleinere Modelle wo sie reichen. Dazu Timeouts, Retries und ein sauberer Fallback wenn ein Anbieter ausfällt.
Testdatensätze aus echten Fällen, automatisierte Evaluationen in der Pipeline, Regressionen sichtbar vor dem Release. Ein Modell- oder Prompt-Wechsel wird damit zu einer Entscheidung mit Zahlen statt zu einem Gefühl.
Die Abbruchentscheidung ist Teil des Vorgehens. Nach der Machbarkeit wissen Sie, ob sich der Produktivbau rechnet, und dürfen Nein sagen.
Anwendungsfall, Datenlage, Erwartung. Wenn ein Modell nicht die richtige Lösung ist, sage ich das im Gespräch und nicht nach drei Monaten.
Prototyp am echten Datenbestand, Qualitätsmessung gegen eine Baseline, Kostenabschätzung pro Anfrage.
MCP-Server, Tool-Anbindung, Auth und Audit-Trail. Deployment auf AWS in Terraform, wie jeder andere Service auch.
Evaluationen in der Pipeline, Kosten- und Qualitäts-Dashboards, Übergabe an Ihr Team inklusive Pairing.
Jeder Tool-Aufruf hat einen Nutzer, eine geprüfte Berechtigung und einen Log-Eintrag.
Verbrauch pro Anwendungsfall sichtbar, Limits gesetzt, teure Aufrufe erkannt bevor sie zur Gewohnheit werden.
Modelle und Anbieter lassen sich wechseln, ohne die Anwendung neu zu bauen.
Das Model Context Protocol ist ein offener Standard dafür, wie ein Modell mit externen Systemen spricht. Ein MCP-Server stellt Ihre Systeme als klar definierte Tools bereit, mit Schema, Berechtigungsprüfung und Fehlerverhalten. Der Vorteil: Sie kontrollieren an einer Stelle was ein Agent tun darf, statt diese Logik in jede Anwendung zu kopieren.
Nicht zwingend. Über Amazon Bedrock bleiben Aufrufe innerhalb Ihrer AWS-Umgebung und Region. Welche Daten überhaupt in einen Prompt gelangen, wird auf Tool-Ebene entschieden und protokolliert. Das ist Teil des Entwurfs, nicht eine Einstellung am Ende.
Durch Messung und Grenzen: Token-Verbrauch pro Nutzer und Anwendungsfall, harte Limits, Caching wiederkehrender Anfragen und kleinere Modelle dort wo sie ausreichen. Die Kostenabschätzung entsteht in der Machbarkeitsphase, bevor gebaut wird, nicht wenn die erste Rechnung kommt.
Ja, das ist ein häufiger Ausgangspunkt. Der Prototyp beantwortet meist die Frage ob es fachlich funktioniert. Was dann fehlt ist der Weg in den Betrieb: Identität, Berechtigungen, Fehlerverhalten, Evaluationen und Kostenkontrolle. Genau diese Schicht baue ich.
Dann sagen wir das nach der Machbarkeitsphase und Sie haben ein bis zwei Wochen investiert statt zwei Quartale. Ein sauberes Nein mit Begründung ist ein legitimes Ergebnis, und deutlich billiger als ein Projekt, das niemand abbrechen will.
Manuelle Abläufe durch echte Systeme ersetzen: angebunden an Ihre Bestandssysteme, mit Berechtigungen und Protokoll statt Tool-Kette.
Mehr erfahrenIch finde wo Ihr AWS-Budget versickert, messbar reduziert, ohne Abstriche bei Performance oder Verfügbarkeit.
Mehr erfahrenVom eigenen Rechenzentrum oder aus einer anderen Cloud nach AWS, mit Kostenmodell vor dem Umzug und Rollback-Pfad für jeden Schritt.
Mehr erfahrenGewachsene Systeme schrittweise modernisieren: Strangler-Fig statt Rewrite, laufender Betrieb unangetastet, jeder Schritt umkehrbar.
Mehr erfahrenBackends für SaaS und Plattformen, die unter echter Last halten: in Go und PHP 8, event-getrieben, mit Mandantentrennung und Wiederanlauf im Entwurf.
Mehr erfahren