Architektur zur Integration von Agenten-Tools

Problem

Der Agent konnte über eine Aufgabe nachdenken. Er konnte Fähigkeiten, die in anderen Systemen schon existierten, nicht zuverlässig aufrufen. Teams glichen das mit einem Flickwerk aus HR- und Operations-Datentools aus, jedes mit eigenem Auth-Modell, Vertrag und eigener Rechnung. Automatisierungen waren brüchig. Abfragen waren doppelt. Die Rechnung wuchs, während der Agent von der Arbeit isoliert blieb, die er tun sollte.

Vorgaben

Mehrere Produktionsumgebungen, jede mit eigener Sicherheitsgrenze. Bestehende Dienste mussten die Quelle der Wahrheit bleiben; ein Rewrite war außerhalb des Umfangs. Kostendruck bedeutete, dass jede Integration sich gegen das Tool rechtfertigen musste, das sie ersetzen würde. Die Schicht musste allgemein sein: ein System hinzuzufügen sollte wie das Registrieren eines Tools aussehen, nicht wie ein neues Arbeitsprogramm.

Architektur

Eine verallgemeinerte Tool-Integrationsschicht nach dem Muster des Model Context Protocol saß zwischen der internen Agent-Runtime und den externen Diensten. Skills beschrieben, was der Agent tun durfte. Tools beschrieben, wie diese Skills auf bestehende APIs abgebildet wurden. Ein API-Gateway vermittelte Identität, Rate-Limits und die Isolation der Umgebungen. Kafka-Pipelines bewegten Änderungsdaten in einen Sync-Pfad. Automatisiertes CI/CD beförderte nur geprüfte, umgebungsgebundene Konfiguration. Verteilte Infrastruktur ersetzte das frühere Muster von einem Tool pro Team.

Rolle

Als leitender Ingenieur habe ich die Taxonomie von Skills und Tools definiert, die MCP-Integrationsverträge und die Form der Gateways und Pipelines. Ich habe den Promotion-Pfad verantwortet, der den Sync über mehrere Umgebungen vor einem manuellen Prozess bewahrte, und ich habe die verteilte Infrastruktur entworfen, mit der das Team die fragmentierten Datentools ablösen konnte.

Ergebnisse

• 35–45 % weniger operative Kosten durch das Ablösen fragmentierter HR- und Operations-Datentools.
• Eine einzige Integrationsfläche für nachfolgende Systeme, sodass neue Fähigkeiten keinen neuen Anbieter-Stack brauchten.
• Umgebungsgebundene Promotion: Konfiguration lief durch CI/CD statt durch Copy-and-paste zwischen Produktionen.

Stack