Robin Honnart

Hey DevHunt! We built Pipelex because we kept rewriting the same agentic patterns across projects. Instead of more glue code, we modeled *meaningful* steps that both humans and LLMs can read and execute like Dockerfile/SQL for AI workflows. What’s included - Python library for local dev - FastAPI server + Docker image (self-host) - MCP server (agents can *run* and even *build* pipes) - n8n node for automations - VS Code / Cursor extension (PLX syntax) What we’d love feedback on 1. Does the PLX syntax help you model your use case? 2. Agent/MCP workflows & n8n node devX. 3. Missing pipe types / model integrations. 4. OSS contributions (core + community pipes). Known limitations - Connectors: we focus on cognitive steps; bring your own app/API (or MCP/n8n). - Visualization: flow-charts WIP. - Pipe builder can fail on very complex briefs; we’re adding recursion. - No hosted API yet (on the way). - Cost tracking: LLM only for now. - Caching & reasoning options: not yet. Thanks for trying even one workflow and telling us exactly where it hurts — that’s the most valuable feedback.

If you want to use Pipelex IRL, we're hosting a Hackathon in San Francisco on Wed 10/29 Register to attend : https://luma.com/4jwfaw71