Python Agentur Berlin — Backends, LLM-Integration und AI-Agenten

Erfahrung

10+ Jahre Python

Projekte

100+ realisiert

Schwerpunkt

LLM & AI-Agenten

Unser Python-Stack

Backends & APIs

Django REST Framework und FastAPI: Datenmodell, Auth, Rechte, Versionierung, OpenAPI-Spezifikation.

LLM-Integration

Anbindung von Claude, GPT und offenen Modellen an bestehende Systeme — inklusive Streaming, Caching und Kostenkontrolle.

RAG & Wissenssuche

Dokumente chunken, Embeddings erzeugen, mit pgvector durchsuchbar machen und Antworten mit Quellenangabe ausliefern.

AI-Agenten

Tool-Calling, MCP-Server für eure internen Systeme, mehrstufige Abläufe mit Abbruchbedingungen und Kostendeckel.

Datenverarbeitung

ETL-Pipelines, Import- und Exportstrecken, pandas-Auswertungen, geplante Jobs mit Celery.

Betrieb & Evaluation

Monitoring, Regressionstests für Prompt-Änderungen, Fehler-Budgets und Deployments, die niemanden nachts wecken.

Discovery

Woche 1–2

Anforderungen, Datenlage, Architekturentscheidungen, realistische Aufwandsschätzung

Setup

Woche 2–3

Projektstruktur, CI/CD, Datenbank, Docker, Testgerüst

Entwicklung

Woche 3–10

Iterative Sprints mit pytest, Code Reviews, wöchentlichem Zwischenstand

KI-Layer

Woche 8–12

LLM-Anbindung, RAG oder Agenten, Eval-Suite, Kostenkontrolle

Launch & Betrieb

ab Woche 12

Deployment, Monitoring, Übergabe oder laufende Betreuung

Was macht eine Python Agentur konkret?

Eine Python Agentur übernimmt Konzeption, Entwicklung und Betrieb von Software, deren Kern in Python geschrieben ist: Backends und REST-APIs mit Django oder FastAPI, Datenpipelines, Automatisierung von Geschäftsprozessen und — seit etwa 2023 der größte Wachstumsbereich — die Integration von LLMs und AI-Agenten in bestehende Systeme. Der Unterschied zu einer allgemeinen Softwareagentur liegt darin, dass KI-Layer und Geschäftslogik im selben Stack und im selben Team entstehen.

Was kostet ein Python-Projekt?

Ein klar abgegrenzter Prototyp — etwa eine LLM-Integration in ein bestehendes Backend — liegt typischerweise bei 10.000 bis 25.000 Euro. Eine vollständige Webanwendung mit Datenmodell, Auth, Admin und API beginnt bei rund 40.000 Euro. Entscheidend für die Spanne ist selten der Code, sondern wie klar die Anforderungen und wie sauber die bestehenden Datenquellen sind.

Django oder FastAPI — was ist die richtige Wahl?

Django, wenn ihr ein Datenmodell, Authentifizierung, ein Admin-Interface und langfristige Wartbarkeit braucht — also bei den meisten Produktivsystemen. FastAPI, wenn es um einen schmalen, asynchronen Service geht: Inference-Endpoints, Streaming, Webhooks. In der Praxis kombinieren wir beides häufig: Django als System of Record, FastAPI für den LLM-Layer davor.

Wie lange dauert es, ein LLM in ein bestehendes System zu integrieren?

Ein erster nutzbarer Durchstich dauert meist zwei bis vier Wochen. Der Aufwand steckt danach: Evaluation, Kostenkontrolle, Fehlerbehandlung bei Modellausfällen, Datenschutz und die Frage, was passiert, wenn das Modell falsch liegt. Wir planen deshalb von Anfang an mit einer Evaluations-Suite statt mit einem Demo-Prototyp.

Arbeitet ihr auch mit bestehenden Python-Codebasen?

Ja, das ist eher die Regel als die Ausnahme. Wir übernehmen gewachsene Django-Projekte, modernisieren Abhängigkeiten, führen Tests und CI/CD ein und bauen darauf neue Funktionen. Vor größeren Umbauten machen wir ein Assessment: Testabdeckung, Datenmodell, Deployment-Situation und die Frage, welche Teile überhaupt Änderungen brauchen.

Agentur oder Freelancer — was ist sinnvoller?

Freelancer sind sinnvoll für klar umrissene Aufgaben in einem Team, das bereits Architekturentscheidungen trifft. Eine Agentur lohnt sich, wenn Verantwortung für das Gesamtsystem abgegeben werden soll — inklusive Vertretung bei Ausfall, Code-Review durch mehrere Personen und Betrieb über Jahre. Der Stundensatz ist bei Agenturen höher, die Gesamtkosten über die Projektlaufzeit oft nicht.

Was ist ein AI-Agent und wann lohnt er sich?

Ein AI-Agent ist ein LLM, das Werkzeuge aufrufen darf — Datenbankabfragen, APIs, Dateisystem — und in mehreren Schritten auf ein Ziel hinarbeitet, statt nur einen Text zu erzeugen. Sinnvoll ist das, wenn die Aufgabe mehrere Schritte hat, die Reihenfolge vorher nicht feststeht und ein Fehler korrigierbar ist. Für deterministische Abläufe ist normaler Code fast immer die bessere, billigere und sicherere Lösung.

