In Ordnung, Leute. Leo Grant hier, zurück in den digitalen Gräben bei agntdev.com. Heute möchte ich über etwas sprechen, das mir seit einiger Zeit im Kopf herumgeht, etwas, das ich in Forum um Forum, Discord um Discord immer wieder auftauchen sehe: die Debatte „bauen oder kaufen“ im Zusammenhang mit interner Agentenorchestrierung. Konkret konzentriere ich mich auf die Orchestrierungsebene selbst, nicht auf die Agenten. Es ist 2026, und der Agentenbereich bewegt sich mit Lichtgeschwindigkeit. Wir sind über die theoretischen Konzepte hinaus. Wir bauen echte, produktionsreife Systeme.
Ich war in den letzten sechs Monaten intensiv damit beschäftigt, zuerst bei einem Kunden, bei dem wir eine Lösung gekauft haben, und dann, vor kurzem, bei einem anderen Kunden, bei dem wir aktiv eine von Grund auf bauen. Der Gegensatz war frappierend, aufschlussreich und ehrlich gesagt manchmal ein wenig frustrierend. Also lass uns das aufdröseln, denn ich denke, viele von euch da draußen haben mit genau dieser Entscheidung zu kämpfen.
Das „Kaufen“-Argument: Wenn Fertiglösungen Sinn machen (und wenn nicht)
Mein erster Kunde, nennen wir sie „InnovateCo“, hatte eine klare Vorgabe: ein Agentensystem schnell zum Laufen bringen. Sie waren ein mittelständisches Unternehmen, kein Tech-Riese, und ihr internes Entwicklerteam war bereits stark ausgelastet. Ihr Kerngeschäft war nicht die Entwicklung von Agenten; es war Logistik. Daher schien der Erwerb einer fertigen Orchestrierungsplattform die naheliegende Wahl zu sein.
Wir haben einige Optionen evaluiert, uns für einen der bekanntesten Anbieter entschieden – ich werde keine Namen nennen, aber ihr könnt euch wahrscheinlich ein paar denken – und haben losgelegt. Die anfängliche Einrichtung verlief überraschend reibungslos. Die Plattform konnte mit einer eleganten Benutzeroberfläche, Drag-and-Drop-Workflows und dem Versprechen von „Out-of-the-Box-Integrationen“ aufwarten.
Die Vorteile: Schnelligkeit auf dem Markt und reduzierte Anfangskosten
- Schnelle Bereitstellung: Wir hatten unsere ersten wenigen Agenten innerhalb von ein paar Wochen mit dem Orchestrator kommuniziert und grundlegende Aufgaben erledigt. Das war ein großer Gewinn für die Stakeholder, die einfach sehen wollten, dass etwas funktioniert.
- Verwaltete Infrastruktur: Kein Grund, sich um das Skalieren von Datenbanken, Nachrichtenwarteschlangen oder API-Gateways Sorgen zu machen. Der Anbieter kümmerte sich um all das. Für ein Team ohne dedizierte DevOps für Agentensysteme war das eine enorme Erleichterung.
- Funktionsvielfalt (auf dem Papier): Die Plattform hatte eine Menge Funktionen: Monitoring, Logging, Versionierung, Zugriffskontrolle. Es schien umfassend zu sein.
InnovateCo war glücklich. Für eine Weile. Die anfängliche Aufregung war spürbar. Wir hatten ein Dashboard, wir hatten Kennzahlen und konnten neue Agenten-Workflows mit wenigen Klicks erstellen. Es fühlte sich an, als würden wir wirklich die Grenzen verschieben.
Die Nachteile: Die „Vendor Lock-in“-Blues und Anpassungskopfschmerzen
Dann kam das Unvermeidliche. Als unsere Agenten-Anwendungsfälle komplexer wurden, stießen wir auf Wände. InnovateCo benötigte spezifische benutzerdefinierte Logik für die Aufgabenverteilung basierend auf aktuellen externen Datenfeeds – Daten, die nicht einfach in die vordefinierten Verbindungsstellen der Plattform integriert werden konnten. Wir benötigten eine benutzerdefinierte Fehlerbehandlung, die eine komplizierte Wiederholungslogik auf Basis der externen API-Durchsatzgrenzen umfasste, nicht nur ein einfaches exponentielles Backoff.
Jede kleine Abweichung vom vorgesehenen Design der Plattform wurde zu einem Kampf. Wir mussten ständig Support-Tickets einreichen, Funktionen anfordern oder versuchen, unsere Anforderungen in ihr bestehendes Framework zu pressen. Die „Out-of-the-Box-Integrationen“ erwiesen sich als weniger flexibel als beworben. Wir fanden uns damit wieder, jede Menge „Klebecode“ extern zu schreiben, um unsere Agenten an den Orchestrator anzupassen, und dann noch mehr Klebecode, um den Orchestrator an unsere internen Systeme anzupassen.
Meine persönliche Frustration wuchs, als wir einen sehr spezifischen, kontextbewussten Mechanismus für die Übergabe von Agenten implementieren mussten. Die Plattform hatte eine grundlegende Übergabe, aber sie berücksichtigte nicht die nuancierte Zustandsverwaltung, die wir benötigten. Am Ende bauten wir einen völlig separaten Mikroservice nur für diese Verwaltung, wodurch wir die beabsichtigte Funktionalität des Orchestrators für diesen spezifischen Workflow effektiv umgingen.
Hier begann die „Kaufen“-Strategie, ihre Risse zu zeigen. Der anfangliche Geschwindigkeitsvorteil wurde durch die Reibung der Anpassung aufgezehrt. Wir zahlten eine hohe Abonnementsgebühr und machten dennoch einen erheblichen Teil der benutzerdefinierten Entwicklung um die Plattform herum, anstatt auf ihr. Die versprochene Reduzierung der Anfangskosten fühlte sich an wie eine Illusion.
Das „Bauen“-Argument: Kontrolle (und Verantwortung) übernehmen
Spulen wir vor zu meinem aktuellen Kunden, „PioneerTech“. Sie sind ein kleineres, agileres Start-up, das tief in der KI-Forschung und -Entwicklung eingebettet ist. Ihr Kernerzeugnis sind intelligente Agenten. Für sie war die Entscheidung, ihre eigene Orchestrierungsebene zu bauen, beinahe eine Selbstverständlichkeit. Sie benötigten ultimative Flexibilität, fein abgestimmte Kontrolle und die Fähigkeit, schnell an experimentellen Agentenarchitekturen zu iterieren.
Meine Rolle dort besteht darin, bei der Architektur und dem Bau dieses internen Orchestrierungssystems zu helfen. Es war eine völlig andere Erfahrung.
Die Vorteile: Unbegrenzte Flexibilität und echtes Eigentum
- Auf Ihre Bedürfnisse zugeschnitten: Wir bauen genau das, was PioneerTech benötigt, nicht mehr, nicht weniger. Jede Funktion, jede Integration, jedes Stück Logik ist darauf ausgelegt, ihre spezifischen Probleme zu lösen.
- Tiefe Integration: Da wir die gesamte Infrastruktur kontrollieren, können wir tief mit ihren bestehenden internen Tools, Datenspeichern und KI-Modellen integrieren, ohne dass es zu Impedanzabweichungen kommt.
- Kein Vendor Lock-in: Das ist ein großer Vorteil. Wir sind nicht von der Roadmap, der Preisstruktur oder den architektonischen Entscheidungen eines Anbieters abhängig. Wir besitzen das geistige Eigentum und das Schicksal unseres Systems.
- Optimierte Leistung: Wir können auf ihre spezifischen Arbeitslasten optimieren und die richtigen Datenbanken, Nachrichtenwarteschlangen und Rechnerressourcen auswählen, ohne durch die Entscheidungen einer allgemeinen Plattform eingeschränkt zu sein.
Ein aktuelles Beispiel: PioneerTech benötigte ein hoch dynamisches Aufgabenzuweisungssystem, basierend auf der aktuellen Kapazität, den Fähigkeiten und der historischen Leistung der Agenten. Wir entwarfen einen maßgeschneiderten Scheduler, der Daten aus mehreren internen Diensten abruft, einen gewichteten Bewertungsalgorithmus anwendet und Aufgaben an den am besten geeigneten Agenten zuteilt. Eine solche komplexe, maßgeschneiderte Logik wäre auf einer fertigen Plattform ein Albtraum gewesen.
Hier ist ein vereinfachter Auszug, wie wir eine Aufgabe in unserem System definieren könnten, unter Verwendung eines einfachen Pydantic-Modells zur Validierung und einer Nachrichtenwarteschlange zur Zuweisung:
from pydantic import BaseModel, Field
from typing import Dict, Any
import json
import pika # Beispiel: Verwendung von RabbitMQ
class AgentTask(BaseModel):
task_id: str = Field(..., description="Eindeutige Kennung für die Aufgabe")
agent_type: str = Field(..., description="Typ des benötigten Agenten für die Aufgabe")
payload: Dict[str, Any] = Field(..., description="Aufgabenspezifische Daten")
priority: int = Field(5, ge=1, le=10, description="Aufgabenpriorität (1-10)")
callback_url: str | None = Field(None, description="URL für den Callback nach Abschluss der Aufgabe")
def publish_task(task: AgentTask, queue_name: str = 'agent_tasks'):
"""Veröffentlicht eine Agentenaufgabe in einer Nachrichtenwarteschlange."""
connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()
channel.queue_declare(queue=queue_name)
message = task.model_dump_json()
channel.basic_publish(
exchange='',
routing_key=queue_name,
body=message,
properties=pika.BasicProperties(
delivery_mode=pika.spec.PERSISTENT_DELIVERY_MODE
)
)
print(f" [x] Gesendet '{task.task_id}' an '{queue_name}'")
connection.close()
# Beispielverwendung:
if __name__ == "__main__":
task_data = {
"task_id": "order-processing-001",
"agent_type": "OrderProcessor",
"payload": {"order_id": "ABC123", "customer_id": "CUST456"},
"priority": 8,
"callback_url": "https://api.pioneertech.com/tasks/callback"
}
new_task = AgentTask(**task_data)
publish_task(new_task)
Dieses Maß an Kontrolle, vom Datenmodell bis zum Nachrichtenbroker, ermöglicht es uns, unglaublich effiziente und spezialisierte Systeme zu bauen. Wir kämpfen nicht gegen eine allgemeine Abstraktion; wir gestalten das genaue Werkzeug, das wir benötigen.
Die Nachteile: Bedeutende anfängliche Investitionen und laufende Wartung
Natürlich gibt es dafür keine kostenlose Lösung. Der Bau von Grund auf bringt seine eigenen Herausforderungen mit sich:
- Höhere Anfangskosten: Wir investieren erhebliche Ingenieurestunden im Voraus. Das ist keine schnelle Lösung.
- Erhöhte Verantwortung: Wir sind für alles verantwortlich – Infrastruktur, Sicherheit, Skalierbarkeit, Bugs. Es gibt keinen Support-Hotline des Anbieters, den man anrufen kann.
- Funktionale Parität: Wir müssen entscheiden, welche „Standard“-Funktionen (wie detaillierte Dashboards, Audit-Trails, erweiterte Zugriffskontrolle) wichtig genug sind, um sie selbst zu entwickeln, und auf welche wir verzichten oder einfacher umsetzen können.
- Time to Market (anfangs): Die Bereitstellung eines voll funktionsfähigen, produktionsbereiten Systems dauert länger als die Erstellung einer SaaS-Lösung.
Mein aktuelles Team verbringt viel Zeit mit Infrastructure as Code, der Einrichtung von Monitoring und der Gewährleistung solider Fehlerbehandlung. Wir müssen von Grund auf an die Resilienz denken. Zum Beispiel hier ist ein konzeptioneller Entwurf eines grundlegenden Mechanismus für die Agentenregistrierung und den Herzschlag, den wir möglicherweise implementieren könnten:
# Vereinfachtes konzeptionelles Beispiel für die Registrierung von Agenten und Heartbeats
# In einem realen System würde dies eine Datenbank, eine solide API und eine ordnungsgemäße Authentifizierung erfordern.
import time
import uuid
from datetime import datetime
class AgentRegistry:
def __init__(self):
self.registered_agents = {} # {agent_id: {"last_heartbeat": datetime, "capabilities": [], "status": "active"}}
def register_agent(self, agent_id: str, capabilities: list):
if agent_id not in self.registered_agents:
self.registered_agents[agent_id] = {
"last_heartbeat": datetime.now(),
"capabilities": capabilities,
"status": "active"
}
print(f"Agent {agent_id} registriert mit Fähigkeiten: {capabilities}")
return True
else:
print(f"Agent {agent_id} bereits registriert. Aktualisiere Heartbeat.")
self.send_heartbeat(agent_id)
return False
def send_heartbeat(self, agent_id: str):
if agent_id in self.registered_agents:
self.registered_agents[agent_id]["last_heartbeat"] = datetime.now()
self.registered_agents[agent_id]["status"] = "active"
# print(f"Heartbeat erhalten von Agent {agent_id}")
else:
print(f"Warnung: Heartbeat von nicht registriertem Agenten {agent_id}")
def get_active_agents(self, capability: str | None = None):
active_agents = []
for agent_id, data in self.registered_agents.items():
if data["status"] == "active" and (capability is None or capability in data["capabilities"]):
# Einfacher Frische-Check (z. B. letzter Heartbeat innerhalb von 60 Sekunden)
if (datetime.now() - data["last_heartbeat"]).total_seconds() < 60:
active_agents.append(agent_id)
else:
self.registered_agents[agent_id]["status"] = "inactive" # Als inaktiv markieren
return active_agents
# Simuliere Agenten, die Heartbeats senden
if __name__ == "__main__":
registry = AgentRegistry()
agent_a_id = str(uuid.uuid4())
agent_b_id = str(uuid.uuid4())
registry.register_agent(agent_a_id, ["data_analysis", "report_generation"])
registry.register_agent(agent_b_id, ["data_ingestion", "validation"])
print("\n--- Initiale Aktive Agenten ---")
print(f"Alle: {registry.get_active_agents()}")
print(f"Datenanalyse: {registry.get_active_agents('data_analysis')}")
# Simuliere Heartbeats über die Zeit
for _ in range(3):
time.sleep(10) # 10 Sekunden warten
registry.send_heartbeat(agent_a_id)
print(f"\nAktive 'data_analysis' Agenten nach Heartbeat: {registry.get_active_agents('data_analysis')}")
# Simuliere, dass Agent B offline geht (keine weiteren Heartbeats)
print("\n--- Agent B geht offline ---")
time.sleep(70) # Länger als die Heartbeat-Schwelle warten
print(f"Aktive 'validation' Agenten: {registry.get_active_agents('validation')}") # Sollte leer sein
print(f"Alle aktiven Agenten: {registry.get_active_agents()}") # Agent A sollte weiterhin aktiv sein
Dieser Code ist nur ein konzeptioneller Ausgangspunkt, aber er veranschaulicht die Art von grundlegenden Komponenten, die Sie benötigen, wenn Sie den "build"-Weg gehen. Jedes Stück erfordert sorgfältige Planung, Tests und Bereitstellung. Es ist ein Marathon, kein Sprint.
Das Urteil: Es kommt darauf an (aber im Ernst)
Nachdem ich auf beiden Seiten dieses Zauns war, ist meine Schlussfolgerung kein einfaches "Build gewinnt immer" oder "Buy gewinnt immer." Es hängt wirklich, wirklich, ehrlich von Ihrem spezifischen Kontext ab.
Hier ist, wie ich begonnen habe, Kunden zu beraten:
Wann man stark in Betracht ziehen sollte, eine Orchestrierungsplattform zu "kaufen":
- Ihr Kerngeschäft sind keine Agenten: Wenn das Wertversprechen Ihres Unternehmens nicht direkt an die Agententechnologie selbst gebunden ist und Agenten mehr einer unterstützenden Funktion entsprechen, kann der Kauf sinnvoll sein.
- Begrenzte Entwicklungsressourcen: Wenn Ihr Entwicklungsteam klein, bereits beschäftigt oder nicht über spezifisches Fachwissen in verteilten Systemen und Agentenarchitekturen verfügt.
- Standardisierte Workflows: Ihre Agenten-Anwendungsfälle sind relativ unkompliziert, passen gut in gängige Muster (z. B. einfache Aufgabenverteilung, grundlegende sequenzielle Workflows) und erfordern keine hochspezialisierte Logik.
- Geschwindigkeit ist entscheidend (anfänglich): Sie müssen schnell etwas zum Laufen bringen, um ein Konzept zu beweisen oder einen unmittelbaren Geschäftszweck zu erfüllen, selbst wenn das bedeutet, dass es später einige Kompromisse erfordert.
- Budget für SaaS: Sie haben ein Betriebskapital für wiederkehrende SaaS-Gebühren und ziehen Opex gegenüber Capex für Softwareentwicklung vor.
Wann man stark in Betracht ziehen sollte, Ihre eigene Orchestrierungsebene zu "bauen":
- Agenten sind Ihr Kerngeschäft/unterscheidendes Merkmal: Wenn Ihr Produkt intelligente Agenten sind oder Agenten einen entscheidenden Wettbewerbsvorteil darstellen, benötigen Sie volle Kontrolle.
- Hochgradig individuelle oder komplexe Workflows: Ihre Interaktionen zwischen Agenten umfassen komplizierte Zustandsverwaltung, dynamisches Routing basierend auf Echtzeitdaten, komplexe Entscheidungsbäume oder die Zusammenarbeit zwischen mehreren Agenten, die über einfache sequenzielle oder parallele Ausführung hinausgeht.
- Notwendigkeit zur tiefen Integration: Sie müssen eng mit einzigartigen internen Systemen, proprietären Datenquellen oder spezialisierten KI-Modellen integrieren, die von Standardplattformen nicht nativ unterstützt werden.
- Langfristige Vision für Evolution: Sie erwarten schnelle Iterationen bei Agentenarchitekturen und müssen mit neuen Kommunikationsprotokollen, Scheduling-Algorithmen oder Interaktionsmustern experimentieren.
- Starkes Engineering-Team: Sie haben ein fähiges Team mit Fachwissen in verteilten Systemen, Nachrichtenwarteschlangen, Datenbanken und API-Design, das bereit ist, den kompletten Stack zu übernehmen.
- Vendor Lock-in um jeden Preis vermeiden: Sie möchten die vollständige Kontrolle über Ihren Technologiestack und die zukünftige Richtung.
Umsetzbare Erkenntnisse
- Definieren Sie Ihr "Warum": Bevor Sie überhaupt nach Werkzeugen suchen, artikulieren Sie klar warum Sie eine Agenten-Orchestrierungsebene benötigen. Welche spezifischen Probleme lösen Sie? Welchen geschäftlichen Wert wird es liefern?
- Kartieren Sie Ihre Agenten-Workflows: Werden Sie detailliert. Zeichnen Sie Ihre komplexesten envisioned Agenten-Workflows auf. Wo sind die Entscheidungspunkte? Welche externen Systeme müssen beteiligt werden? Wie übergeben Agenten Aufgaben? Das wird schnell zeigen, ob eine Standardlösung das bewältigen kann.
- Bewerten Sie die Fähigkeiten Ihres Teams: Seien Sie brutal ehrlich. Verfügen Sie über das Ingenieurwissen und die Kapazität, um ein verteiltes System aufzubauen und zu warten? Oder wird es zu einem Engpass und einer Quelle technischer Schulden?
- Berücksichtigen Sie die Gesamtkosten des Eigentums (TCO): Es geht dabei nicht nur um Abonnementgebühren im Vergleich zu Gehältern. Berücksichtigen Sie die Anpassungskosten für gekaufte Plattformen (Beratung, externe Verknüpfungsprogrammierung) sowie laufende Wartungs-, Sicherheits- und Skalierungskosten für gebaute Systeme.
- Einfach starten, clever skalieren: Wenn Sie sich entscheiden zu bauen, versuchen Sie nicht, den ultimativen Orchestrator am Tag eins zu bauen. Beginnen Sie mit den Kernfunktionen, die Sie benötigen, bringen Sie es zum Laufen und iterieren Sie. Wenn Sie kaufen, verstehen Sie die Grenzen der Anpassung, bevor Sie sich festlegen.
Die Welt der Agentenentwicklung entwickelt sich weiterhin rasant. Was heute eine "Build"-Entscheidung sein mag, könnte morgen eine "Buy"-Entscheidung werden, wenn sich Plattformen weiterentwickeln. Aber für jetzt, im März 2026, drängt die Komplexität realer Agentensysteme oft auf mehr Kontrolle. Wählen Sie weise, denn Ihre Orchestrierungsebene wird das Rückgrat Ihres Agenten-Ökosystems sein.
Das war's für heute. Machen Sie weiter mit dem Bauen, dem Experimentieren, und ich sehe Sie das nächste Mal auf agntdev.com.
🕒 Published: