Pipelex

Pipelex's pitch is unusual in this category: it doesn't argue that agents are good enough, it argues that generic agent skills lack types and validation. The homepage hr_screening.mthds example shows exactly what that means in practice. You declare a Criterion concept with a name, a description and a required numeric weight 1-10; you declare a Scorecard with a job_title, a list of required_skills and a list of Criterion refs; you declare a CvEvaluation whose fit field is constrained to choices = ["yes", "no"]. None of that is prompt text — a malformed CV scorecard fails at validation, not after a 40-page extraction job has already burned tokens. The orchestration model is straightforward and worth understanding before you commit: screen_candidates is a PipeSequence taking a Document and a Document[] of CVs, calling extract_job_offer (a PipeExtract with model "@default-text-from-pdf"), then build_scorecard (a PipeLLM returning a Scorecard, run with model "$writing-factual"), then evaluate_cv with batch_over = "cvs" — the fan-out over the CV list — before pipeline boundaries. Each evaluate_cv is itself a nested sequence: extract_cv, score_cv, route_by_fit. That's a two-level structure in one file, with named result bindings (job_pages, scorecard, results) rather than implicit state. Two things stand out as real strengths. First, the model is selected per step with a symbolic alias — "$writing-factual" for scoring prose against a rubric, "@default-text-from-pdf" for extraction — so the choice of model lives in a reviewable line of the method instead of buried in Python config. Second, the whole method is a file. You diff it, you review it in a pull request, you keep it next to the app code it supports. For regulated or audited work that's the entire value proposition. The weaknesses are honest and not small. MTHDS is a custom DSL. Python-first teams will look at the configuration surface above and reasonably ask why this isn't a YAML or a decorator library, and there's no answer that beats "it validates and compiles." The ecosystem around Pipelex is the reference implementation's own — the community surfaces in the seed data are Discord and GitHub, and the enterprise connector catalog you'd get from n8n simply isn't the shape of this product. The blog arc from March 2026 ("Why Multi-Step AI Workflows Need a New Language") through May 2026 ("From Spec-Driven Development to Compilable Specs") shows where the team is putting weight: MTHDS as an open standard plus a compiler, with Pipelex as the MIT-licensed runtime underneath. That's a coherent bet. If it lands, the .mthds artifact becomes portable in a way that a Python graph definition never is. If it doesn't, you've adopted a language for a runtime you're betting on. Consider it seriously for document-heavy, rules-stable pipelines — KYC bundles, contract review, CV screening — where run-to-run consistency is the requirement and not a nice-to-have. Look elsewhere if your workflow changes weekly, or