Warum Python die Standardsprache für KI-Systeme ist

Die Dominanz von Python im KI-Bereich ist kein Geschmacksurteil, sondern eine Frage der Referenzimplementierungen. PyTorch, Transformers, die offiziellen SDKs von Anthropic und OpenAI, LangGraph, die MCP-Referenzbibliothek — sie alle erscheinen zuerst in Python. Wer in einer anderen Sprache arbeitet, bekommt neue Fähigkeiten mit Monaten Verzögerung oder gar nicht.

Für Unternehmen ist die praktische Konsequenz wichtiger als die Bibliotheksfrage: Wenn das Backend ohnehin Python spricht, entsteht der KI-Layer im selben Repository, im selben Deployment und im selben Team. Es gibt keine Schnittstelle zwischen „KI-Team“ und „Produktteam“, die gepflegt und synchron gehalten werden müsste. Das ist der Grund, warum wir auch bei Projekten ohne aktuellen KI-Bedarf zu Python raten, wenn absehbar ist, dass er kommt.

Backend-Entwicklung mit Django und FastAPI

Django nehmen wir, wenn ein System ein Datenmodell im Zentrum hat: Nutzer, Rechte, Historie, Admin-Oberfläche, langfristige Migrationen. Das ORM und das Migrationssystem sind nach über fünfzehn Jahren ausgereift, und das Admin-Interface spart in fast jedem Projekt Wochen an Backoffice-Entwicklung.

FastAPI nehmen wir für schmale, asynchrone Dienste: Inference-Endpunkte, Streaming-Antworten, Webhook-Empfänger, alles mit hoher Nebenläufigkeit und wenig Datenmodell. Die automatische OpenAPI-Spezifikation aus Typannotationen macht die Zusammenarbeit mit Frontend-Teams deutlich einfacher.

In größeren Systemen kombinieren wir beides: Django als System of Record mit der Geschäftslogik, davor ein FastAPI-Service für den LLM-Layer, der asynchron arbeiten und unabhängig skalieren muss. Beide teilen sich Datenbank und Modelldefinitionen — es bleibt ein Python-Projekt.

LLM-Integration: was den Aufwand wirklich treibt

Der Aufruf einer LLM-API ist eine Zeile Code. Was danach kommt, ist die Arbeit. Aus unseren Projekten sind das immer wieder dieselben Punkte:

• Kontextbeschaffung: Welche Daten braucht das Modell, woher kommen sie, wie aktuell müssen sie sein?
• Fehlerverhalten: Was passiert bei Rate-Limits, Timeouts oder einem Modell, das kurzfristig abgekündigt wird?
• Kostenkontrolle: Token-Budgets pro Nutzer und Aufgabe, Caching identischer Anfragen, günstigere Modelle für einfache Teilschritte.
• Qualitätsmessung: eine Sammlung von Referenzfällen, gegen die jede Prompt- und Modelländerung läuft, bevor sie live geht.
• Datenschutz: Auftragsverarbeitungsvertrag, EU-Verarbeitung, Ausschluss der Trainingsnutzung, Löschkonzept für Embeddings.

Keiner dieser Punkte ist besonders exotisch — es ist solide Softwareentwicklung. Genau deshalb scheitern viele KI-Projekte nicht am Modell, sondern daran, dass sie als Experiment gestartet und nie in ein Produkt überführt wurden.

AI-Agenten und das Model Context Protocol

Ein AI-Agent unterscheidet sich von einer normalen LLM-Anfrage dadurch, dass das Modell Werkzeuge aufrufen darf und mehrere Schritte plant. Das eröffnet Anwendungsfälle, die mit einem einzelnen Prompt nicht lösbar sind — bringt aber Zustand, Nichtdeterminismus und potenziell unbegrenzte Kosten mit sich. Wir bauen Agenten deshalb grundsätzlich mit harten Abbruchbedingungen: maximale Schrittzahl, Token-Deckel, und eine klare Trennung zwischen lesenden und schreibenden Werkzeugen.

Das Model Context Protocol hat die Anbindung interner Systeme seit 2025 deutlich vereinfacht. Statt für jeden LLM-Anbieter eine eigene Tool-Integration zu schreiben, beschreibt ein MCP-Server eure Systeme einmal — und jeder kompatible Client kann sie nutzen. Für Unternehmen mit gewachsener Systemlandschaft ist das der pragmatischste Einstieg in agentische Anwendungen, weil die Investition nicht an einen Anbieter gebunden ist.

Was uns von anderen Python-Agenturen unterscheidet

Über 100 Projekte in 25 Jahren, davon die letzten zehn mit Python als Kern-Stack. Vom Potsdam-Institut für Klimafolgenforschung über die Humboldt-Universität bis zu SaaS-Produkten wie finban.io, das wir selbst entwickeln und betreiben.

Der praktische Unterschied liegt darin, dass wir Software nicht nur schreiben, sondern selbst betreiben. Wer sein eigenes Produkt im Livebetrieb hat, trifft andere Architekturentscheidungen als jemand, der nach Abnahme aus dem Projekt geht. Das merkt man an Kleinigkeiten: daran, wie viel Logging drin ist, wie Migrationen geplant werden und wie ehrlich Aufwandsschätzungen ausfallen.