Interesting project

[MachuraHarry]

Your project is very interesting; perhaps we could pursue a goal together. You’ve already taken a look at Pipe, and you’re clearly working with AI agents as well. Feel free to get in touch.

[baokhang83]

Thanks! What is your background? I have 20 years of XP in Software development (Java/JVM). Interested, Pipe looks also interesting. Did you make use of it yet somewhere?

[MachuraHarry]

Thanks for getting back!

My background is in systems programming — C, C#, Java, and now Go. I built Pipe from scratch (lexer, parser, AST, compiler, bytecode VM, LSP, the whole thing) because I was tired of writing 80 lines of Python boilerplate for a 5-line LLM pipeline.

I used AI heavily as a development accelerator while building it, but the core design is intentional: pipeline syntax that reads like a reasoning chain, declarative sandboxing at the language level, and AI operations as first-class primitives — not library calls.

The syntax is deliberately minimal (around 20 keywords, no braces, indentation-based like Python). That makes it readable for humans, but it also means AI coding assistants learn it quickly and generate correct code with fewer hallucinations.

Pipe isn't meant to replace Python. It's a specialized runtime for AI-native infrastructure: automated workflows, sandboxed agents, RAG pipelines, and CI/CD. I'm on v0.7, dogfooding it daily for my own AI tasks, and looking for people who want to push it toward real production use.

Your 20 years of JVM experience plus your work on FluencyLoop would be incredibly valuable. I'd love to hear your perspective on whether a lightweight, sandboxed runtime like Pipe fills a gap you've seen in the agent space.

Up for a quick exchange ideas here?

[baokhang83]

Impressive :)
You're welcome, yes let's brainstorm here.

Since you mention automated workflows I definitely see it integrated into skills in a similar fashion FluencyLoop calls scripts for token efficiency.

Actually speed and token efficiency could be an angle? Can it compute complex output already? In a similar way AI Agents invoke python. Or does it need several other functions?

[MachuraHarry]

Thanks!
To clarify the first point: Pipe doesn't generate Python. It's its own language with a bytecode VM. You write "read_file > classify > summarize" and Pipe executes it directly, no Python intermediary.

On missing functions: you're right, it's not complete yet. The core is there (114 builtins, VM, tests), but it lacks modules for real-world backend work — no Postgres, no Redis, no HTTP server. For AI-only pipelines it's ready. for complex orchestration, those connectors are the gap.

Re: token efficiency — absolutely. 20 keywords, linear pipelines, no braces. An LLM agent needs way fewer tokens to generate correct Pipe code than Python, and the built-in sandbox prevents escape hatches by default.

How does FluencyLoop execute generated code today? Direct Python/JS, or through a sandboxed layer?

[baokhang83]

It's the skill that tells the model what to type: check my SKILL.md files.
Then there is the fluencyloop dispatcher: a bash script (plugins/fluencyloop/fluencyloop) which routes to the other scripts.

Let me gather further thoughts I come back to you :)

[baokhang83]

Hey,
I looked at Pipe with FluencyLoop's constraints in mind, and I want to be upfront about where I land: FluencyLoop's whole pitch is "just Claude/Codex skills, nothing else to install." Any integration that requires a second LLM provider (even a local one via Ollama) breaks that promise for users who just want the managed skill experience. So I don't think the AI-op side of Pipe (summarize, classify, embed, etc.) is a fit here, that would make Pipe a hard dependency with its own model to configure and reconcile against FluencyLoop's own teaching, which isn't a trade I want to make right now.

Where I do see a legitimate case is the deterministic side of Pipe: exec, read_file, match, sandbox profiles, used with ai: false. FluencyLoop currently maintains its plumbing scripts twice: once in bash (scripts/bash/), once in PowerShell (scripts/powershell/), and they have to match behavior and JSON output exactly. That's already caused at least one real bug (a stdout-redirection mismatch that broke ConvertFrom-Json in CI). If Pipe could replace that dual-tree with one script that produces byte-identical JSON on Windows/macOS/Linux, and its sandbox profile actually enforces exec: false / network: false rather than just declaring it, that would be a real win: "Pipe deletes a whole maintenance burden and adds a security property I can't get from bash/PowerShell alone."

Concretely, for now would you be up for porting one script: say slice-context or index (both live under plugins/fluencyloop/scripts/) to a Pipe script running under a sandbox profile with ai: false, network: false? If it produces identical output across platforms from one source, and the sandbox genuinely blocks a stray exec/network call rather than just declaring intent, that's a strong enough case for me to look at adopting Pipe as a build-time dependency for that layer.

I'd rather validate on one real script than commit to an architecture.
Let me know what you think :)