DEV Community: Mathieu Ledru

✨ Transformative design: no longer designing uses, but metamorphoses

Mathieu Ledru — Fri, 01 May 2026 06:39:23 +0000

On April 30th, at Le Laptop in Paris, an event took place that broke away from the beaten path of classic Product Design: “Transformative Design: Don't just create uses, transform users”, presented by David Jeanne and organized by Jordan Thévenot.

In a room filled with around forty participants—designers, developers, and product specialists—the promise was clear: to question the current limitations of UX and propose a new direction. A direction where design no longer simply optimizes interfaces, but seeks to produce profound transformations for users.

From Experience to Transformation

Product design has long sought to make things simpler.

Less friction.
Less effort.
Less complexity.
Less waiting time.

It's a powerful promise. But it also has a limitation: by smoothing everything over, we sometimes end up smoothing over meaning itself.

David Jeanne starts from an idea from The Experience Economy: the economy evolves in stages.

We started by selling raw materials.
Then products.
Then services.
Then experiments.

But when the experience itself becomes commonplace, what remains to differentiate oneself?

The proposed answer is powerful: transformation.

It's no longer just about selling a pleasant interface or a smooth user journey. It's about designing an experience that helps a person become someone else.

For example :

to go from “I am not sporty” to “I take care of my body”;
moving from “I am at the mercy of my money” to “I am building my future”;
to move from “I am just a resource” to “I am an active participant in the project”.

This is where design becomes transformative.

Designing a passage, not just a route

Classical design often works with a persona: their needs, their pains, their motivations.

Transformative design adds a deeper question:

How do we want to help this person to grow?

This completely changes the nature of the work.

We no longer just design a user journey.
We design a passage.

A passage between a current self and a possible self.

This transition can follow the structure of initiation rites: a preparation phase, a turning point phase, and then an integration phase. The goal is not simply to create a "wow" effect, but to create an experience that leaves a lasting impression.

The role of rituals, symbols and objects

One of the most interesting aspects of the conference is the importance given to symbols.

A transformation does not happen solely through rational arguments. It also happens through forms, gestures, objects, places, words, and postures.

In the example presented, a simple, traditional meeting was transformed into a ritualistic moment. The chairs disappeared, a large strategic map was placed on the table, and the computer was put aside. The client was no longer simply someone who "gave a brief." They gradually became a strategist.

And this change in physical posture can trigger a change in mental posture.

This is a key idea: design transforms not only by what it explains, but by what it brings to life.

Preserve, amplify, help, dissolve, transform

David Jeanne presents an interesting matrix for deciding what to do with the existing elements in the experiment.

Certain elements must be preserved, as they ensure the psychological safety of the user.
Others need to be amplified, because they are already moving in the direction of the desired transformation.
Others need help when they are simply irritants to be removed.

Then come the deeper dimensions:

dissolve certain reference points;
to transform certain identity-related blockages.

This is where transformative design differs from traditional UX. It doesn't just aim to reduce problems; it seeks to identify what prevents a person from changing their perspective on themselves.

A central ethical question

Such a design obviously raises a question: how far can we go?

While design can transform, it can also manipulate.

The conference emphasizes this point: the model presented aims for empowerment, not subjugation. But this imposes a strong requirement regarding consent, protection, and intent.

Designing a transformation is not a neutral process.

This is likely one of the major topics of the coming years, especially with the massive integration of AI into digital products. Interfaces will become more adaptive, more personalized, and more persuasive. The line between guidance and manipulation will become increasingly blurred.

My takeaway for Darkwood

This conference resonates strongly with the topics I explore around Darkwood, Flow, and automation.

Today, many tools aim to save time. But save time for what purpose?

A good product shouldn't just automate a task. It should help its user change their approach.

To go from consumer to creator.
To move from executor to architect.
To go from spectator to player.
To go from being overwhelmed to being able to orchestrate their own systems.

This is probably where part of the value of future products lies: not in the total elimination of effort, but in the design of efforts that transform.

Conclusion

Transformative design encourages us to move beyond a purely utilitarian view of the product.

A product can be more than just a tool.
It can become a ritual.
A passage.
A mirror.
A trigger.

The question is therefore no longer simply:

“What use are we creating?”

But rather:

“What kind of person are we helping to emerge?”

Going further

David Jeanne has launched a campaign for his book dedicated to transformative design, which delves deeper into these concepts with concrete and operational methods.

👉 https://fr.ulule.com/design-transformatif-livre/

⚙️ Hermes X Paperclip - Building a Governed Multi-Agent Architecture with Symfony AI, Flow, and Navi

Mathieu Ledru — Thu, 30 Apr 2026 12:19:19 +0000

Multi-agent systems are everywhere:

orchestrated via Docker: https://blog.darkwood.com/fr/article/ai-tinkerers-paris-agentic-workflows-avec-docker-vers-des-systemes-autonomes-securises-et-orchestres
Simulated using frameworks like Paperclip + Hermes: https://www.youtube.com/watch?v=j7cKjTMjNLE
or integrated directly into products: https://docs.langchain.com/oss/python/langchain/multi-agent

But in most cases, they remain:

❌ collections of prompts

❌ without governance

❌ without traceability

❌ without clear responsibility

In this article, we will build an alternative, not as a fictional startup, but as a concrete example:

NoLife Agency - a digital agency entirely driven by a governed multi-agent architecture.

a digital agency that produces client websites with specialized roles.

🏢 NoLife Agency - a complete organization

Unlike simplistic demos, NoLife Agency replicates a real organization:

Direction

CEO
CTO
Governance Director Manager

Client & Delivery

Account Manager
Product Owner
Delivery Manager

Production

Architect
Developer
UX Designer
UI Designer Graphic Designer
Motion Designer

Growth

SEO / GEO
Marketing
Sales
Web Analytics

Support & Reliability

QA
DevOps
Security Officer
Data Analyst

Internal Organization

Experience Officer
Office Manager
Happiness Chief Officer
Nolife Resource

👉 Here, each role can be played by an agent.

⚠️ The trap of multi-agent architectures

What many are building:

Prompt → LLM → résultat

The result is:

*no guarantee

no control
no auditability
no contract
no governance
no trace
no trade-in
no clear responsibility

✅ The NoLife Agency Model

We introduce a strict separation:

organization (Paperclip) → who does what
specialization (Hermes) → how to think
orchestration (Flow) → when to execute
traceability (Navi) → observe and audit
intelligence (Symfony AI) → produce content

🧱 Technical architecture

The application is based on a ports & adapters architecture.

Main Ports

NoLife Agency uses ports and adapters to ensure that orchestration and governance remain decoupled from vendor/runtime specifics.

AI → AiAgentClient
Workflow → FlowWorkflowClient
Trace → NaviTraceClient
Media → MediaGenerationClient

👉 Each external dependency is isolated.

AgentRunner is the single boundary for execution and governance. Adapters provide functionality, but they do not enforce policy.

flowchart LR
demoCommand[DemoClientWebsiteCommand] --> workflowLoader[WorkflowDefinitionLoader]
workflowLoader --> workflowValidator[WorkflowDefinitionValidator]
workflowValidator --> flowPort[FlowWorkflowClient]
flowPort --> agentRunner[AgentRunner]
agentRunner --> aiPort[AiAgentClient]
agentRunner --> naviPort[NaviTraceClient]
agentRunner --> mediaPort[MediaGenerationClient]
agentRunner --> auditJsonl[Audit JSONL]
agentRunner --> runArtifacts[Run Artifacts]

Symfony AI
  ↓
Agent Contracts + Registry
  ↓
AgentRunner + Governance
  ↓
Flow Workflow Runner
  ↓
Navi Trace Client
  ↓
Operational Reports

🧠 Key principle

Agents are not dependent on tools. They are dependent on contracts.

Result :

testability
interchangeability
robustness

⚙️ The heart of the system: AgentRunner

AgentRunner is the central point:

execution
governance
audit
trace

👉 No agent can circumvent this point.

Main guarantees:

checks of the pre-flight and post-flight policy
Application of approval for high-risk states/final delivery
Workflow status security checks
confining the artifact path to the execution directory
Trace the correlation between the lifecycle and audit events

🔐 Integrated IT Governance

Each action is:

validated
traced
audited

With :

JSONL logs
trace per run
validation rules
mandatory approval

👉 This is not a blind, autonomous system.

👉 It's a controlled system.

AgentRunner is the single point of application for:

policy checks
trace the life cycle
Issuance of audit events
approval requirements

Key points:

separation of responsibilities
auditability
human validation
limitation of risky actions
typed interfaces
policy tests

🔌 Phase 3 - Typed Ports

The dependencies become ports:

Symfony AI → intelligence
Flow → orchestration
Navi → traceability
media-bundle → media generation

With one critical point:

The adapters are interchangeable via configuration

Environment variables made available on the project:

NOLIFE_AI_ADAPTER (null|symfony_ai)
NOLIFE_FLOW_ADAPTER (null|darkwood_flow)
NOLIFE_NAVI_ADAPTER (null|darkwood_navi)
NOLIFE_MEDIA_ADAPTER (null|media_bundle)
NOLIFE_FLOW_ROOT
NOLIFE_NAVI_ROOT
NOLIFE_MEDIA_BUNDLE_ROOT

🧪 Use Case - Creating a Client Website

Use case:

Client: Acme SaaS
Contact: John Do
Need: landing page + blog + SEO + short launch video

Order :

php bin/console nolife:demo:client-website acme-saas

Workflow:

lead_qualified
brief_created
architecture_defined
ux_ready
content_generated
development_ready
SEO optimized
qa_validated
media_brief_created
delivery_reviewed
human_approval_required
published

👉 We are intentionally stopping before publication.

Paperclip is modeled as an organizational concept.

Hermès is modeled as a concept of specialization.

Neither is coupled as an execution service.

📂 Generated Outputs

var/nolife-agency/runs/{run_id}/

brief.json
landing-page.md
article-draft.md
seo-geo.md
media-brief.yaml
delivery-report.md
trace.json
audit.jsonl

Expected final state: human_approval_required.

🔁 Multi-agent at all levels

1. Infrastructure

Docker / isolated services

2. Organization

Paperclip → role structure

3. Intelligence

Hermes → agent specialization

4. Application

Symfony → concrete orchestration

👉 NoLife Agency is a point of convergence.

⚠️ Real problem encountered

Today :

AI adapter: null
Using Null AI adapter

👉 The system is correct… but not yet connected.

That's normal.

Because :

The ports are in place
but the actual implementations are not enabled

🧠 What this reveals

Building a multi-agent architecture is not the same as calling an LLM.

It is :

Define contracts
Isolate the dependencies
Centralize governance
Make the system testable
Gradually activate the integrations

🚀 Next step

Enable :

Symfony AI (real intelligence)
Flow (actual workflow)
Navi (actual track)

👉 Without breaking anything:

the tests
governance
the ports

🎯 Conclusion

Multi-agent architectures are not:

magical autonomous systems

These are :

governed, orchestrated, and traceable software organizations

💡 Darkwood Positioning

NoLife Agency is showing a clear direction:

The future of AI systems is not only autonomous.

It is governed.

🕵 Project source code

nolife-agency: https://github.com/matyo91/nolife-agency

🔗 Resources

Multi-Agent Architectures: https://speakerdeck.com/chr_hertel/symfony-ai-in-action-symfonylive-berlin-2026?slide=46
What is a multi-agent system? https://www.ibm.com/fr-fr/think/topics/multiagent-system
Multi-Agent Orchestration: How to Build Agent Teams That Actually Work: https://www.mindstudio.ai/blog/multi-agent-orchestration-patterns
Building AI Teams: How Docker Sandboxes and Docker Agent Transform Development: https://www.docker.com/blog/building-ai-teams-docker-sandboxes-agent/
How To Build a Multi-Agent AI System with Docker Agent: https://www.digitalocean.com/community/tutorials/how-to-build-multi-agent-ai-system-docker-agent-digitalocean
Langchain Multi-agent: https://docs.langchain.com/oss/python/langchain/multi-agent
Github NousResearch/hermes-paperclip-adapter: https://github.com/NousResearch/hermes-paperclip-adapter
Hermes Agent, how to take advantage of the OpenClaw killer: https://www.youtube.com/watch?v=j7cKjTMjNLE
The A-Team - AI Agents for SaaS Development: https://github.com/gmoigneu/the-a-team
New Tech Role Emerging: Product Managers might evolve to “Product CEOs” (Paul Teyssier | Front): https://www.youtube.com/watch?v=J3vCkWbSYI0
Openai/symphony: https://github.com/openai/symphony

🎶 Music credit

Keine Freunde bleiben (feat. Mia Julia) - Matthias Reim: https://vm.tiktok.com/ZNRgyxKkE/

