DEV Community

Mathieu Ledru
Mathieu Ledru

Posted on

🤩 Unleach connectors - From Tools to Language

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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)
Enter fullscreen mode Exit fullscreen mode

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]"
Enter fullscreen mode Exit fullscreen mode

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'"
Enter fullscreen mode Exit fullscreen mode

Produces:

λfetchemails.fetchemails()
Enter fullscreen mode Exit fullscreen mode

Why This Matters

Traditional automation:

Workflow → Tools → Execution
Enter fullscreen mode Exit fullscreen mode

This model:

Intent → Lambda → Flow → Connector
Enter fullscreen mode Exit fullscreen mode

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
)
Enter fullscreen mode Exit fullscreen mode

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.

Resources

Top comments (0)