Sehr gut, alle zusammen. Leo Grant hier, zurück in den digitalen Gräben auf agntdev.com. Heute möchte ich etwas ansprechen, das mich beschäftigt, etwas, das ich in Forum um Forum, Discord um Discord gesehen habe: die Diskussion “bauen oder kaufen” wenn es um die Orchestrierung interner Agenten geht. Genauer gesagt, konzentriere ich mich auf die Orchestrierungsschicht selbst, nicht auf die Agenten. Wir befinden uns im Jahr 2026, und der Bereich der Agenten entwickelt sich rasant. Wir sind über das Theoretische hinaus. Wir bauen echte produktionsbereite Systeme.
Ich bin seit sechs Monaten tief darin verwickelt, zuerst bei einem Kunden, wo wir eine Lösung gekauft haben, und dann, vor kurzem, bei einem anderen Kunden, wo wir aktiv eine Lösung von Grund auf bauen. Der Kontrast war frappierend, erhellend und ehrlich gesagt, manchmal etwas frustrierend. Lassen Sie uns das entwirren, denn ich denke, viele von Ihnen kämpfen mit dieser speziellen Entscheidung.
Das “Kaufen”-Argument: Wann der Standard Sinn macht (und wann nicht)
Mein erster Kunde, nennen wir sie “InnovateCo”, hatte eine klare Vorgabe: ein Agentensystem schnell aufzubauen. Es war ein mittelständisches Unternehmen, kein Technologieriese, und ihr internes Entwicklungsteam war bereits stark ausgelastet. Ihr Kerngeschäft war nicht die Entwicklung von Agenten; es war die Logistik. Daher schien der Kauf einer einsatzbereiten Orchestrierungsplattform die offensichtliche Wahl zu sein.
Wir haben einige Optionen evaluiert, uns für einen der prominentesten Anbieter entschieden – ich werde keine Namen nennen, aber Sie können wahrscheinlich einige erraten – und wir haben mit unserer Arbeit begonnen. Die anfängliche Konfiguration war überraschend reibungslos. Die Plattform prahlte mit einer eleganten Benutzeroberfläche, Drag-and-Drop-Workflows und dem Versprechen von “einsatzbereiten Integrationen”.
Die Vorteile: Schnelle Markteinführung und niedrige Anfangskosten
- Schnelle Bereitstellung: Wir hatten unsere ersten Agenten in Kommunikation mit dem Orchestrator und führten grundlegende Aufgaben innerhalb weniger Wochen aus. Das war ein großer Sieg für die Stakeholder, die einfach nur sehen wollten, dass etwas funktioniert.
- Verwaltete Infrastruktur: Keine Sorge um die Skalierung von Datenbanken, Warteschlangen oder API-Gateways. 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 Vielzahl von Funktionen: Überwachung, Protokollierung, Versionierung, Zugriffskontrolle. Es schien umfassend zu sein.
InnovateCo war zufrieden. Für eine Weile. Die anfängliche Aufregung war spürbar. Wir hatten ein Dashboard, Metriken und konnten neue Agenten-Workflows in wenigen Klicks erstellen. Man hatte das Gefühl, wirklich an die Grenzen zu gehen.
Die Nachteile: Der “Vendor Lock-in”-Blues und die Kopfschmerzen der Anpassung
Dann kam das Unvermeidliche. Als unsere Anwendungsfälle für Agenten komplexer wurden, begannen wir, auf Hindernisse zu stoßen. InnovateCo benötigte eine spezifische benutzerdefinierte Logik für das Routing von Aufgaben basierend auf externen Echtzeit-Datenströmen – Daten, die sich nicht leicht in die vordefinierten Connectoren der Plattform integrieren ließen. Wir benötigten ein benutzerdefiniertes Fehlerhandling, das komplexe Wiederholungslogik basierend auf API-Durchsatzgrenzen beinhaltete, nicht einfach nur exponentielles Wiederholen.
Jede kleine Abweichung vom vorgesehenen Design der Plattform wurde zu einem Kampf. Wir reichten ständig Support-Tickets ein, forderten Funktionen an oder versuchten, unsere Anforderungen an ihr bestehendes Framework anzupassen. Die “einsatzbereiten Integrationen” erwiesen sich als weniger flexibel als erwartet. Wir fanden uns ständig dabei, eine Menge “Bridge-Code” extern zu schreiben, um unsere Agenten an den Orchestrator anzupassen, und dann noch mehr Bridge-Code, um den Orchestrator an unsere internen Systeme anzupassen.
Mein persönlicher Frustrationspegel stieg, als wir einen sehr spezifischen und kontextuellen Agententransfermechanismus umsetzen mussten. Die Plattform hatte eine grundlegende Transferfunktion, aber sie berücksichtigte nicht die nuancierte Zustandsverwaltung, die wir benötigten. Am Ende bauten wir einen völlig separaten Mikrodienst nur, um das zu handhaben, wodurch wir effektiv die vorgesehene Funktionalität des Orchestrators für diesen spezifischen Workflow umgingen.
Hier zeigte die Strategie “kaufen” ihre Risse. Der anfängliche Geschwindigkeitsgewinn wurde von der Reibung der Anpassung aufgezehrt. Wir zahlten hohe Abonnementgebühren und waren dennoch immer noch dabei, eine signifikante Menge an benutzerdefinierter Entwicklung um die Plattform herum zu machen, statt darauf. Die versprochenen Kosteneinsparungen schienen eine Illusion zu sein.
Das “Bauen”-Argument: Kontrolle (und Verantwortung) übernehmen
Kommen wir schnell zu meinem aktuellen Kunden, “PioneerTech”. Es ist ein kleineres, agiles Start-up, das tief in Forschung und Entwicklung von KI verwurzelt ist. Ihr Flaggschiffprodukt besteht aus intelligenten Agenten. Für sie war die Entscheidung, ihre eigene Orchestrierungsschicht zu bauen, praktisch eine offensichtliche Schlussfolgerung. Sie benötigen ultimative Flexibilität, granularen Kontrolle und die Fähigkeit, schnell über experimentelle Agentenarchitekturen iterieren zu können.
Meine Rolle hier ist es, bei der Architektur und dem Bau dieses internen Orchestrierungssystems zu helfen. Es war eine völlig andere Erfahrung.
Die Vorteile: Flexibilität ohne Einschränkungen und wahres Eigentum
- Maßgeschneidert für Ihre Bedürfnisse: 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 Architektur kontrollieren, können wir ihre bestehenden internen Tools, Datenbanken und KI-Modelle tief integrieren, ohne Impedanzabweichungen.
- Kein Vendor Lock-in: Das ist ein wichtiger Punkt. Wir sind nicht an die Roadmap, Preismodell oder architektonischen Entscheidungen eines Anbieters gebunden. Wir besitzen das geistige Eigentum und das Schicksal unseres Systems.
- Optimierte Leistung: Wir können für ihre spezifischen Workloads optimieren, indem wir die richtigen Datenbanken, Warteschlangen und Rechenressourcen wählen, ohne durch die Entscheidungen einer generischen Plattform eingeschränkt zu sein.
Ein aktuelles Beispiel: PioneerTech benötigte ein hochdynamisches Aufgabenroutingsystem, das auf der Echtzeitkapazität von Agenten, den Fähigkeiten und den historischen Leistungen basierte. Wir haben einen benutzerdefinierten Scheduler entworfen, der Daten von mehreren internen Diensten extrahiert, einen gewichteten Bewertungsalgorithmus anwendet und die Aufgaben dem am besten geeigneten Agenten zuweist. Eine solche komplexe und maßgeschneiderte Logik wäre ein Albtraum gewesen, wenn sie auf einer einsatzbereiten Plattform implementiert worden wäre.
Hier ist ein vereinfachter Auszug, wie wir eine Aufgabe in unserem System definieren könnten, unter Verwendung eines grundlegenden Pydantic-Modells für die Validierung und einer Warteschlange für die 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="Priorität der Aufgabe (1-10)")
callback_url: str | None = Field(None, description="URL für den Callback der abgeschlossenen 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()
# Beispielanwendung:
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)
Dieser Steuerungsgrad, vom Datenmodell bis zum Nachrichtenbroker, ermöglicht es uns, unglaublich effiziente und spezialisierte Systeme zu erstellen. Wir kämpfen nicht gegen eine generische Abstraktion; wir formen das genaue Tool, das wir benötigen.
Nachteile: Bedeutende Anfangsinvestition und fortlaufende Wartung
Natürlich ist das kein kostenloses Mittagessen. Der Aufbau von Grund auf bringt eine eigene Reihe von Herausforderungen mit sich:
- Höhere Anfangskosten: Wir investieren eine signifikante Anzahl an Ingenieurstunden von Anfang an. Das ist keine schnelle Lösung.
- Erhöhte Verantwortung: Wir sind für alles verantwortlich – Infrastruktur, Sicherheit, Skalierbarkeit, Bugs. Es gibt keine Support-Hotline des Anbieters, die wir anrufen können.
- Funktionale Parität: Wir müssen entscheiden, welche “Standardfunktionen” (wie detaillierte Dashboards, Protokollverfolgung, erweiterte Zugriffskontrolle) ausreichend kritisch sind, um sie selbst zu erstellen, und von welchen wir verzichten oder sie einfacher implementieren können.
- Time-to-Market (zu Beginn): Ein voll funktionsfähiges, produktionsbereites System zu erhalten, dauert länger als die Bereitstellung einer SaaS-Lösung.
Mein aktuelles Team verbringt einen Großteil seiner Zeit mit Infrastruktur als Code, mit der Konfiguration von Überwachung und der Gewährleistung einer soliden Fehlerverwaltung. Wir müssen von Anfang an über Resilienz nachdenken. Hier ist beispielsweise ein konzeptioneller Entwurf eines Mechanismus zur Registrierung von Agenten und zur Lebenszeichenüberwachung, den wir implementieren könnten:
# Vereinfachtes konzeptionelles Beispiel zur Registrierung von Agenten und Heartbeat
# In einem echten System würde dies eine Datenbank, eine robuste API und angemessene 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 den 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 von Agent {agent_id} empfangen")
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"]):
# Einfache Frischeprüfung (z.B. letzter Heartbeat in den letzten 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 kennzeichnen
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--- Anfangs 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) # Warte 10 Sekunden
registry.send_heartbeat(agent_a_id)
print(f"\nAktive 'data_analysis'-Agenten nach dem Heartbeat: {registry.get_active_agents('data_analysis')}")
# Simuliere Agent B offline (keine weiteren Heartbeats)
print("\n--- Agent B geht offline ---")
time.sleep(70) # Warte länger als der Heartbeat-Schwellenwert
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 aufgebaut werden müssen, wenn man den "Build"-Weg einschlägt. Jedes Element erfordert sorgfältige Planung, Tests und Bereitstellung. Es ist ein Marathon, kein Sprint.
Das Urteil: Es kommt darauf an (aber ernsthaft)
Nachdem ich auf beiden Seiten dieser Barriere war, ist mein Fazit nicht einfach "das Bauen gewinnt immer" oder "das Kaufen gewinnt immer". Es kommt wirklich auf Ihren spezifischen Kontext an.
So habe ich angefangen, meinen Kunden zu raten:
Wann es sinnvoll ist, stark eine Orchestrierungsplattform zu "kaufen":
- Ihr Kerngeschäft sind nicht die Agenten: Wenn der Wertvorschlag Ihres Unternehmens nicht direkt mit Agententechnologie verbunden ist und Agenten eher eine unterstützende Funktion darstellen, kann kaufen sinnvoll sein.
- Begrenzte Entwicklungsressourcen: Wenn Ihr Ingenieurteam klein, bereits beschäftigt oder nicht über spezifische Expertise in verteilten Systemen und Agentenarchitekturen verfügt.
- Standardisierte Workflows: Ihre Anwendungsfälle für Agenten sind relativ einfach, passen gut in gängige Modelle (z.B. einfache Aufgabenverteilung, grundlegende sequenzielle Workflows) und erfordern keine hochspezialisierte Logik.
- Schnelligkeit ist entscheidend (anfangs): Sie müssen schnell etwas in Betrieb nehmen, um ein Konzept zu beweisen oder eine unmittelbare geschäftliche Anforderung zu erfüllen, auch wenn dies bedeutet, später einige Kompromisse einzugehen.
- Budget für SaaS: Sie haben ein Betriebsbudget für wiederkehrende SaaS-Gebühren und bevorzugen Opex gegenüber Capex für Softwareentwicklung.
Wann es sinnvoll ist, stark Ihre eigene Orchestrierungsschicht zu "bauen":
- Die Agenten sind Ihr Kerngeschäft/Unterscheidungsmerkmal: Wenn Ihr Produkt Agenten ist oder Agenten einen kritischen Wettbewerbsvorteil darstellen, benötigen Sie vollständige Kontrolle.
- Hochgradig angepasste oder komplexe Workflows: Ihre Interaktionen zwischen Agenten beinhalten komplexes Zustandsmanagement, dynamisches Routing basierend auf Echtzeitdaten von extern, komplexe Entscheidungsbäume oder Multi-Agenten-Zusammenarbeit, die über einfache sequenzielle oder parallele Ausführung hinausgeht.
- Tiefe Integrationsbedürfnisse: Sie müssen eng mit einzigartigen internen Systemen, proprietären Datenquellen oder spezialisierten KI-Modellen integrieren, die von handelsüblichen Plattformen nicht nativ unterstützt werden.
- Langfristige Vision für Evolution: Sie planen schnelle Iterationen über Agentenarchitekturen und benötigen die Möglichkeit, mit neuen Kommunikationsprotokollen, Planungsalgorithmen oder Interaktionsschemata zu experimentieren.
- Starkes Ingenieurteam: Sie haben ein kompetentes Team mit Expertise in verteilten Systemen, Nachrichtenwarteschlangen, Datenbanken und API-Design, das bereit ist, den gesamten Stack zu verwalten.
- Vermeiden Sie Anbieter-Lock-in um jeden Preis: Sie möchten vollständige Kontrolle über Ihren Technologiestack und Ihre zukünftige Ausrichtung.
Praktische Schlussfolgerungen
- Definieren Sie Ihr "Warum" : Bevor Sie überhaupt nach den Tools schauen, formulieren Sie klar warum Sie eine Orchestrierungsschicht für Agenten benötigen. Welche spezifischen Probleme lösen Sie? Welchen geschäftlichen Wert wird das bringen?
- Kartografieren Sie Ihre Agenten-Workflows : Seien Sie detailliert. Zeichnen Sie Ihre komplexesten geplanten Agenten-Workflows auf. Wo sind die Entscheidungspunkte? Welche externen Systeme müssen einbezogen werden? Wie übergeben die Agenten Aufgaben? Das wird schnell zeigen, ob eine fertige Lösung damit umgehen kann.
- Bewerten Sie die Fähigkeiten Ihres Teams : Seien Sie brutal ehrlich. Haben Sie das Ingenieurtalent und die Bandbreite, um ein verteiltes System zu bauen und zu warten? Oder wird das zu einem Engpass und einer Quelle technischer Schulden?
- Berücksichtigen Sie die Gesamtkosten des Eigentums (TCO) : Es geht nicht nur um die Abonnementgebühren im Vergleich zu Gehältern. Berücksichtigen Sie die Anpassungskosten für gekaufte Plattformen (Beratung, externe Ergänzungscodes) sowie die Kosten für Wartung, Sicherheit und Skalierung von selbstgebauten Systemen.
- Fangen Sie einfach an, entwickeln Sie intelligent : Wenn Sie sich entscheiden zu bauen, versuchen Sie nicht, am ersten Tag den ultimativen Orchestrator zu erschaffen. Beginnen Sie mit der Basisfunktionalität, die Sie benötigen, bringen Sie sie 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 schnell. Was heute eine "Build"-Entscheidung sein könnte, könnte morgen eine "Buy"-Entscheidung werden, während die Plattformen reifen. Aber fürs Erste, im März 2026, treibt die Komplexität der realen Agentensysteme uns oft zu einem erhöhten Kontrollbedarf. Wählen Sie weise, denn Ihre Orchestrierungsschicht wird das Fundament Ihres Agenten-Ökosystems sein.
Das ist alles für heute. Fahren Sie fort mit dem Bauen, experimentieren Sie weiter, und ich werde Sie das nächste Mal auf agntdev.com treffen.
🕒 Published: