🤩 Unleach-Konnektoren – Von Werkzeugen zur Sprache

vom 13. April 2026

Einführung

Die Automatisierung ist an einem Paradoxon angelangt.

Wir hatten noch nie so viele Werkzeuge:

• Steckverbinder
• Arbeitsabläufe
• Orchestrierungs-Engines
• KI-Agenten

Doch etwas Grundlegendes fehlt noch immer.

Wir haben keine Sprache.

Dieser Artikel greift ein früheres Experiment mit Composio und MCP erneut auf und stellt eine neue Richtung vor:

Automatisierung sollte kein Arbeitsablauf sein, sondern eine Sprache.

Eine erneute Betrachtung des ersten Ansatzes

Vor einem Jahr wurde eine Implementierung vorgeschlagen, um Gmail und Google Kalender mithilfe von PHP-Agenten, MCP und Composio zu automatisieren.

Das System beruhte auf Folgendem:

• Werkzeugexposition über MCP
• Konnektorchestrierung
• agentengesteuerte Ausführung

Dieser Ansatz funktionierte zwar, wies aber strukturelle Einschränkungen auf:

• enge Anbindung an bestimmte Anbieter (Composio)
• Workflow-zentriertes Design
• Mangelnde Kompositionsfähigkeit
• keine Abstraktion der Absicht

Dies führte zur Archivierung des ursprünglichen Projekts: → composio-mcp

Das Problem waren nicht die Werkzeuge.

Das Problem war das Modell.

Die Grenzen von Steckverbindern

Moderne Automatisierungsplattformen bieten Zugriff auf Hunderte von Integrationen:

• Komposition
• Symfony Mate
• Kestra
• n8n

Jedes dieser Systeme bietet folgende Möglichkeiten:

• E-Mail senden
• Daten abrufen
• Workflows auslösen
• APIs aufrufen

Diese Systeme weisen jedoch eine gemeinsame Einschränkung auf:

Sie definieren wie die Verbindung hergestellt wird, nicht wie die Berechnung erfolgt.

Sie funktionieren wie folgt:

• Pipelines
• Grafiken
• Sequenzen

Aber nicht als formales System.

Zurück zu den Grundlagen

Um Automatisierung neu zu definieren, betrachten wir zwei grundlegende Modelle erneut:

Kirche - Die Sprache

Der Lambda-Kalkül definiert Berechnungen wie folgt:

• Funktionsabstraktion
• Funktionsanwendung

Beispiel:

λx.x + 1
(λx.x + 1)(5) = 6

Wichtigste Eigenschaften:

• Funktionen sind erstklassig
• kein veränderlicher Zustand
• Berechnung = Auswertung

Turing - Die Hinrichtung

Die Turingmaschine definiert:

• wie die Berechnung ausgeführt wird
• wie sich der Staat entwickelt
• wie Anweisungen verarbeitet werden

Äquivalenz

Die Church-Turing-These besagt:

Jede als Turingmaschine ausgedrückte Berechnung kann im Lambda-Kalkül ausgedrückt werden.

Ein neues Modell für die Automatisierung

Anwendung dieser Äquivalenz:

Dies führt zu einer neuen Architektur:

Intent → Lambda → Execution → Connector

Connect Flow

Dieses Modell wird durch ein neues System namens connect-flow umgesetzt.

Es führt drei Kernbereiche ein:

1. Lambda-Funktion

Stellt dar:

• eine Berechnung
• ein zusammensetzbarer Ausdruck
• eine formale Struktur

Beispiel:

λfetchemails.λuserId.fetchemails(userId)

2. Ausführung (Ablauf)

Die Ausführung wird delegiert an:

• eine Orchestrierungs-Engine
• Unterstützung von asynchroner und paralleler Berechnung

Flow fungiert als Turingmaschine des Systems.

3. Sprachfähigkeit

Eine Abstraktion auf höherer Ebene:

• wandelt natürliche Sprache in Lambda-Ausdrücke um
• verwendet ein lokales LLM (Ollama + Mistral)
• wahrt die Privatsphäre (DSGVO-konform)

Von Werkzeugen zu Primitiven

In diesem Modell:

• Komposition
• Symfony Mate
• n8n
• Kestra

sind keine zentralen Systeme mehr.

Sie werden zu:

Ausführungs-Backends

Jedes Werkzeug wird zu einer primitiven aufrufbaren Funktion innerhalb von Lambda.

Praktisches Beispiel

Lambda-Ausführung

bin/console connect-flow:lambda:run \
"λfetchemails.λuserId.fetchemails(userId)" \
--args "[5]"

Dies definiert:

• eine Funktion, die fetchemails entgegennimmt
• dann userId
• Anwendung von fetchemails(userId)

Natürliche Sprache → Lambda

bin/console -vvv connect-flow:language:to-lambda \
"fetch emails you have the tool 'fetchemails'"

Produziert:

λfetchemails.fetchemails()

Warum das wichtig ist

Traditionelle Automatisierung:

Workflow → Tools → Execution

Dieses Modell:

Intent → Lambda → Flow → Connector

Wichtigste Unterschiede

Erweiterung der Sprache

Zukünftige Versionen werden Folgendes einführen:

• Datenmapper
• Bedingte Logik
• Schleifen
• HTTP-Primitive
• Prozessausführung

Beispiel:

compose(
  fetch_emails,
  filter_important,
  map(summary),
  send_email
)

Beziehung zur funktionalen Programmierung

Dieser Ansatz baut auf Folgendem auf:

• Lambda-Kalkül
• Kombinatorische Logik
• funktionelle Zusammensetzung

Wie bereits zuvor erläutert wurde in:

→ Lambda-Interpreter in PHP → Y-Kombinator-Implementierungen → Ablaufausführungsmodell

Auf dem Weg zu einer universellen Ausführungsschicht

Diese Architektur legt eine neue Kategorie von Systemen nahe:

Capability Composition Engines

Wo:

• Die Anschlüsse sind austauschbar
• Die Ausführung ist abstrahiert
• Die Absicht wird formalisiert

Projektquellen

Die Projektquellen finden Sie hier: https://github.com/matyo91/connect-flow

Abschluss

Die Automatisierung hat sich von Skripten zu Arbeitsabläufen weiterentwickelt.

Der nächste Schritt ist klar:

Von Arbeitsabläufen bis hin zur Sprache.

Durch die Kombination von:

• Lambda (Kirche)
• Fluss (Turing)
• Konnektoren (Primitive)

Wir erhalten ein System, das wie folgt lautet:

• kompositionsfähig
• erweiterbar
• formal geerdet

Abschließender Gedanke

Automatisierung ist keine Abfolge von Schritten. Es handelt sich um eine Berechnung.

Und die Informatik verdient eine eigene Sprache.

Music credit

Die Musik, die mir dabei geholfen hat, den Artikel tiefgründig zu schreiben und mich an vergangene Zeiten zu erinnern, unter https://www.bigyouth.fr: ODESZA – The Last Goodbye (feat. Bettye LaVette) – Offizieller Visualizer

Ressourcen

• https://blog.darkwood.com/article/automating-gmail-and-google-calendar-with-php-agents
• https://github.com/matyo91/composio-mcp
• https://composio.dev/
• https://symfony.com/doc/current/ai/components/mate.html
• https://kestra.io/plugins
• https://n8n.io/integrations/
• https://navi.darkwood.com/
• https://flow.darkwood.com/