@reim.matthias Wenn Freundschaft keinen Sinn mehr macht… Wer fühlt den Song? #miajulia #matthiasreim #keinefreundebleben ♬ Keine Freunde bleiben (feat. Mia Julia) - Matthias Reim

"That way I eat more!" 😂 #nico #byilhanntwitch: https://vm.tiktok.com/ZNRg5Rsh1/

@leclippeurrapide "That way I eat more!" 😂 #nico #byilhanntwitch ♬ original sound - Le Clippeur Rapide

📖 Selection of the week

DeepSeek-R1 evolving a Game of Life pattern really feels like a breakthrough: https://www.reddit.com/r/LocalLLaMA/comments/1icqzcz/deepseekr1_evolving_a_game_of_life_pattern_really/
Unbounded: A Generative Infinite Game of Character Life Simulation: https://arxiv.org/html/2410.18975v1
LLM Interactive Story Game Architecture: https://montreal.aitinkerers.org/talks/rsvp_c82tFBRQJ9A
Can an LLM Make a Video Game? https://www.codemag.com/Article/2411061/Can-an-LLM-Make-a-Video-Game
Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps
Elon Musk explains his 5-step algorithm for running companies: https://youtu.be/tdf3luOCNks?is=L6MRoXTHzvFVIUR8
when you have vibe coder in your office: https://x.com/javinpaul/status/2048425733694124211/video/1?s=46
Sunday morning science: https://x.com/Soph_astro/status/2048333972615111050/video/1?s=46
React Native at Cdiscount with Ludwig Vantours: https://www.youtube.com/watch?v=C3toh628KJE&list=PLmewDYeBL3XIx7Lnga-jO3eRjOsKQ-HW0&index=31
Getgaal - docs(mcp): re-sync with agents/global registry resolution: https://github.com/getgaal/docs/pull/16
Arize Phoenix: https://arize.com/docs/phoenix
Design a new professional future with no-code and AI: https://www.youtube.com/watch?v=p-sHtOut884
The bullshit of open-source AI models: https://www.youtube.com/watch?v=jpg9lvtqrF8
A former spy uses AI to learn everything about you (Claude Code demonstration): https://www.youtube.com/watch?v=eQXMEvGRld4
Automate your information monitoring for free and easily: https://www.youtube.com/watch?v=6n_xwJ6YAj0
A man spent 50 years teaching at MIT. The most important hour you'll watch this week. https://x.com/suryanshti777/status/2049187998936482069?s=46
The Fastest AI Infrastructure: https://www.cerebras.ai
Diablo® IV: Lord of Hatred: https://eu.shop.battle.net/fr-fr/product/diablo-iv-lord-of-hatred

🚀 Fundraising vs. Bootstrap: Two paths to building a company

Mathieu Ledru — Wed, 29 Apr 2026 07:22:46 +0000

On April 28th, Builders Factory and NextGen VC organized a discussion in Paris around a seemingly simple question: Should you raise funds or build using bootstrapping?

Face to face: Étienne Genvrin, founder of Emma, which has raised several million euros, and Wilfried Granier, founder of Superprof, which claims impressive growth without raising funds.

Two opposing paths. Two visions of entrepreneurship. And above all, one central idea: there is no single right way to build a business.

The bootstrap: building a company that reflects you

Wilfried Granier defends a very personal vision of the company.

Superprof wasn't conceived as a startup to be sold, but as a company to be held onto. This difference changes everything. When you don't raise capital, you retain the freedom to decide, to experiment, to take your time, to make choices that may not seem rational on paper, but are consistent with your intuition.

The bootstrap also forces you to focus on the essentials: revenue.

No artificial runway. No growth financed by successive rounds of funding. The market responds directly. If customers pay, the company moves forward. If not, it must correct course.

This constraint can become a strength: it encourages creativity, efficiency, the building of a solid culture, and the search for sustainable organic levers such as SEO, community, user reviews, or gradual internationalization.

Fundraising: Accelerate, learn, iterate faster

Étienne Genvrin offers another interpretation.

For certain markets, particularly consumer applications or products requiring high execution speeds, raising funds can be almost essential. Funding allows for faster recruitment, more testing, and the ability to make more mistakes in less time.

But he insists on one important point: raising funds is a game.

This game has its rules, its codes, its expectations, its language. Many entrepreneurs fail to raise funds not because their project is bad, but because they don't yet understand how this game works.

Raising funds is therefore not just a question of business model. It is also a question of narrative, timing, network, perceived ambition, and the ability to embody a credible trajectory.

The real issue: alignment

The debate could have been reduced to “raise or not raise”. But the real question is deeper:

What type of business do you really want to build?

If your goal is to remain in control, to build for twenty years, to preserve maximum freedom, then the bootstrap may be the best path.

If your goal is to quickly capture a market, recruit expensive profiles, and move very fast in a sector where speed counts, then fundraising can become a strategic tool.

In both cases, the danger is misalignment.

Raising capital when you want a flexible structure can create ongoing problems. Bootstrapping when you're operating in a market where speed is vital can condemn the project to remain too small.

Advice is no substitute for instinct.

One of the strongest messages of the evening: entrepreneurship is learned through practice.

Listening to podcasts, reading threads, or attending conferences can be inspiring. But it doesn't replace being on the ground.

Entrepreneurial instinct is built by talking to customers, selling, recruiting, making mistakes, wasting time, correcting, and starting again.

This is also why we must be wary of absolute advice. Advice that's true for Superprof isn't necessarily true for Emma. A strategy that works in 2013 isn't necessarily effective in 2026. A tactic that works in France might fail in the United States.

The entrepreneur should not seek a universal rule. He must develop his own judgment.

Barriers to entry are built as you move forward

Another interesting point: at the beginning, it is often unnecessary to over-theorize about barriers to entry.

When you start out, you don't yet have 39 million teachers, millions of user reviews, a well-known brand, or an international database. These advantages aren't prerequisites. They're the result of years of operation.

The real initial barrier to entry is often the ability to continue when others give up.

Create a first version. Find a first client. Solve a first problem. Move from level 0 to level 1.

It's less spectacular than an ambitious pitch deck, but this is where the real building begins.

Conclusion

Fundraising and bootstrapping are not two opposing camps.

These are two different tools.

The fundraising buys time, speed, and visible ambition.
Bootstrapping buys freedom, patience, and mastery.

The real issue, therefore, is not which model is superior.

The real question is which one allows you to build the right business, at the right time, with the right level of alignment.

🚀 I rebuilt an LLM… with pixels.

Mathieu Ledru — Sun, 26 Apr 2026 15:59:27 +0000

Large Language Models (LLMs) are based on abstract concepts:
probability distribution, autoregressive generation, large-scale optimization.

These mechanisms are difficult to observe directly.

An alternative approach is to project these concepts into a visual and deterministic system, allowing us to study their dynamics.

This work is inspired by an initial demonstration shared on Twitter:
Allen Explains thread

The goal is to build an educational prototype that will:

represent a sequential generation
observe an optimization process
compare different training regimens

System Architecture

The prototype is implemented in PHP (Symfony 8) and is based on four main components:

Cellular Automaton (Game of Life)
Lambda language (AST JSON)
Genetic Algorithm
Streaming pipeline (NDJSON + SSE)

Full source code:
llm-game-of-life

Representation: from text to grid

An LLM models a distribution:

[
P(x_1, x_2, ..., x_n)
]

broken down into:

