🤩 Unleach connectors - From Tools to Language

on April 13, 2026

Introduction

Automation has reached a paradox.

We have never had so many tools:

  • connectors
  • workflows
  • orchestration engines
  • AI agents

Yet, something fundamental is still missing.

We don’t have a language.

This article revisits a previous experiment around Composio and MCP, and introduces a new direction:

Automation should not be a workflow. It should be a language.

Revisiting the First Approach

A year ago, an implementation was proposed to automate Gmail and Google Calendar using PHP agents, MCP, and Composio.

The system relied on:

  • tool exposure via MCP
  • connector orchestration
  • agent-driven execution

While functional, this approach had structural limitations:

  • tight coupling to specific providers (Composio)
  • workflow-centric design
  • lack of composability
  • no abstraction of intent

This led to the archival of the original project: → composio-mcp

The problem was not the tools.

The problem was the model.

The Limits of Connectors

Modern automation platforms provide access to hundreds of integrations:

  • Composio
  • Symfony Mate
  • Kestra
  • n8n

Each exposes capabilities:

  • send email
  • fetch data
  • trigger workflows
  • call APIs

However, these systems share a common limitation:

They define how to connect, not how to compute.

They operate as:

  • pipelines
  • graphs
  • sequences

But not as a formal system.

Back to First Principles

To redefine automation, we revisit two foundational models:

Church - The Language

Lambda calculus defines computation as:

  • function abstraction
  • function application

Example:

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

Key properties:

  • functions are first-class
  • no mutable state
  • computation = evaluation

Turing - The Execution

The Turing machine defines:

  • how computation is executed
  • how state evolves
  • how instructions are processed

Equivalence

The Church–Turing thesis states:

Any computation expressed as a Turing machine can be expressed in lambda calculus.

A New Model for Automation

Applying this equivalence:

| Concept | Role | | ---------- | ------------------- | | Lambda | Language (intent) | | Flow | Execution (runtime) | | Connectors | External primitives |

This leads to a new architecture:

Intent → Lambda → Execution → Connector

Connect Flow

A new system, connect-flow, implements this model.

It introduces three core domains:

1. LambdaCapability

Represents:

  • a computation
  • a composable expression
  • a formal structure

Example:

λfetchemails.λuserId.fetchemails(userId)

2. Execution (Flow)

Execution is delegated to:

  • an orchestration engine
  • supporting async and parallel computation

Flow acts as the Turing machine of the system.

3. LanguageCapability

A higher-level abstraction:

  • transforms natural language into lambda expressions
  • uses a local LLM (Ollama + Mistral)
  • preserves privacy (RGPD-compliant)

From Tools to Primitives

In this model:

  • Composio
  • Symfony Mate
  • n8n
  • Kestra

are no longer central systems.

They become:

execution backends

Each tool becomes a primitive callable within lambda.

Practical Example

Lambda Execution

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

This defines:

  • a function taking fetchemails
  • then userId
  • applying fetchemails(userId)

Natural Language → Lambda

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

Produces:

λfetchemails.fetchemails()

Why This Matters

Traditional automation:

Workflow → Tools → Execution

This model:

Intent → Lambda → Flow → Connector

Key Differences

| Traditional | Lambda-based | | ------------------ | ------------------- | | Static workflows | Dynamic composition | | Tool-driven | Language-driven | | Provider-dependent | Provider-agnostic | | Hard to scale | Composable |

Extending the Language

Future iterations will introduce:

  • data mappers
  • conditional logic
  • loops
  • HTTP primitives
  • process execution

Example:

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

Relationship with Functional Programming

This approach builds upon:

  • lambda calculus
  • combinatory logic
  • functional composition

As previously explored in:

→ Lambda interpreter in PHP → Y combinator implementations → Flow execution model

Toward a Universal Execution Layer

This architecture suggests a new category of systems:

Capability Composition Engines

Where:

  • connectors are interchangeable
  • execution is abstracted
  • intent is formalized

Projet sources

You can find sources of the project here : https://github.com/matyo91/connect-flow

Conclusion

Automation has evolved from scripts to workflows.

The next step is clear:

From workflows to language.

By combining:

  • Lambda (Church)
  • Flow (Turing)
  • Connectors (primitives)

we obtain a system that is:

  • composable
  • extensible
  • formally grounded

Final Thought

Automation is not a sequence of steps. It is a computation.

And computation deserves a language.

Music credit

The music that help me deeply write the article, in remembering of times past at https://www.bigyouth.fr : ODESZA - The Last Goodbye (feat. Bettye LaVette) - Official Visualizer

Resources

Site

Network

Social

Darkwood 2026, all rights reserved