[
\prod_{t=1}^{n} P(x_t \mid x_{
]

In this prototype, this structure is transposed:

LLM	Prototype
Token	Cell
Sequence	Grid
Generation	Frame
Model	Program
Inference loop	Simulation

Each frame corresponds to a generation step.

The SSE flow produces a sequence:

frame₀ → frame₁ → frame₂ → …

equivalent to a self-regressive generation.

Model: program rather than network

Unlike traditional LLMs, no neural networks are used.

The model is defined as a program in a mini lambda language, represented as an AST JSON file:

{
  "type": "sequence",
  "nodes": [
    { "type": "birth", "x": 1, "y": 1 },
    { "type": "next" }
  ]
}

This program acts as a transition function on the grid.

This approach replaces:

the weights of a model → by instructions
the layers → through explicit transformations

Optimization: Genetic Algorithm

The training is based on a population of programs.

Each generation follows:

Fitness Assessment
Selection
Crossover
Mutation
Elitism

This process replaces gradient descent.

Unsupervised training

Unsupervised mode maximizes a fitness function based on:

entropy (diversity)
movement (variation between frames)
lifetime

Objective :

[
\text{fitness} = f(\text{entropy}, \text{motion}, \text{lifetime})
]

This regimen is analogous to pretraining:

absence of target
exploration of the solutions space

Supervised Training

The supervised mode introduces a target:

glider
blinker
block

Fitness is becoming:

[
\text{fitness} = -d(\text{frame}, \text{target}) + \lambda \cdot \text{penalty}
]

Or :

(d) is a distance between grids
the penalty limits the size of the programs

This mode corresponds to fine-tuning.

Preferences and selection

A comparison mechanism can be introduced:

Two programs produce two sequences
a preference is applied
The selection favors the best

This diagram represents a simplification of RLHF / DPO:

[
\max \log P(\text{preferred}) - \log P(\text{rejected})
]

Generation and streaming

The results are produced in NDJSON and disseminated via SSE:

Each chunk = one frame
Each stream = one generation

Canvas-based visualization interface:

matrix rendering
real-time display
metrics (fitness, generation, seed)

Presentation slides:
Slidewire presentation

Benchmark and reproducibility

The system includes a benchmark pipeline:

deterministic seed
double execution
sequence hash

Metrics:

duration (duration_ms)
memory (peak_memory_mb)
final fitness
reproducibility

Boundaries

This prototype is not intended to reproduce a real LLM:

no transformer
no tokenization
no probabilistic model
no gradient

This is a computational analogy, useful for:

observe an optimization dynamic
visualize a sequential generation
compare different learning regimes

Conclusion

Modern LLMs rely on mechanisms that are difficult to grasp directly.

Transposing this into a visual system allows us to:

make generation observable
to materialize the optimization
isolate the fundamental concepts

This approach does not replace existing models, but offers a conceptual exploration tool.

Source of the Twitter post: https://x.com/allen_explains/status/2044757995549319172?s=12
The project's source code: https://github.com/matyo91/llm-game-of-life
The presentation slides: https://github.com/matyo91/slidewire

Resources

What are the principles we can use to build LLM-powered software that is actually good enough to put in the hands of production customers? https://github.com/humanlayer/12-factor-agents
AIE Miami Keynote & Talks ft. OpenCode. Google Deepmind, OpenAI, and more! : https://www.youtube.com/watch?v=6IxSbMhT7v4
AIE Miami Day 2 ft. Cerebras, OpenCode, Cursor, Arize AI, and more! : https://www.youtube.com/watch?v=DeM_u2Ik0sk
How AI is transforming software engineering: a conversation with Gergely Orosz, @pragmaticengineer: https://www.youtube.com/watch?v=CS5Cmz5FssI
Microsoft at ICLR 2026: Deep Learning, LLM Reasoning, Generative Models: https://www.linkedin.com/pulse/microsoft-iclr-2026-deep-learning-llm-reasoning-generative-h74se/
ASUS DGX Spark: KI auf dem Schreibtisch – Nie wieder Token‑Kosten! | Live Modellvergleich: https://www.youtube.com/watch?v=dP4zE-DTWAg
🟣 [VIRTUAL SUMMIT DAY 1/5] How to outperform 99% of people using AI: https://www.youtube.com/watch?v=yzhg9Ks859I Ready to launch your own agent? : https://hermes-agent.org/fr/
PaperClip + Agent Hermès, it's insane! : https://www.youtube.com/watch?v=PUaZ5o8u0wY
30-minute workshop by the creator of Claude Code that will teach you more about vibe-coding: https://x.com/heyamit_/status/2046489651775713498?s=46
What Young People Expect from HR: Why the Generational Approach is a Misleading Concept: https://www.insign.fr/en/insights/young-workforce-expectations-generational-approach-an-intellectual-scam

🤖 Symfony AI in Action - Building real AI systems with Symfony

Mathieu Ledru — Fri, 24 Apr 2026 14:25:23 +0000

For two days, on April 23 and 24, 2026, the SymfonyLive Berlin conference brought the community together around the major developments of the Symfony ecosystem.

Among the talks, one in particular marks a turning point:

👉 Symfony AI in Action, presented by Christopher Hertel.

🎥 Slides: https://speakerdeck.com/chr_hertel/symfony-ai-in-action-symfonylive-berlin-2026
🧠 Symfony AI: https://ai.symfony.com
🛠️ Platform used for this article: https://slidewire.dev

This article does not summarize the conference.
He offers a Darkwood interpretation of what is happening.

The real issue: stop thinking “chatbot”

Today, many AI integrations are limited to this:

write a prompt → call a template → display a response

That's insufficient.

The real problem, in production, lies elsewhere:

orchestrate multiple models
manage context and memory
Expose actions (tools)
monitor costs and logs
integrate everything into a business architecture

👉 Symfony AI does not offer a chatbot.
👉 Symfony AI offers a complete stack.

Symfony AI: a stack, not a feature

The objective is clear:

“Enable AI features, not only LLMs.”

Symfony AI introduces several fundamental building blocks:

Platform → model abstraction
Agent → LLM loop + tools
Store → embeddings & RAG
AI Bundle → Symfony integration
MCP Bundle / SDK → tools exhibition

👉 We're moving from an API call… to a complete AI architecture.

Platform: Model abstraction

First classic problem:

OpenAI, Claude, Gemini, Mistral → Different APIs

Symfony AI introduces a unique abstraction.

$platform->invoke('gpt-5-mini', $input);

Same code, different providers.

Why this is key

change model without refactoring
optimize costs
fallback multi-provider
Integrate local and remote

👉 Symfony becomes a model orchestration layer.

Streaming & multimodal

Symfony AI goes beyond simple text:

Real-time token streaming
audio, image, PDF
binary output

Examples:

analyze a PDF
Describe an image
process an audio
generate files

👉 AI is becoming a multimodal application building block.

Structured Output: regaining control

Classic problem:

LLMs return text… not reliable data

Symfony AI introduces typed responses:

$response_format => MyDTO::class

Result :

usable PHP objects
strict validation
Direct integration into the profession

👉 We are moving from “generated text” to controlled data.

Agent: Connect the LLM to your application

An agent is:

a model that can call your code

With Symfony AI:

#[AsTool('create_recipe')]

You present your profession as a tool.

What this changes

Before :

Isolated LLM

After :

LLM + access to your system

👉 AI becomes executable.

Human in the loop: security

A critical point that is often overlooked:

An AI shouldn't do everything automatically.

Symfony AI allows you to:

intercept a tool call
request validation
block or allow

Example :

publish an article
trigger critical action

👉 You remain in control.

Memory: contextualize

Agents do not function without context.

Symfony AI allows you to:

inject user data
manage profiles
store history
control permissions

👉 AI is becoming contextual and personalized.

Store & RAG: Connect your data

Pipeline:

loading
Filtering
transforming
Vectorizing

👉 You are building a vector basis.

Afterwards :

user request
search in the store
enrichment of the prompt

👉 This is RAG (Retrieval Augmented Generation).

Real Impact

Smart FAQ
industry search engine
internal co-pilot
documented assistant

👉 You connect the AI to your business knowledge.

Multi-agent: specialization

Advanced architecture:

senior agent
specialized sub-agents
orchestration
sharing or isolation of context

Example :

support agent
technical agent
billing agent

👉 Each agent has a role.

MCP: Expose your system

Symfony AI is part of a broader movement:

👉 the MCP protocol

Objective :

Showcase your tools
make your system queryable
standardize AI interactions

👉 Your application becomes an intelligence server.

The real turning point: orchestration

The most important point is not:

the models
the prompts
the agents

👉 The real issue is orchestration.

Key questions:

Who calls what?
In what context?
Under what permissions?
With what traceability?
How to regain control?

The Darkwood Approach

At Darkwood, the answer is clear:

Suggested Stack

Symfony AI → AI building blocks
MCP → tools exposure
Flow → orchestration
Navi → execution + tracing
Uniflow → interface

Why this stack

Symfony AI provides:

the models
the agents
the tools
the RAG

But something is missing:

business orchestration
overall control
full visibility

👉 This is where Flow and Navi come in.

What this changes in practice

Before :

isolated AI scripts
fragile prompts
little control

After :

orchestrated system
traceable execution
integrated business logic

👉 We are moving from “playing with AI” to building reliable systems.

Conclusion

Symfony AI marks a major evolution:

You're no longer building a chatbot

you build a complete AI feature

Today you have:

an abstraction of models
agents connected to your code
a memory system
of the integrated RAG
a basis for orchestrating

👉 You have no more excuses.

To go further

Symfony AI: https://ai.symfony.com
Slides by Christopher Hertel: https://speakerdeck.com/chr_hertel/symfony-ai-in-action-symfonylive-berlin-2026
The technical support that allowed me to generate the slides - Slidewire: https://slidewire.dev

Darkwood

Navi → execution & tracing
Flow → orchestration
Uniflow → interface

👉 Articles coming soon with concrete implementations.

🐳 AI Tinkerers Paris Agentic Workflows with Docker - towards autonomous, secure and orchestrated systems

Mathieu Ledru — Wed, 22 Apr 2026 04:00:48 +0000

During this meetup organized by GitGuardian and sponsored by Docker, several speakers shared their vision of modern agentic systems.

The goal is clear: to move from simple AI assistants to true autonomous agents capable of acting, collaborating and executing in production.

🎤 Introduction - Security & Context (GitGuardian)

The evening begins in the Paris offices of GitGuardian, which reminds us of a point often underestimated in discussions around AI agents: before even talking about autonomy, we must talk about access security.

The message is simple. Secrets are everywhere: API keys, JWTs, tokens, credentials, or any information capable of granting access to a resource, service, or infrastructure. In a context where agents increasingly interact with code, repositories, collaborative tools, or connected systems, the detection and control of these secrets becomes a critical layer.

GitGuardian is positioned precisely in this area: helping developers, security teams and infrastructure profiles to identify exposed secrets in their environments, whether it be Git repositories, collaborative platforms like Slack or other surfaces where sensitive information may leak.

Another interesting signal emerges from this introduction: agent security is no longer a theoretical subject. It is becoming a concrete market need, to the point of accompanying a phase of active growth at GitGuardian, which indicates it is recruiting for several profiles, including software engineers and AI engineers.

👉 Key point:

Agents should never expose sensitive secrets without strict controls.

🥽 Speakers

The quality of this evening also stems from its lineup. Rather than presenting purely theoretical profiles, the event brought together speakers directly involved in building tools, runtimes and infrastructures related to agentic workflows.

Sébastien Blanc - making agents truly deployable

Sébastien Blanc, Technical Director at Sciam, presented SAIL: Serverless Agentic Containers, a distributed execution-oriented approach where agents are no longer conceived as simple local assistants, but as workloads capable of running in a serverless environment. His presentation naturally extends the discussions on Kubernetes, Knative, and event-driven architectures, with a fundamental question: how to build robust, scalable, and resource-efficient agentic systems?

Philippe Charrière - exploring the limits and potential of tiny LLMs

Philippe Charrière, Principal Solutions Architect at Docker, presented a session entitled Compose and Dragons: Tiny LLMs, undoubtedly one of the most experimental of the evening. His approach was particularly interesting: demonstrating that small, local models are not merely technical curiosities, but can serve as the foundation for multi-agent systems, provided their memory, performance, and orchestration constraints are accepted. His work highlights a possible future where agents rely not only on large, remote models, but also on local, specialized, and composable building blocks.

David Gageot - simplifying agent creation

David Gageot, Senior Principal Software Engineer at Docker, spoke on Docker Agent: No-Code AI Agents. His presentation focused on radical simplification: reducing the friction between the idea of an agent and its concrete implementation. The value of his presentation lies not only in the "no-code" aspect, but also in the ability to make agents more accessible, more declarative, and easier to integrate into real-world workflows.

Guillaume Lours - securing autonomy

Guillaume Lours, Staff Software Engineer at Docker, presented Docker Sandboxes, probably one of the most strategic topics of the evening. While many discussions around agents focus on models or prompts, his presentation puts the runtime back at the center: if an agent is to act, it must be isolated, observable, and governable. Docker sandboxes provide a very concrete solution to questions of secure execution, network permissions, secrets, and access control.

Djordje Lukic - think of the agent as a system, not as a gadget

Djordje Lukic, Principal Software Engineer at Docker, shares a presentation on Docker Agent with David Gageot. His contribution is significant as he situates the topic within a broader discussion on agentic frameworks. Beyond the promise of “easy-to-create” agents, there is a more structural ambition: to provide a framework where models, tools, instructions, and orchestration can be neatly assembled, with a true engineering logic behind them.

🧠 David Gageot - Djordje Lukic - Docker Agents - from assistant to true agent runtime

The Docker segment opens with Georgi and his team, who present Docker Agent not as just another assistant, but as what they themselves call a “Swiss Army Knife” of agentic frameworks. The idea is quite clear: to move beyond the ad-hoc use of the model and into a logic where AI becomes a fully-fledged execution component. Their starting point is not theoretical. They explain that Docker has been working on these topics for nearly two years, particularly around Gordon, the assistant integrated into Docker Desktop, and that Docker Agents is now used internally to build and evolve its own tools.

What immediately stands out is the desire to make agents configurable, composable, and usable in real-world conditions. Docker Agents can connect to various models, local or remote, integrate with diverse tools, and, most importantly, be described very lightweightly in YAML, without systematically requiring a complex implementation. This is one of the demo's strongest messages: getting started with agentics doesn't necessarily begin with a cumbersome SDK or a distributed architecture, but sometimes with a simple, clear declarative definition that produces useful behavior.

The first demonstration deliberately plays on something absurd—a hacker agent—to show how low the barrier to entry is. With a template and an instruction, the team already has an exploitable agent. The demonstration is lighthearted, almost mocking, but the subtext is important: an agent doesn't need a huge infrastructure to exist; it primarily needs a clear execution framework. From there, Docker can scale it into something much more serious.

This is precisely what happens in the second part, which is much more technically compelling. The team demonstrates how to connect an existing API to an agent using its OpenAPI definition. In their example, it's a Pokémon API—used as a deliberately playful substitute for a more traditional business API—but the message is clear: in a corporate environment, it would be possible to use the exact same mechanism to connect internal services, knowledge bases, or specialized tools. The OpenAPI specification is transformed into a set of tools, and the agent can then query the system without the user having to directly manipulate the endpoints. It's no longer the human navigating the API; the agent handles the mediation.

The demo also highlights an often underestimated architectural point: the question isn't just about giving an agent tools, but about giving it the right tools. During the Q&A session, the team acknowledged that an overloaded agent quickly becomes ineffective. Even if an OpenAPI specification can expose dozens or even hundreds of tools, it's better to filter them heavily and keep only a subset that's relevant to the task. The key idea here isn't "more tools = better agent," but almost the opposite: a specialized agent works best with a limited, readable, and intentionally defined scope.

The most interesting part comes next with the more advanced use cases. Docker Agents isn't limited to a single-agent approach handling a few API calls. The team demonstrates a multi-layered system, with a main agent, dedicated commands, and then sub-agents, each with its own role, instructions, model, and potentially its own tools. The interactive quiz and the Pokémon battle simulation primarily serve to illustrate a broader idea: useful agentics relies less on a single “super-agent” than on an orchestration of clearly separated responsibilities. The root agent coordinates, the sub-agents execute, and each operates within a more clearly defined context.

The answers provided during the Q&A session reinforce this point. Docker distinguishes, in particular, two forms of inter-agent interaction: on the one hand, sub-agents, which receive a task with a new context; on the other hand, handoff mechanisms, where the conversation can switch from one agent to another. The team also mentions the possibility of sharing certain memory or to-do tools between several agents. Here again, we find a structuring idea: agentics becomes interesting when it ceases to be solely conversational and becomes organizational. We are no longer simply asking a model to respond; we are distributing work among several specialized entities.

🔐 Guillaume Lours - Docker Sandboxes - giving autonomy without relinquishing control

The second part perfectly complements the first. After demonstrating how to build agents, the Docker team poses the real question: where and how should they operate? This is where the demonstration of Docker Sandboxes comes in. The initial observation is very concrete: as long as an agent needs to read files, install dependencies, run commands, or access the network, it becomes impossible to run it reliably directly on the host machine without accepting an excessively high level of risk. The presenter states it very clearly: granting this level of access to an agent on your laptop is out of the question.

Docker's proposed solution is an isolated execution environment in the form of a micro-VM, containing its own Docker engine, within which runs a container hosting the agent. This represents a significant shift in perspective. The challenge is not simply to "restrict" the agent, but to create a framework that, on the contrary, grants it greater autonomy, while still allowing the ability to observe, filter, and interrupt its actions. The goal, therefore, is not to render the agent harmless by blocking it entirely, but to give it enough freedom to truly function within clearly defined boundaries.

The demonstration is compelling: in a simple web project, the agent can independently install the necessary dependencies, launch build commands, and execute tests, even when this involves operations that one wouldn't readily accept on their personal machine. The key advantage isn't just technical isolation; it's also visibility. Sandboxes expose an interface that allows users to list running environments, inspect active processes, observe network traffic generated by the agent, and, more broadly, understand what it's actually doing. Therefore, delegation isn't blind; it's delegation within an instrumented environment.

Network management is probably the most compelling aspect of this section. Docker demonstrates several network policy modes, ranging from outright denial to a much more permissive openness, with a balanced intermediate option. Crucially, the interest lies not so much in the names of the modes as in the granularity they subsequently enable. Blocked access can be visualized in the sandbox's network logs and then explicitly granted. This transforms the agent's network behavior into an observable and adjustable policy, rather than a global permission granted once and for all. In other words, access to the web or a specific domain is no longer based on implicit trust, but on an explicit decision.

The same logic applies to secrets. Here too, Docker takes an interesting approach: secrets are not simply “visible” in the agent's environment as they would be on a misconfigured machine. They are injected when the sandbox is created, with a global or specific scope depending on the need. This detail is truly important in production: it means that an agent should not inherit everything on the development machine by default. It only operates with what has been provided to it in its controlled environment. In practice, this makes secrets an explicitly provisioned resource, and not a side effect of the user session.

The port exposure demo illustrates this point. An application can run in the sandbox without being immediately visible from the outside. To access it, the relevant port must be published; if it's removed, the application continues to exist in its isolated environment but becomes inaccessible from the outside. Here again, Docker demonstrates a clear separation between execution and exposure, which is precisely what's missing in many overly hasty agentic demos.

Finally, the demonstration concludes with a particularly interesting case for modern workflows: multiple agents working on the same source code, but without interfering with each other. The proposed approach relies on the automatic creation of separate branches or worktrees, so that each agent can operate in its own workspace. This part is important because it shows that Docker doesn't just think of the agent as an individual assistant, but also as a parallel actor in a collaborative development flow. The agent is no longer just there to respond, but to take over part of the work in a controlled, isolated, and potentially concurrent space.

The implicit conclusion of this sequence is undoubtedly the most useful of the entire evening:

The real issue is not preventing agents from acting, but building the environment in which they can act properly.

In other words, useful autonomy doesn't stem from blind trust, but from a well-designed runtime: isolation, granular network policies, controlled injection of secrets, observability, and separation of workspaces. This is probably where Docker's approach becomes most compelling for stacks like Darkwood, Flow, or any architecture seeking to move agents from the "demo" stage to the "system" stage.

🧠 Philippe Charrière - Local models, between promise and memory pressure

With Philippe Charrière's presentation, the evening shifted its focus from agentic frameworks to something much more concrete: the actual cost of running a model locally. His presentation had the merit of bringing the topic back down to the level of the machine, RAM, and technical trade-offs. Behind the enthusiasm surrounding "small models," his observation was simple: yes, local models are interesting, but as soon as you want to do more than a minimal demo, the dominant constraint immediately becomes that of resources, especially on Macs.

The main point of friction, in his experience, isn't so much Docker itself as the memory pressure generated by the templates. On his machine—a MacBook Pro M2 Max with 32 GB of RAM—a template might seem to "hold up" in theory, then become unusable in practice as soon as it's actually queried. Philippe emphasizes an important detail: a compatibility estimate isn't always a guarantee of comfortable use. A template might start, respond once, then quickly degrade the machine as soon as the load increases. And if you add a second, different template, or simply more requests, the situation deteriorates even faster. His real-world experience is almost brutally simple: for a long time, what he thought was a Docker problem was actually a memory issue.

His demonstration was based on a relatively straightforward stack: Docker Model Runner, Docker Compose, and a set of local models used as building blocks for a larger system. During the Q&A session, he explained that Docker Model Runner currently relies on engines like llama.cpp and vLLM, with the possibility of future integration with MLX. He also clearly distinguished between different use cases: vLLM seemed better suited for production, while llama.cpp remained more relevant for local or experimental use. Again, the key point is not to promote a single, overarching backend, but to recognize that the model runtime is itself an architectural issue.

But the presentation isn't just a simple warning about RAM. Philippe also demonstrates what can be built despite these constraints, provided one is willing to work with small, specialized, and local models. His example takes the form of a text-based game project, a kind of dungeon crawler orchestrated by several components. This choice might seem playful, but it primarily serves to showcase an interesting architecture: an MCP server to manage the dungeon, rooms, monsters, and rules; a Dungeon Master as the main agent; several NPC agents exposing their own APIs; and a final boss that also functions as a fully autonomous entity. This is no longer a simple prompting demo, but an attempt at multi-component simulation, where each role has its own scope of action.

What makes this section particularly useful is that it shows that local models aren't just a matter of cost or sovereignty. They imply a different way of thinking about the system. Philippe explains, for example, that he reuses the same model for multiple agents to avoid memory overload, rather than multiplying heterogeneous instances. This approach is important: in a constrained environment, good design doesn't necessarily consist of choosing the best model for each agent, but sometimes of designing the entire workflow around an acceptable hardware compromise. The system must then be designed based on the available machine, not just the ideal functionality.

His “Compose and Dragons” project perfectly illustrates this logic. The dungeon map is generated in advance, and other components then enrich the experience with descriptions, NPCs, and interactions. All of this relies on an orchestration combining local models, Docker services, and specialized agents. It's not yet a demonstration of industrial robustness, but it's an interesting proof of concept: even with limited resources, it's possible to create a relatively rich, autonomous system, provided you accept its limitations in latency, memory, and complexity. Philippe himself states this frankly during the demo: on small models, some interactions remain slow, some transitions fail, and the system still requires adjustments. This is precisely what makes the feedback credible.

Finally, a more subtle but very useful point emerged at the end of the discussion: this local architecture can also be combined with Docker sandboxes, provided that the correct ports are explicitly opened to connect to the model runner from the isolated environment. Here again, we find the central theme of the entire evening: agents, models, and tools are only as good as the runtime that connects them correctly. Local models are therefore not a “simple” alternative to the cloud; they simply shift the problem to another level, where a trade-off must be made between autonomy, performance, memory, and execution architecture.

In summary, Philippe Charrière's demonstration reminds us of one essential thing:

Local models are useful, but they do not eliminate complexity; they simply make it more visible.

☸️ Sébastien Blanc - Production Agents - Kubernetes & Knative

The latest intervention clearly shifts towards a production-ready approach. After agents, models, and sandboxes, the question becomes simple:

Where and how can these systems be scaled up?

The proposed answer is straightforward: Java + Kubernetes + Knative.

🚀 A deliberate stack

The choice is deliberately clear-cut:

Java (Quarkus) for the application layer
Docker for packaging
Kubernetes as the primary runtime
Knative to introduce serverless

A clear stance is even taken during the talk:

Agent workflows will become industrialized, and Kubernetes will remain their operating system.

🔥 From local demo to production

The demonstration follows a very concrete, almost pedagogical path:

Creation of a local chatbot connected to a model via Docker Model Runner
Exposure via a simple HTTP API
Containerization of the application
Deployment on Kubernetes
Execution in a pod… capable of interacting with the local model

👉 Interesting point:
the model remains accessible via an OpenAI compatible API, which allows reuse of any existing library without heavy adaptation.

⚡ Knative - the real game changer

Once the application is deployed on Kubernetes, switching to Knative completely changes the execution model.

Instead of managing continuous pods, we're switching to a native Kubernetes serverless model:

no traffic → 0 pods
Incoming request → Automatic creation of a pod
peak load → massive auto-scaling
End of activity → return to zero

👉 Simple but effective demonstration:

a curl → triggers the creation of a pod The request has been processed.
A few seconds later → the pod disappears

We no longer manage machines, but only on-demand workloads.

🧠 The real problem: the agents' memory

This model immediately raises a critical question:

What happens to memory when everything scales to zero?

The proposed solution is pragmatic:

make agents stateless
externalize the state into a dedicated system

👉 Solution used:

Redis as shared memory
Storing the state of conversations/agents outside of pods

Result :

Agents can be recreated on the fly
Memory persists independently of the infrastructure
The system remains compatible with Knative's aggressive scaling

🧩 Towards distributed agentic systems

The conclusion opens up an interesting direction:

Agent deployment via Kubernetes CRDs
communication between agents
large-scale orchestration
Triggering via events (Kafka, HTTP…)

👉 In just a few lines of YAML, you can:

Deploy multiple agents
to make them communicate
manage their lifecycle automatically

💡 Takeaway

This section completely changes perspective:

An agent is no longer a script or a local tool.

It is a distributed, ephemeral computing unit, orchestrated by Kubernetes.

And with Knative + Redis, we obtain an architecture where:

the execution is flexible
the state is outsourced
and agents become truly scalable in production

🧭 Global vision

The talks are converging in the same direction:

🔁 Before

LLM = assistant
occasional use

🚀 Now

autonomous agents
multi-agent
orchestration
actual execution

🧩 The key building blocks

Domain	Solution
Agents	Docker Agents
Security	Docker Sandbox
Models	Docker Model Runner
Orchestration	YAML / multi-agent
Infra	Kubernetes / Knative
Memory	Repeat

🎯 Conclusion

The real issue is not limiting the number of agents, but:

give them maximum autonomy within a strictly controlled framework

Key concepts:

sandboxing
network policies
secure injection of secrets
multi-agent orchestration
infra scalable

🚀 Takeaway

We move from:

👉 “I ask an AI”
has
👉 “I delegate to an autonomous system”

👨‍💻 Benchmarking Small Language Models in the Real World

Mathieu Ledru — Tue, 21 Apr 2026 07:55:27 +0000

On Saturday, April 18th, I participated in a hackathon that invites machine learning engineers, data engineers and researchers to Paris for an in-depth study of the evaluation of small language models (SLM).

This hackathon, organized by AI Tinkerers Paris, addresses a very concrete problem:

test the actual ability of language models to produce production-ready executable code.

The theme - "Benchmarking Small Language Models in the Real World" - sets a clear framework: moving beyond impressive demos to confront models with real-world constraints (execution, performance, resources).

🎯 Objective

The challenge is to automatically generate Polars queries from natural language, with a strong requirement:

produce correct code
ensure that it is executable
Optimize execution time and memory consumption

The scoring reflects this reality:

Score = N / (T × VRAM^0.1 × RAM^0.01)

👉 In other words: accuracy alone is not enough - system efficiency becomes a central constraint.

⚙️ Technical Context

Each team works in a standardized environment:

execution under Docker
Use of Polars for data processing
GPU/memory constraints
evaluation dataset provided

The goal is not to create "the best prompt", but to build a system capable of:

withstand real data
produce robust code
run an automated benchmark

🧩 Positioning

This hackathon stands out because of its approach:

no marketing demo
no "impressive but fragile" generation
focus on what really works

👉 This is an environment that directly exposes the current limitations of LLM:

hallucinations
syntax errors
Misunderstanding of the data schema

And it forces you to build around it.

prompt structured engineering
systematic validation
fast iteration loop

📊 Reading

This is not a "creative" hackathon, but an engineering benchmark.

The final deliverable is not an idea, but:

a measurable, reproducible, and comparable system.

🏗️ Day's Organization

Morning - framing and initialization

The morning is dedicated to setting up the technical and organizational framework:

Team formation via the event portal
Presentation of the problem by the organizers and mentors
Clarification of expectations (generation of executable Polars code + scoring)
Initial setup of the work environment

The Darkwood team is formed around:

The objective of this phase is to reduce uncertainty and align everyone on an executable pipeline from the very first hours.

Midday - Forced Break

Lunch provided on site
informal exchanges between teams
Consultation of the message center (general questions, clarifications from the jury)

👉 Short phase, without real decoupling: the project remains in iteration.

Afternoon - Implementation and Iterations

The afternoon is entirely production-oriented:

implementation of the benchmark (polars-bench)
integration of the model via ai-harness
experimentation on prompts (structure, format, constraints)
Adjusting model behavior via dataset and prompt engineering
progressive validation via actual execution

The iterations focus on three areas:

Hallucination reduction (schema-aware prompting)
improved executable code rate
score optimization (time / memory / accuracy)

👉 The logic is not to add features, but to tighten the system around real constraints.

⚙️ Benchmark Architecture

The system relies on a clear separation of responsibilities:

ai-harness → pattern orchestration layer
polars-bench → execution and evaluation engine

This breakdown allows us to isolate the generation (LLM) from the execution reality (runtime), which is precisely the objective of the benchmark.

🤝 Sponsors, Mentors & Organizers, Teams

This hackathon is made possible thanks to an ecosystem of complementary players: sponsors, mentors and organizers, each playing a key role in the overall experience.

🏢 Organizers

The event is organized by the AI Tinkerers Paris community, a collective active in experimenting with and sharing AI technologies.

🌐 Official website: https://paris.aitinkerers.org
📅 Hackathon page: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk
👥 Organizers: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/organizers

Their positioning is clear: to promote concrete experimentation around AI models, with a focus on real engineering rather than demonstration.

💼 Sponsors

Sponsors support the event by providing:

technical resources (GPU, infrastructure, tools)
funding
visibility

👉 Their role is critical to enabling a realistic environment (compute constraints, Docker execution, etc.).

Mistral
- Sponsor page: Hackathon Sponsors
- Representative: Matthieu Dinot — AI Scientist at Mistral
Alpic
- Sponsor page: Hackathon Sponsors
- Representative: Nikolay Rodionov — COO at Alpic
- Other links:
- X / Twitter
- GitHub
Cloudfare
- Sponsor page: Hackathon Sponsors
- Representative: Nans Cyril Bouissou — Account executive at Cloudfare
Fold
- Sponsor page: Hackathon Sponsors
- Representative: Raouf Chebri — Developer Relations Engineer at Replit
Microsoft
- Sponsor page: Hackathon Sponsors
- Representative: Julien Bichon — Developer Experience | GTM Manager at Microsoft
ESGI (venue partner mentioned alongside sponsors)
- Sponsor / venue page: Hackathon Sponsors
- Representative: Astrid Beaucourt — Communications Officer at ESGI
- School links:
- LinkedIn
- X/Twitter

🧑‍🏫 Mentors

Mentors support participants throughout the hackathon:

assistance in structuring approaches
Feedback on templates and prompts
tips on performance and optimization

👉 They help avoid common dead ends:

over-optimization of the prompt
lack of validation
errors in data interpretation
Arthur Mensch
- Mentor page: Hackathon Mentors
- Role: Co-founder and CEO of Mistral AI
- Public profile link: not visible in the provided data
Leo Arsenin
- Mentor page: Hackathon Mentors
- LinkedIn: Léo Arsenin
- Role: Solutions engineer at Cloudfare
Matthieu Dinot
- Mentor page: Hackathon Mentors
- LinkedIn: Matthieu Dinot
- Role: AI Scientist at Mistral
Preetham Kaukuntla
- Mentor page: Hackathon Mentors
- LinkedIn: Preetham Kaukuntla
- Role: Staff Data Scientist at Glassdoor
Mentors Message Board
- Mentors Message Board

👥 Teams

Darkwood
- Status: 1st Place
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_qFVxlREukLQ
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_qFVxlREukLQ
- Demo video: YouTube
- Members:
- Mathieu Ledru
- Mirza Marotsaha
- Victor-eliejah GARNIER
bluebull
- Status: Best Startup
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_-p8xvdGl-oA
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_-p8xvdGl-oA
- Members:
- Vasiliki Doropoulou
Muon
- Status: 10x Data Scientist
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_ub4tDzlrft0
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_ub4tDzlrft0
- Members:
- Imane Momayiz
Polaris
- Status: Finalist
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_y4_Yz6P5BZE
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_y4_Yz6P5BZE
- Members:
- Hippolyte Dupont
- Ghaith ABDESSALEM
- Jacques Dumora
Training Expert
- Status: Finalist
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_njEtwEBAmUE
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_njEtwEBAmUE
- Members:
- Eva Useros Marugan
- Paul-Louis Fouesnant
CodeMind
- Status: Submitted
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_wRj-nEG24zE
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_wRj-nEG24zE
- Members:
- Amelie Smith
- Damien Frechou
- Anis Kaci
- Choutri Adel Djalil
Coffe is life
- Status: Submitted
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_RFBTGYYwbm4
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_RFBTGYYwbm4
- Members:
- Pierre Lepagnol
- Filipp Trigub
PiLLM
- Status: Submitted
- Entry: /hackathons/h_sj1ca_J4Hdk/entries/ht_Gc4SneBV2D4
- Team: /hackathons/h_sj1ca_J4Hdk/teams/ht_Gc4SneBV2D4
- Members:
- Din Sokheng
- Ahmed Abdelaziz Mokeddem

🔗 Useful Links

🏠 Home: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk
👥 Teams: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/teams
📩 Message Center: https://paris.aitinkerers.org/message_center?board_key=meetup_mu_eZJ5tCXlA2A
🏆 Submissions: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/entries
📊 Results: https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/results

🧱 Technical Stack

The architecture is intentionally simple, but constrained by real-world conditions:

Python for execution
Polars as a search engine
Quinn 2.5 as a generation model
FastAPI for the interface
Local sandbox (CPU) with memory constraints

The core of the system is an API that transforms a natural request into directly executable Polars code.

🔄 Execution Pipeline

The benchmark requires a complete chain, without shortcuts:

User Query (NL)
    ↓
Prompt enrichi (schema + règles)
    ↓
LLM
    ↓
Code Polars généré
    ↓
Exécution réelle
    ↓
Validation
    ↓
Scoring

👉 The model is not evaluated on what it "says", but on what its code actually produces.

🧠 Generation Strategy

The key choice is simple:

❌ train the model
✅ to constrain one's behavior

Rather than heavy-handed fine-tuning, the system is based on:

a structured prompt
a dataset of targeted examples

Required Format

System:
- règles Polars
- contraintes strictes

User:
- schéma
- requête

Assistant:
- code uniquement

👉 The model learns an execution pattern, not general knowledge.

🗂️ Dataset

The dataset is not massive, it is intentional:

15 to 500 examples
focused on critical patterns

Cutlery:

selection
filters
aggregations
joins
window functions
nulls
edge cases

👉 Coverage is more important than volume.

📊 Schema injection

The model doesn't guess anything.
The scheme is injected systematically:

{
  "columns": ["card_name", "mana_cost", "frequency"]
}

Direct effects:

fewer hallucinations
Valid queries on the first try
strong dependence on the provided context

👉 Without a diagram, the system collapses.

⚡ Inference Constraints

~6GB model
CPU only
high latency

Consequence:

Every call counts
Re-sorting is expensive
The prompt must be precise from the outset

👉 The cost of error is included in the score.

🧪 Validation & scoring

The benchmark validates a complete behavior, not a raw output.

Levels

Valid code
Successful execution
Correct result
Acceptable performance

Score

Score = N / (T * VRAM^0.1 * RAM^0.01)

👉 We measure a constrained system, not an abstract model.

🔁 Architectural choices

Three options:

fine-tuning → too heavy
multi-models → too complex
prompt + dataset → chosen

👉 Decision: encode the behavior in the data

🧩 Implementation

The API exposes a simple stream:

input:
- request
- metadata
output:
- Polars code

The service:

builds the prompt
calls the model
returns the code

👉 Voluntary simplicity: the real difficulty lies elsewhere.

📦 Positioning

The project is not presented as an LLM wrapper, but as:

a secure analytical copilot for tabular data

With :

guided prompts
structured context
execution verified

👉 The product is defined by its constraints, not by the model.

🧭 System reading

This benchmark shows one thing:

The performance of a small model is a property of the system, not of the model alone.

The real levers:

structure of the prompt
dataset
Context injection
runtime validation

👉 We're going from an ML problem to an engineering problem.

🧱 Components

Harness

abstraction of models
standardization of inputs/outputs

Executor

isolated execution
error capture
runtime metrics

Scoring

validity
performance
stability

📊 What is measured

Execution → Is it running?
Correction → Is this correct?
Polars Quality → correct use of the motor
Performance → actual cost

🔍 Real-life case

Input:

"Find the top 10 most frequent cards with mana cost ≤ 3"

Expected :

filter correct
correct aggregation
sorting + limit

Observed:

valid but incorrect code
Python fallback
silent errors

👉 The benchmark reveals the gap between generation and execution.

⚠️ Real stakes

An LLM generates plausible code, not reliable code

So, in production:

sandbox required
systematic validation
controlled retrievals
monitoring

👉 Without this, the system is unstable by default.

🧠 Project Contribution

This benchmark introduces:

an end-to-end executable pipeline
a multi-criteria assessment
a reproducible approach
a production-friendly environment

Rest :

ai-harness → orchestration
polars-bench → evaluation

👉 This is no longer a model test, it's a complete system test.

📹 Demo

Submission video:

📦 Hackathon Deliverables

Full benchmark code
Test set
Reproducible pipeline
Comparative results

Example of a provided structure:

submission_example
main benchmark code
datasets
logs

🧭 Conclusion

This hackathon is not intended to demonstrate that LLMs work.

It shows where they break.

And most importantly:

A useful benchmark does not measure generation.
It measures performance.

🔮 Darkwood Perspective

This type of benchmark fits directly into a broader vision:

orchestration of AI pipelines
systematic validation
generation/execution separation
observability

👉 This is not a demo tool.
It's a building block for constructing reliable systems.

🚀 Sundays Lab #3 - When AI becomes a collective playground

Mathieu Ledru — Mon, 20 Apr 2026 12:15:35 +0000

On Sunday, April 19, 2026, at Hexa (eFounders) in Paris, a new edition of Sundays Lab was held.
A seemingly simple format: coworking, AI workshop, exchange session.

But in practice:
👉 a concrete demonstration of what the builder ecosystem will become in 2026.

⚙️ A paradigm shift: from conference to interactive system

The first strong signal of the event is not technical.

This is the format.

We are no longer sure:

top-down talks
“Inspiring” speakers

We are on:

a real-time construction
an ongoing interaction**
a system where the audience becomes a co-creator

“We didn’t want a traditional workshop. We wanted everyone to participate.”

Here's a section ready to integrate into your Darkwood article 👇

🧑‍🚀 Speakers & Participants - Projects and Weak Signals

👤 Pato - AI & Automated Go-To-Market

As the founder of Cluently, he embodies the “builder + sales” profile.
His presentation shows how AI can replace entire business functions (prospecting, matching, CRM).

👉 Project presented:

AI agent for automated prospecting
Intelligent matching between profiles / opportunities
Build Society community app generated live

👉 Key signal:

The future of SaaS = agent + distribution, not just product

👤 Jules - Growth & Creative AI

Founder of Loops, focused on performance marketing.

👉 Project:

SaaS for generating high-performing ads
Focus on creativity as the main driver of growth

👉 Insight:

Growth no longer comes from targeting
but large-scale content creation via AI

👤 Tom - Personal branding & distribution

Content creator (philosophy + tech), rapid growth on Instagram.

👉 Positioning:

Build an audience before a product
Transforming complex ideas into viral content

👉 Insight:

Distribution is becoming a stronger asset than tech.

👤 Lucas Lefner - Startup advisory & network

Provides support to early-stage startups (strategy, sales, equity).

👉 Model:

support in exchange for equity or mission
creation of a business club (Startup Hunters)

👉 Key insight:

“90% of business is networking”

👉 Signal:

return of network-driven business
Importance of private circles / clubs

👤 Enzo - Iomaris

Real estate startup (beta phase).

👉 Product:

Platform for managing a real estate project from start to finish
Profitability analysis, taxation, market
collaboration between individuals and professionals

👉 Business model:

Free for individuals
Monetization via professionals (leads)

👉 Insight:

extreme simplification of a complex domain via AI
trend “vertically integrated business assistant”

👤 Eli - Gamified Education App

Student (HEC), project focused on academic productivity.

👉 Product:

collaborative work app
Strava-type logic applied to the study
comparison between students / classes

👉 Insight:

gamification + social = strong engagement lever
“public progress tracking” logic

👤 Romain - Automated Pentest with AI

Profile not an expert in cybersecurity.

👉 Product:

Automated penetration testing service via AI
Use of scripts + LLM to detect vulnerabilities

👉 Model:

one-off service (audit)
no ongoing maintenance

👉 Key insight:

AI makes it possible to create expert services without initial expertise.

👉 Signal:

explosion of AI-augmented agencies

👤 Laurent (Startup Hunters) - Ecosystem & Support

Supports startups and young entrepreneurs.

👉 Activity:

business structuring
Connecting investors and founders

👉 Insight:

Lack of operational support for early founders
growing need for on-the-ground guidance

👤 GEO Project (AI Search Optimization)

E-commerce consultant / Advanced SEO.

👉 Product:

optimization tool to appear in LLM responses
alternative to traditional SEO

👉 Function:

analysis of the sources used by AI
Content optimization + ecosystem

👉 Key insight:

AI traffic will surpass traditional SEO

👤 Social Matching Project (anonymous)

Next generation social network concept.

👉 Product:

Weekly matching based on deep interests
No profile, no swipe
authentic interaction

👉 Insight:

reaction to the saturation of social networks
back to qualitative interactions

🧭 Overall reading

These profiles show a clear convergence:

1. All projects use AI

But at different levels:

Automation (sales, penetration testing)
product (ads, real estate)
distribution (content, GEO)

2. The technical barrier disappears

➡️ Everyone can build
➡️ so the difference lies elsewhere

3. The real weapons become:

network
distribution
branding
niche

In concrete terms:

an app generated live
decisions made via vote
a product built in front of the audience

👉 The event itself becomes a product prototype.

🤖 AI is no longer a tool, it's a production interface

The workshop highlighted a key point:

👉 Software creation is now iterative, public, and assisted.

A concrete example observed:

app scenario generation
code generation with LLM (Claude)
Automatic error correction
near-immediate deployment (Cloudflare)

“Claude generates the code, corrects his errors, and we build the app as we go.”

What it actually changes

Before :

design → dev → test → deploy

NOW :

intention → generation → feedback → correction

👉 The cycle becomes continuous and conversational.

🧠 The real issue: distribution > technology

One point came up several times during the exchange session:

👉 Technology is no longer the barrier to entry.

What remains difficult:

find customers
distribute a product
create an audience

“Code is becoming commoditized. The real barrier is distribution.”

Direct consequence

We observe a shift:

Before	Now
Build a product	Build an audience
Optimize tech	Optimize acquisition
Be a developer	Be a full operator

📈 Acquisition: Organized Chaos

The discussions highlighted a reality:

👉 There is no longer a single dominant channel.

Canals mentioned

LinkedIn (B2B, decision-makers)
Instagram (creation + virality)
Twitter/X (monitoring + opportunities)
Email (still extremely effective)

Key Insight

👉 Efficiency comes from:

repetition
multi-channel presence
the transformation of content into multiple formats

“A video → shorts → reels → LinkedIn post → newsletter”

🧩 The emergence of “hybrid builders”

One profile keeps recurring:

👉 people not technically expert
→ capable of creating products using AI

A striking example:

creation of an automated penetration testing service
without advanced cybersecurity expertise
based on tool orchestration + LLM

“I don’t have strong technical skills, but it works.”

🧠 The underlying problem: cognitive overload

Everyone shares the same feeling:

👉 AI is going too fast

Symptoms :

permanent FOMO
too many tools
too many new things

Observed response:

👉 Return to:

Task structuring (SOP)
simplification
focus

“Write down your tasks one by one, then see what AI can optimize.”

🧬 AI amplifies… but does not replace

A central question was raised:

👉 Will AI kill products?

Overall response from the group:

❌ No
✅ It filters

What disappears

low-quality products
SaaS without distribution
worthless clones

What remains

branding
network
human relationship

“AI amplifies both the good and the bad.”

🌐 Towards a new layer: GEO (AI Search)

An advanced topic has emerged:

👉 GEO (Generative Engine Optimization)

Objective :

appear in LLM responses (ChatGPT, etc.)
not just in Google

Figures mentioned:

18x growth in AI traffic
4x conversion on this traffic

“Users coming from ChatGPT convert 4x more.”

👉 This is probably the equivalent of SEO… AI version.

🤝 The heart of the model: connecting people

The product built during the event is revealing:

👉 a matching app for participants

Aim :

Connect problems ↔ solutions
create real synergies

“Matching problems with solutions.”

🧭 Darkwood Reading

This meetup confirms several major trends:

1. The technical stack becomes secondary

Symfony, Node, etc. → important
But more differentiating on its own

2. Orchestration becomes key

What you do with Flow → totally aligned

👉 Connect:

data
agents
workflows

3. The product = system + distribution

Not just code

4. The future is hybrid

AI → execution
human → direction

⚡ Conclusion

Sundays Lab #3 is not a meetup.
This is a prototype of what the tech ecosystem is becoming.

👉 A space where:

on build live
we learn by doing
we connect in real time

And most importantly:

👉 where the real skill is no longer coding
but to transform an intention into a functional system.

⚙️ Message-oriented vs. Data-oriented orchestration - from data to knowledge

Mathieu Ledru — Fri, 17 Apr 2026 15:37:26 +0000

For intellectual property reasons, the subject chosen for the application of this article will not be the one discussed, although it is closely related. For any further information, please contact Omer who will be happy to answer, and apologize for any potential inconvenience.

In this article, we explore two fundamental approaches to software orchestration:

Message-Oriented Orchestration: via Symfony Messenger synchronous respectively asynchronous
Data-Oriented Orchestration: via Navi for synchronous and Flow for asynchronous

The case study is based on a classic but structuring problem: text mining applied to a set of Git repositories.

For the practical demonstration, I will take the EIT tutorial from 2007/2008 carried out at the time on classification with Matthieu Beyou during computer science class tutorials.

For the data, we use those of Omer (former work colleague) available on his site https://git.arkalo.ovh (via the api).

The goal is not to produce the best machine learning model, but to understand how the form of orchestration influences the complexity, readability, and scalability of the system.

The problem: transforming repositories into usable knowledge

The dataset consists of a list of Git repositories defined in a repos.json file, the data of the directories listed on https://git.arkalo.ovh/explore/repos.

For your information, you can extract the information using the Composio connector for https://composio.dev/toolkits/gitea. Refer to my previous article for the implementation: https://blog.darkwood.com/fr/article/relacher-les-connecteurs-des-outils-au-langage.

Each deposit becomes a canonical document constructed from:

repository name
description
README
metadata (owner, topics…)

This document is then transformed via a classic text mining pipeline:

Pretreatment (cleaning, tokenization)
Feature Extraction
TF-IDF Weighting
Similarity between documents
Classification / clustering

This pipeline is directly inspired by historical approaches:

TF-IDF: weight = tf * log(N / df)
Cosine similarity between documents
Supervised Naive Bayes Classification
Unsupervised k-means clustering

What interests us here is not the algorithm, but the way to orchestrate it.

Note that if you are fond of documentation, you can refer to the Resources section at the bottom of the article which lists a number of topics concerning data mining applied in computer science.

Business pipeline (independent of orchestration)

First and foremost, the core business needs to be isolated.

Repository → Document → Tokens → Features → TF-IDF → Similarity → Results

This pipeline represents a data transformation.

Each step:

takes a piece of data
produces new data
without strong dependence on an external context

This is precisely where the two approaches diverge.

Approach 1 Message-Oriented - Orchestration via Symfony Messenger

In the Message-Oriented implementation, the pipeline is not expressed as a continuous data transformation.

It is encapsulated in a message, then executed via the Symfony bus.

Execution Model

Command → Message Bus → Handler → PipelineService → Stages

In concrete terms:

a CLI command triggers the execution
A message is sent
a handler takes care of the execution
the core business remains centralized in a shared service

RunMessengerPipelineMessage
→ RunMessengerPipelineHandler
→ PipelineService

Separation of responsibilities

This implementation adheres to a key project constraint:

The core business is strictly shared between the two approaches

So :

Messenger contains no business logic
he only orchestrates the execution

Actual Pipeline Executed

The handler triggers a deterministic pipeline:

1. ingest
2. preprocess
3. feature build
4. classification
5. clustering

Each step is executed in a common application service (PipelineService).

Concepts introduced by Messenger

The orchestration explicitly introduces:

a message class
a dedicated handler
a dependence on the bus
a dispatch layer

Command → Message → Handler → Service

These elements are specific to Messenger and do not exist in the data-oriented model

Observability and debugging

Messenger offers a natural debugging model:

message inspection
middleware
bus logging
Extensibility towards async / queue

Debug = niveau message + middleware

Nature of the overhead

In this MVP, the overhead is conceptually measurable:

introduction of an artificial message
Indirection via handler
the need to structure the execution around the bus

But this overhead is located in the orchestration adapter, not in the hardware.

Summary

This approach transforms the pipeline into:

a distributed work unit

She favors:

Symfony standardization
extensibility towards async
integration with the ecosystem

At the cost of an additional layer of indirection.

Conceptual Example

final class ComputeTfIdfMessage
{
    public function __construct(public DocumentId $id) {}
}

final class ComputeTfIdfHandler
{
    public function __invoke(ComputeTfIdfMessage $message)
    {
        $document = $this->repository->get($message->id);
        $vector = $this->tfidf->compute($document);

        $this->bus->dispatch(new ComputeSimilarityMessage($vector));
    }
}

Benefits

strong decoupling
resilience (retry, queue)
native parallelization
Symfony standard

Structural Limitations

The problem quickly becomes apparent:

➡️ the message becomes an artificial envelope

We manipulate:

IDs
persistent states
indirect transitions

The problem is simply:

data → transformation → data

This introduces:

the boilerplate
implicit dependencies
a loss of overall readability

Approach 2 Data-Oriented - Orchestration via Navi (synchronous) and Flow (asynchronous)

In the Data-Oriented implementation, the pipeline is expressed as an ordered sequence of actions applied to a context.

There is no message.

There is no dispatch.

There is only:

a piece of data
a context
a sequential transformation

Execution Model

Command → WorkflowRunner → Actions → PipelineService → Data

In concrete terms:

a command triggers a workflow
The WorkflowRunner executes a list of actions
each action transforms a Context
The business services are identical to Messenger

WorkflowRunner
→ PipelineStageAction[]
→ Context
→ PipelineService

Pipeline Structure

The pipeline is explicitly defined as a sequence:

[IngestAction,
 PreprocessAction,
 FeatureBuildAction,
 ClassificationAction,
 ClusteringAction]

Each action:

takes a Context
applies a transformation
returns a new Context

Nature of the Context

The Context becomes the central object:

it contains the pipeline status
it evolves at each stage
it is inspectable

Context₀ → Context₁ → Context₂ → ... → Contextₙ

Concepts introduced by Flow

This approach introduces:

explicit actions
a runner
an evolving context

Data → Action → Data

Unlike Messenger:

no message
no handler
no bus

Observability and debugging

The debugging process changes completely in nature:

Debug = suite d’actions + snapshots de contexte

Benefits :

visible execution order
inspectable intermediate state
deterministic pipeline

Nature of readability

The pipeline can be directly read as a stream:

ingest → preprocess → features → classification → clustering

Without structural transformation.

Structural Overhead

The cost introduced is different:

need for a Context
abstraction via actions

But :

no envelope
no bus detours
no break in the data flow

Summary

This approach transforms the pipeline into:

a series of data transformations

She favors:

immediate readability
direct transformation of data
absence of envelope
deterministic pipeline
ease of testing

Boundaries

less suitable for complex distributed systems
requires strict discipline regarding the purity of the transformations
Tooling less standard than Messenger

Direct Comparison

Criteria	Message-Oriented	Data-Oriented
Mental model	Events / Messages	Data streams
Readability	fragmented	linear
Overhead	high (messages, handlers)	low
Scalability	excellent	depends on the design
Debug	indirect	direct
Business coupling	weak but diffuse	strong but explicit

Appearance	Messenger	NaviFlow
Central unit	Message	Context
Orchestration	Bus + Handler	Runner + Actions
Flow	indirect	direct
Debug	message-centric	data-centric
Overhead	message + handler	action + context
Pipeline	encapsulated	explicit

Key point: the illusion of complexity

In the case of text mining, each step is:

pure
determinist
functional

Examples:

TF-IDF → simple mathematical formula
Similarity cosine → normalized dot product

There is no natural need for messages.

The introduction of Messenger is therefore an architectural decision, not a business necessity.

Main Insight

Message-oriented transforms data into events.

Data-oriented technology transforms data into data.**

In a system like this:

Message-Oriented adds a layer
Data-Oriented reveals the model

Implications for Symfony

Symfony is evolving towards:

async
workers
sidekicks (FrankenPHP)
distributed orchestration

But this raises a fundamental question:

👉 Does everything have to be orchestrated via messages?

The answer depends on the problem.

When to use each approach

Message-Oriented

distributed workflows
long tasks
resilient systems
industry events

Data-Oriented

analytical pipelines
data transformations
deterministic systems
intensive calculations

Source code

The project's source code is free and can be viewed here: https://github.com/matyo91/omer-quotes

Conclusion

This project demonstrates one simple thing:

👉 Orchestration is not neutral

Two functionally identical implementations can produce:

radically different systems
opposing cognitive costs
divergent evolutionary capacities

In the case of text mining:

Message-Oriented makes things more complex
Data-Oriented clarifie

Symfony Messenger orchestrates a pipeline as a unit of work.

Darkwood Flow orchestrates a pipeline as a data transformation.

The next step in the project is to:

extend the pipeline (clustering, classification)
to integrate more advanced models
expose an API
compare actual performance

But most importantly:

👉 continue to question the form of the orchestration.

Resources

Thank you for writing the article

Omer's git repository for data and inspiration: https://git.arkalo.ovh
Leverage Messenger to Improve Your Architecture - Tugdual Saunier for the article outline: https://speakerdeck.com/tucksaun/tirez-profit-de-messenger-pour-ameliorer-votre-architecture
Polytech Paris Sud (formerly IFIPS) 2008: Information Extraction from Texts Project - Document Classification by François Yvon and Alexandre Allauzen, carried out as a tutorial during the 2007/2008 academic year using the Perl language with Matthieu Beyou https://www.linkedin.com/in/matthieu-beyou-9a425a32/

Examples from friends on EIT topics and mathematical models applied to AI

Claude just changed sales calls forever! (free skill) - Alexandra Spalato | AI Automation: https://www.youtube.com/watch?v=FuVIGGWwYKY
Demystifying AI: A practical guide for PHP developers - Iana IATSUN - PHP Forum 2024: https://www.youtube.com/watch?v=u-yrK_-\_p9g
Embeddings in PHP: Symfony AI in practice: https://speakerdeck.com/lyrixx/embeddings-symfony-ai-en-pratique
Stack Overflow tags - automatic prediction using machine learning algorithms - Marco Berta: https://www.youtube.com/watch?v=fFKXFDDjEJU Help! I'm being asked to use AI! - Drupal Camp Grenoble 2026 - Alexandre Balmes: https://speakerdeck.com/pocky/au-secours-on-me-demande-dutiliser-de-lia-drupal-camp-grenoble-2026
DeepMind's New AI Just Changed Science Forever - Two Minute Papers: https://www.youtube.com/watch?v=Io_GqmbNBbY
Langflow Models Are Smart. Data Is Everything. Building Context-Rich AI Systems with Unstructured: https://www.youtube.com/watch?v=fNLUv6Pvc6w
I am a legend: hacking hearthstone with machine learning - Elie Bursztein, Celine Bursztein: https://elie.net/talk/i-am-a-legend Tell me something about myself that I don't yet know by Nathalie | A Voice That Carries: https://x.com/Bonzai_Star/status/2031432381471797589

The Future of AI as Seen by Yann LeCun

Nobody realizes what Yann LeCun has just created - Grand Angle Nova: https://www.youtube.com/watch?v=P-wAr687qxg
For those who are curious: Inaugural lecture by Yann LeCun - Deep Learning and Beyond: The New Challenges of AI - École nationale des ponts et chaussées: https://www.youtube.com/watch?v=Z208NMP7_-0
What is knowledge made of? From Arthur Sarrazin https://www.linkedin.com/in/arthursarazin in https://srzarthur.substack.com/p/what-is-knowledge-made-of

🤩 Unleach connectors - From Tools to Language

Mathieu Ledru — Tue, 14 Apr 2026 07:17:40 +0000

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.

Resources

💡 I created a GDPR-compliant AI app in 1 hour with Symfony

Mathieu Ledru — Fri, 03 Apr 2026 06:41:54 +0000

Today, many developers use AI to generate code.

The question we are addressing here is the following:

👉 How to transform an idea into an executable system?

And that's normal.

Because we learned to:

coding features
write functions
connect APIs

But not to:

structuring an idea so that it can be executed

At Darkwood, we never start with the code.

We begin with a much more fundamental step:

👉 the reasoning

In this article, we will look at the following in concrete terms:

How to transform an idea into a usable unit
How to use AI to execute this idea
How to apply this in a real project: SketchUp Shape

🧠 1. An idea is not code

When you think:

“Créer une application”

Your reflex as a developer is often:

“Okay, I’m going to code an API, a database, etc.”

👉 Bad starting point.

An idea is not yet something you can execute.

That's right:

👉 a vague intention

💡 The right mental model

At Darkwood, we believe that:

👉 one idea = one task

No more, no less.

Example

“Créer une application”

becomes :

Task: create_app

It may seem trivial.

But this is a significant change:

👉 You no longer think in terms of “projects”
👉 You think in executable units

⚙️ Why this method works: Church, Turing, and the idea as an executable unit

One might think that “prompting an AI” is a recent, almost purely practical topic, linked to current LLM news.

In reality, the problem is much older.

When a developer takes an idea and tries to turn it into an executable system, they always encounter the same question:

How do we move from an abstract intention to a form that the machine can actually process?

This is exactly the type of question that lies at the root of theoretical computer science.

In a previous Darkwood article - Create a Lambda Interpreter in PHP - we already explored this boundary between:

the idea of a calculation
and its actual execution by a machine

This article started with Alonzo Church's λ-calculus, then linked it to the Turing machine, recalling a fundamental point:

The λ-calculus and the Turing machine are two equivalent models of computation

In other words:

Church provides a conceptual model
Turing provides a model of execution

And that's exactly what interests us here.

🧠 Church: before execution, a conceivable form is necessary

Alonzo Church does not start from a machine.
It stems from a much deeper problem:

What is a function?

and more broadly:

What is a calculation?

The λ-calculus responds to this with a radical idea:

Any calculation can be expressed as an abstraction and application of functions.

In this model:

A function is a transformation
a value can be passed to another function
and evaluation consists of applying functions to one another

This is the theoretical root of many things we use today without thinking about it:

functional programming
the currying
closures
the combinators
pure transformations
DSLs

In the article on the lambda interpreter in PHP, this idea was presented in a very concrete way:
We started with an expression, tokenized it, parsed it, built an AST, and then evaluated it.

In other words:

before a system executes something,
First, it must understand a form

This is exactly the point that interests us regarding AI.

When you give an LLM a sentence like:

Create a house

You haven't given it an execution yet.
You give it an abstract form, an intention, a request that is still insufficiently structured.

And that's where Church's intuition becomes useful to us.

Developer translation

When we talk about ideas in this article, we are not talking about vague inspiration or brainstorming.

We are already talking about a manipulable abstraction.

In other words:

An idea must become a unit upon which a system can reason.

That's why, at Darkwood, we make an initial mental shift:

An idea is not yet code.

An idea is already a transformation in progress.

Or, to put it another way:

An idea is a potential task

⚙️ Turing: once the form is defined, it must be executed

Church formalizes calculation on the side of abstraction.
Turing, however, answers a different question:

What does a machine capable of performing this calculation look like?

His answer is famous:

a memory strip
a reading head
a current state
transition rules

The power of the model does not come from its complexity, but rather from its simplicity.

A Turing machine reads a cell, takes its state into account, applies a rule, possibly writes something, and then moves on.

It's an extremely simple model, but sufficient to reason about what a machine can do.

What interests us here is not teaching the entire theory of automata.
It's about recovering a very concrete intuition:

An executable system needs readable units.

and a clear mechanism for switching from one state to the other

This is where the link with modern work on ideas, tasks, and AI agents becomes very concrete.

🔁 What Church and Turing teach us about working with AI

The essential point is this:

Church teaches us to think of calculation as transformation
Turing teaches us to think of computation as structured execution

When you combine the two, you get a much healthier way of working with AI.

We stop thinking:

“I’m going to ask the model for some code”

And we start to think:

“I’m going to give him a structured unit of work,
that he will be able to transform,
then another system can execute”

That's exactly what we do at Darkwood.

🧩 Darkwood translation: an idea becomes a task

At this stage, we can simplify the model without betraying it.

Here is the translation we are using as a basis:

Theoretical concept	Darkwood interpretation
Abstraction	Structured idea
Function	Transformation
Memory slot	Task
Strip	To-do list / stack
Read	Execute
Transition	Change from one state to another

This gives us a simple rule:

an idea becomes a task

a task becomes a readable unit

A readable unit can be executed.

It is this change of perspective that matters.

Because as long as an idea remains only in your head, it is unusable by the system:

nor your terminal
nor your IDE
nor your LLM
nor your orchestrator

cannot work on it properly.

It therefore needs to be given a form.

💡 The idea as a unit of calculation

This is where our method becomes truly meaningful.

When we say:

Créer une application

It's not a system yet.
This is not yet architecture.
This is not yet a usable prompt.

But it's not "nothing" either.

That's already it:

a unit of calculation to be specified

At Darkwood, we put it through a nomination and reduction stage.

For example :

Task: create_app

Task: generate_sketchup_shape

From this point on, the machine - or the system of agents - no longer manipulates just a human sentence.
She is manipulating an identifiable task.

And once you can identify a task, you can:

store it
reread it
reproduce it
transmit it
cut it
parallelize it
to orchestrate it

That's it, that's the real change.

🧠 Why this is so useful for a developer

A developer often tends to jump directly to implementation:

create a folder
Install Symfony
connect an API
write an order

But if the initial idea has not been modeled correctly, everything else becomes unstable.

This leads to what many people experience with LLMs today:

vague prompts
unclear outputs
fragile structures
projects that “work”, but lack coherence

The theory of Church and Turing reminds us of something very simple:

The quality of the execution depends on the quality of the initial representation.

In other words:

If you want to improve the performance of an AI,
First, you need to represent your idea better.

And that's precisely what we're going to do next with SketchUp Shape:

starting from an intention
convert it into a task
to structure it
transform it into a design
then only in code

🧭 The rule to remember

If this entire section had to be condensed into a single sentence, it would be this:

A useful idea for AI is not an inspiration.

It's a sufficiently clear abstraction to become an executable task

And that's where Church and Turing cease to be distant theory.

They become a practical model for the modern developer:

Church helps you think about form
Turing helps you think about execution
Darkwood helps you connect the two

📚 Concrete example

You have several ideas:

- créer une app
- construire une API
- générer un modèle 3D

👉 You can represent them as a stack:

Stack:
- create_app
- build_api
- generate_model

And then, everything becomes simpler:

You can handle each task one by one

in parallel

⚡ 2. Your brain already works like this

You don't need to learn a new system.

👉 You're already using it.

🧠 Simple case: different tasks

Task A: répondre à un message
Task B: installer un package

👉 No link
👉 You can easily switch between them

⚠️ Complicated case: similar tasks

Task A: coder une API
Task B: refactor la même API

👉 Now, things are getting tough

For what ?

same context
same mental variables
same files

👉 Result:

confusion
errors
fatigue

💥 What this implies

Your brain:

has limited memory
handles too much context poorly
saturates quickly

👉 So:

You can't manage many complex tasks at the same time.

🧩 3. The real problem: reproducibility

A task is only valuable if you can:

find her
to revive it
share it

👉 Otherwise, it stays in your head
👉 and she disappears

🧠 Darkwood Approach

We introduce a simple idea:

👉 one task = one pointer

In concrete terms

You write your task in Joplin
she has an ID
This ID becomes your “pointer”

And then:

in your terminal → you are referencing this task
in your IDE → same
in your AI → same

👉 Result:

you manipulate the same object, everywhere

💡 What this changes

You no longer say:

“I’m going to work on my idea.”

You say:

“I will carry out this task”

And that's much more powerful.

⚙️ 4. AI: not a magic tool, an execution system

Today, many developers use AI like this:

“generate a function for me”
“write me a class”
“Fixes this bug”

👉 It works.

But you remain within a certain logic:

responsive

🧠 Darkwood Approach

We completely change the perspective:

👉 AI is becoming an execution system

🏗 We model like a business

Rather than “magical agents”, a simple structure is used:

👤 You (human)

you define the intention
you pose the problem

🧠 AI Architect

he understands your intention
he breaks it down into tasks
he decides how to organize the system

⚙️ Agents

they execute
they produce code
they transform the data

💡 Key Rule

👉 The prompt = your intention

If your prompt is unclear:

👉 the system is unclear

If your prompt is structured:

👉 the system becomes structured

🔥 Example

❌ Bad prompt:

“Generate a house”

✅ Good prompt:

“Create a structured architectural design of a house,
with walls, roof, proportions and constraints,
then generate SketchUp Ruby code from it”

👉 Here, you give:

a direction
a structure
a clear objective

🧠 What you need to remember

👉 You don't need to be better at coding

👉 You need to get better at:

structuring
intention
orchestration

And that's exactly what we're going to apply now with:

👉 SketchUp Shape

🚀 5. Practical application: SketchUp Shape

Project :
👉 https://github.com/matyo91/sketchup-shape

🎯 Objective

Transformer:

“Create a house”

in:

👉 Ruby script executable in SketchUp

🧱 Why SketchUp?

3D modeling tool
Documented Ruby API: → SketchUp Ruby API
extensible (plugins, scripts)

🎓 Context

I personally learned SketchUp with
Sébastien Maison (YouTube)

👉 Here, the goal is not to use their AI:

→ Official SketchUp AI

👉 But to build our own system

⚙️ 6. Pipeline: from idea to (concrete) 3D model

Before going any further, let's take a real-life example.

👉 Here, we're not talking about an abstract API
👉 We're talking about generating a 3D object in SketchUp

🧱 A little background: why SketchUp?

SketchUp is a widely used 3D modeling tool:

architecture
design
prototyping

Personally, I discovered SketchUp thanks to Sébastien Maison, with whom I took a course.

👉 I modeled a house there “by hand”

And that's where the idea came from:

👉 “What if I could generate that directly with code?”

⚠️ Why not use SketchUp's native AI?

SketchUp already offers AI:

👉 SketchUp AI

But that's not the point here.

👉 We are developers.

👉 We want:

to understand
control
automate

So we go through:

👉 SketchUp Ruby API

🧠 The technical entrance

To do this, SketchUp explains:

👉 In concrete terms:

You write Ruby like this:

model = Sketchup.active_model
entities = model.entities

And you build:

faces
volumes
groups

🧩 Resources used

To make the AI more reliable, I used:

Ruby API Stubs
👉 to give the LLM a clear view of the available objects
Official examples
👉 to understand the real patterns

And if you want to go further:

👉 SketchUp Extensions
→ You can package your code as a plugin

⚠️ Important prerequisite

To run Ruby:

👉 You must use the desktop version:

SketchUp Pro Trial

👉 The web version does not allow this (or only in very limited ways)

🔁 Pipeline Darkwood (applied)

Now that we have the context, here is the actual pipeline:

Intention
   ↓
Design (LLM #1)
   ↓
Code (LLM #2)
   ↓
SketchUp

🧠 Step 1: Intention

You start with a simple idea:

bin/console app:generate-shape "Create a house"

👉 Nothing more.

🧱 Step 2: Design (LLM #1)

Here, AI does not code.

👉 She thinks

She acts like an architect:

{
  "type": "house",
  "structure": {
    "walls": {...},
    "roof": {...}
  }
}

👉 She decides:

proportions
elements
of the structure

⚙️ Step 3: Code (LLM #2)

Only then:

👉 a second AI transforms this plan into code

model.start_operation('House', true)
...
model.commit_operation

👉 She acts like a developer:

It uses the SketchUp API
she constructs the geometry

⚠️ 7. Why 2 LLMs (and not 1)

This is one of the most important parts.

❌ Naive approach

idée → code

👉 What you get:

inconsistent
unpredictable
difficult to correct

✅ Darkwood Approach

idée → design → code

👉 You separate:

🧠 the what
⚙️ the comment

💡 It's exactly like in a team:

architect → decides
developer → implements

🧠 8. The real problem encountered

When I launched:

Create a house

👉 Result:

technically valid
but visually… false

👉 It wasn't a house

❌ Why?

Because AI did this:

“A house = shapes”

👉 She stacked:

cubes
a roof
without logic

💥 The real problem

AI doesn't understand:

gravity
the proportions
actual usage

👉 She doesn't understand:

what a house is

🧠 Correction made

A layer was introduced:

👉 structured design

Instead of :

{ "parts": [...] }

We force:

{
  "type": "house",
  "foundation": {...},
  "walls": {...},
  "roof": {...},
  "constraints": {
    "symmetry": true,
    "alignment": "centered"
  }
}

👉 Result:

consistency
stability
made credible

⚙️ 10. Technical Stack

🧱 Backend

Symfony 8
Symfony AI
darkwood/navi

👉 Installation:

composer require darkwood/navi

🧠 Local AI (GDPR)

👉 everything runs locally

⚖️ Why this is important

no external API
no data leak
total control

👉 You build a system:

GDPR compliant by design

⚙️ 11. Orders

🧠 Local LLM

ollama pull ministral-3:8b
ollama serve

⚙️ Generation

bin/console app:generate-shape "Create a house"

Useful Options

-o house.rb        # sauvegarde du script
--spec design.json # sauvegarde du design
-v                 # debug complet

🧠 12. What you really need to remember

❌ This is not:

“How to use AI”

✅ It is:

👉 How to structure an idea so that an AI can execute it

🔁 Final Model

idée
 → tâche
 → design
 → code
 → exécution

🚀 Conclusion

The future of development is not:

write more code

But :

structuring ideas
and orchestrate their execution

👉 At Darkwood:

we are not trying to go faster

we are trying to be fairer

🎨 Darkwood v1.0.4 - Présentation du design V4

Mathieu Ledru — Mon, 16 Mar 2026 12:29:36 +0000

Darkwood v1.0.4 est maintenant disponible.

Cette version introduit Design V4, la quatrième itération visuelle majeure de Darkwood.

Pour les nouveaux lecteurs, voici deux idées de versionnage différentes :

v1.0.4 est la version du logiciel
Design V4 est la quatrième évolution de l'interface de Darkwood
Au fil des ans, Darkwood a connu plusieurs itérations de conception :

V1 se concentrait sur la première identité visuelle
V2 a exploré de nouvelles orientations de mise en page
V3 a affiné la marque et la structure globale
V4 remanie la navigation sur l'ensemble du site
Cette version n'est donc pas « Darkwood version 4 » au sens du terme. Il s'agit de la version 1.0.4, qui introduit Darkwood Design V4.

Et c'est important, car cette mise à jour ne se limite pas à une simple amélioration visuelle. Elle modernise également l'infrastructure technique et ouvre Darkwood aux flux de travail basés sur l'IA.

Notes de version : https://github.com/darkwood-com/darkwood-com/releases/tag/v1.0.4

Qu'est-ce que Darkwood ?
Darkwood est un jeu tactique axé sur les API.

Il est conçu comme les deux :

un système de jeu jouable
un terrain de jeu technique
une application Symfony conçue pour l'expérimentation à long terme
L'idée de base est simple : le gameplay ne doit pas dépendre entièrement de l'interface graphique.

L'interface utilisateur est importante, mais la logique du jeu réside avant tout dans l'API.

Cette approche a été décrite précédemment ici : https://blog.darkwood.com/article/darkwood-building-an-api-first-tactical-game

Cette version s'inscrit dans cette continuité.

Darkwood combine désormais :

une interface repensée
une pile PHP mise à jour
et intégration MCP pour les agents d'IA
Pourquoi concevoir V4 ?
Au fil du temps, Darkwood a accumulé des couches.

Des pages ont été ajoutées. Les expériences ont été intégrées. Navigation étendue.

Le résultat était fonctionnel, mais pas toujours clair.

La version 4 de Design se concentre sur un objectif principal :

Redonner au navigateur un aspect naturel.

Le changement le plus important entre la version V3 et la version V4 ne réside pas dans la marque elle-même. Il s'agit de la manière dont les utilisateurs naviguent sur le site.

Les versions précédentes portaient principalement sur la mise en page et l'identité visuelle. Celui-ci concerne l'architecture de navigation.

La nouvelle conception a d'abord été explorée avec Pencil, ce qui a permis d'accélérer les études d'interface et les décisions de mise en page avant la mise en œuvre.

Elle bénéficie également directement des leçons apprises lors de la construction d'Uniflow.

Chez Uniflow, un travail considérable a été consacré à l'amélioration de la clarté des menus sur ordinateur et mobile. Cette expérience a contribué à façonner le nouveau modèle de navigation de Darkwood.

Une bonne façon de résumer cet état d'esprit est :

Penser macro, agir micro.

Au niveau macro, la plateforme a besoin d'une structure claire. Au niveau micro, chaque interaction doit rester simple.

Voilà l’esprit qui anime le design V4.

Qu'est-ce qui a changé dans l'interface ?
Une nouvelle structure de navigation
Le changement le plus visible concerne la navigation.

Darkwood utilise désormais une navigation centrée en haut au lieu de l'ancienne structure latérale.

Le site est organisé autour de quatre sections principales :

Jouer - accéder au jeu tactique
Monde - explorez l'univers et son contexte
Journal - Consultez les articles techniques et les notes de développement
Projets - Découvrez des expériences et des travaux connexes
Cela rend la plateforme plus facile à comprendre au premier coup d'œil.

Au lieu d'être fragmentée, l'expérience est désormais organisée autour de quatre points d'entrée clairement définis.

La même logique est utilisée sur ordinateur et mobile, la navigation reste donc cohérente quel que soit l'appareil.

Une tête plus légère
L'en-tête a été repensé pour paraître plus léger et plus réfléchi.

Elle reste disponible pendant le défilement, mais avec un poids visuel réduit.

Le but n'était pas de le rendre plus décoratif. L'objectif était de le rendre plus utile.

Un pied de page remanié
Le pied de page a également été restructuré.

Elle permet désormais de regrouper le contenu plus clairement tout en restant secondaire par rapport à la page elle-même.

L'objectif était d'améliorer l'orientation sans que le pied de page ne domine l'expérience de lecture.

Un système visuel plus cohérent
La version 4 de Design introduit également un nettoyage plus global du site :

espacement amélioré
Hiérarchie de boutons plus claire
meilleure navigation mobile
Expérience de connexion améliorée
Comportement de mise en page plus cohérent
Il ne s'agit pas d'une refonte radicale. Il s'agit d'un passage de cohérence à travers l'expérience complète.

Construit avec une pile mise à jour
Cette version met également à jour les fondements techniques de Darkwood.

Darkwood fonctionne désormais avec :

PHP 8.5
Symfony 8
FrankenPHP v1.12.1
Il comprend également :

Migration des contrôleurs des annotations vers les attributs PHP
Configuration Nix et CI mise à jour
Mise à jour des recettes et de la configuration du framework
Corrections de dépréciation concernant le groupe d'exceptions Darkwood IA
Renforcement de la sécurité en production sur plusieurs points, notamment le référencement naturel, Castor, la sérialisation des utilisateurs, reCAPTCHA et l'intégration optionnelle de Baserow
L'objectif est simple :

Maintenir la plateforme à jour, rapide et facile à maintenir.

Pas par mode. Pour sa durabilité.

Darkwood devrait pouvoir se développer sans rencontrer de difficultés techniques évitables.

Intégration MCP pour les flux de travail d'IA
Cette version ajoute également l'intégration de l'outil MCP grâce aux nouvelles capacités d'IA de la plateforme API.

Référence: https://les-tilleuls.coop/blog/sortie-dapi-platform-4-3-rencontre-avec-lia

Cela correspond naturellement à l'approche « API-first » de Darkwood.

Si la logique du jeu existe déjà sous forme d'API, l'exposer à des agents d'IA devient une extension de la même philosophie.

Autrement dit, le jeu tactique était déjà programmable. Il est désormais également prêt pour les agents.

Outils MCP de DarkwoodGame
La ressource API DarkwoodGame expose désormais quatre outils MCP :

get_darkwood_state Renvoie l'état actuel du jeu

darkwood_action Exécute une action de jeu à partir d'une entrée

list_darkwood_archives Liste des captures d'écran archivées des puzzles pour les utilisateurs premium

get_darkwood_archive Récupère une archive par identifiant pour les utilisateurs premium

Tous utilisent une sortie de contenu structuré, ce qui signifie que la réponse de l'API est directement renvoyée sous forme de sortie de l'outil MCP.

Aucune nouvelle route HTTP n'a été introduite pour cela.

La couche MCP expose simplement les capacités API existantes de manière à ce que les agents d'IA puissent les exploiter sans problème.

Outils MCP de l'article
Les articles de Darkwood sont désormais également accessibles via MCP.

Deux outils ont été ajoutés :

list_articles
get_article
Cela permet aux agents d'IA de récupérer des données structurées d'articles tout en conservant les mêmes règles de sécurité que la ressource API elle-même.

Là encore, l'objectif n'est pas de dupliquer l'application. Il s'agit de rendre le système existant accessible via une nouvelle couche d'interaction.

Gratuit vs Premium
Darkwood est actuellement en cours de développement en Bêta Saison 0.

La proposition commerciale reste inchangée.

Deux types de clés d'accès sont disponibles.

🎟 Accès bêta (gratuit)
Clé API personnelle
Actions quotidiennes limitées
Accès à l'état jouable actuel
Accès aux archives impossible
💎 Fondateur Premium
Clé API personnelle
Actions quotidiennes illimitées
Accès aux instantanés archivés des puzzles
Statut de soutien précoce
Les archives sont des instantanés en lecture seule des états jouables antérieurs. Ils permettent de révéler l'état historique du jeu sans affecter la partie en cours.

Édition limitée pour les fondateurs
Cette version reste volontairement confidentielle.

Disponible dès maintenant :

5 clés d'accès bêta
5 clés Fondateur Premium
C'est tout.

Il ne s'agit pas d'un lancement destiné au marché de masse. Il s'agit d'une version contrôlée destinée à valider le modèle.

L'accès est géré par Bonzai :

Accès bêta (gratuit) https://www.bonzai.pro/matyo91/shop/yDxv_7247/darkwood-api-beta-access-free

Fondateur Premium https://www.bonzai.pro/matyo91/shop/lQxn_7249/darkwood-api-founder-premium

Chaque clé est personnelle et peut être changée si nécessaire.

Ce que cette publication signifie réellement
Darkwood v1.0.4 est une version qui poursuit trois objectifs :

rendre l'interface plus facile à naviguer
Mettre à jour l'architecture technique selon les normes modernes
Étendre le modèle de jeu basé sur les API aux agents d'IA via MCP
Le design V4 correspond à la partie visible.

Mais en coulisses, le projet se consolide et s'ouvre également.

On peut désormais aborder ce même jeu tactique par le biais de :

le site web
l'API
et les flux de travail pilotés par l'IA
Cette continuité est importante.

Darkwood ne se divise pas en idées distinctes. Cela devient plus cohérent.

Découvrez la version
Darkwood v1.0.4 est disponible.

Il apporte Design V4, une pile Symfony et PHP modernisée, et une intégration MCP pour le jeu tactique axé sur les API.

Explorez l'interface. Lisez le journal. Accédez à l'API. Ou commencez à jouer.

Libérer: https://github.com/darkwood-com/darkwood-com/releases/tag/v1.0.4