Why a new format instead of Python?

Agents need a format they can reliably generate and execute — not free-form code. .mthds files are declarative, deterministic, and portable: agents write them, humans review them, Pipelex runs them. Python stays in the runtime; the method definition stays agent-readable.

What is the MTHDS standard?

MTHDS is an open standard for defining, packaging, and distributing AI methods. It has two pillars: the Language (typed concepts, pipes, and domains in .mthds files) and the Package System (versioned dependencies, lock files, cross-package references, and a federated registry at [mthds.sh](https://mthds.sh)). The standard is maintained at [mthds.ai](https://mthds.ai) and anyone can implement a runtime. Pipelex is the reference implementation.

Can other runtimes implement MTHDS?

Yes. MTHDS is an open standard with a public specification, not a proprietary format. Any platform can parse .mthds files, validate typed signatures, and execute methods. Pipelex is the reference runtime, but the standard is designed for broad adoption — your methods are never locked to a single tool.

How does Pipelex compare to LangGraph, Mastra, Pydantic AI?

Those are code-first frameworks with proprietary formats — humans write Python or TypeScript. Pipelex implements the MTHDS open standard: a portable, typed language with a real package system. Your methods aren't locked to any runtime.

How does Pipelex compare to n8n, Make, Workato?

GUI-based platforms lock methods in their ecosystem. MTHDS methods are plain-text files — version them in Git with semantic versioning, compose them across packages with cross-package references, deploy them anywhere.

Is Pipelex an agent framework?

No. Pipelex provides deterministic methods that agents call as tools via MCP or API. We make agents reliable at repeatable business tasks — we don't replace your agent stack.

When is Pipelex the right choice?

Repeatable, deterministic AI tasks: invoice processing, contract analysis, report generation, compliance review. If it needs consistent results at scale, Pipelex fits. Not designed for creative exploration or open-ended tasks.

Is it really open-source?

Fully. The MTHDS standard and Pipelex runtime are MIT-licensed. The open-core model means enterprise features (managed cloud, advanced observability, certification) are commercial, but the runtime and the standard stay open.

Viewpoint: The Know-How Graph

Why AI Agents Need the MTHDS Open Standard, and What Happens When They Get It

By Louis Choquel, Co-founder & CTO, Pipelex

Originally published: November 2025

Updated: February 2026 — revised to reflect the emergence of Agent Skills and the evolving agent ecosystem

TL;DR

Skills gave agents reusable guidance: portable, natural-language instructions that steer behavior. But they have no types, no validation, no guaranteed output structure. That's why we built MTHDS: an open standard for typed, validated AI workflows with deterministic orchestration, that agents can build, execute, and share. At scale, typed methods connect to form the Know-How Graph: a navigable network of reusable, composable AI know-how that becomes shared infrastructure.

Skills guide intent, not execution

Skills are a great tool to control agents: portable, natural-language instructions that guide behavior. But they're just text injected into prompts. The agent reinterprets them at every invocation: different reasoning paths, different output shapes, limited control over structure. Skills guide intent. They don't guarantee execution.

Today's most advanced harnesses like Claude Code and Codex keep agents working on complex tasks by providing context lifecycle, checkpoints, verification gates, tool execution. But deterministic orchestration and validated outputs? That still requires code. What's missing from this picture: a declarative, portable way to capture a proven method as a typed, validated artifact that runs the same way every time.

Three Ways to Build AI Workflows Today — All Inadequate

Teams everywhere are building AI workflows to extract data from contracts, process expense reports, classify documents, screen resumes. Identical problems solved in isolation. The options they face all have serious trade-offs.

Code (custom Python, frameworks) gives full control: typed outputs, version control, testing. But the 100 lines that capture your actual business logic are buried in 2,000 lines of plumbing. Every workflow is bespoke, nothing composes, and the domain expert who owns the logic cannot read or iterate on it.

Skills and prompts are the opposite. Anyone can write them in minutes. Human-readable, progressively complex. But there is no structure, no validation, no typed outputs, no guaranteed repeatability. You ship a prompt and hope.

Automation platforms (Zapier, Make, n8n) are good at what they're built for: connecting APIs and automating data flow between services. But they are not cognitive workflow systems. AI was bolted on after the fact. When you need multi-step cognition (extraction, analysis, synthesis, reasoning, decision making), these tools quickly become unwieldy.

Code expresses technical plumbing, not business logic. Skills express intent without guarantees. Visual builders express data routing, not cognitive work. What's missing is a common language between code and Skills: structured enough to validate, conceptual enough for any stakeholders to read, and explicit enough for agents to build and execute reliably.

We Need a Language for AI Methods

AI workflows should be first-class citizens of our technical infrastructure: not buried in code or trapped in platforms, but expressed in a language built for the job. The method should be an artifact you can version, diff, test, and optimize.

The Language must be Declarative and conceptual

We need a declarative language that states what you want, not how to compute it. SQL separated intent from implementation for data. We need the same separation for AI workflows.

But it must go further. Thanks to LLMs, machines can now grasp your intent, which opens the door to a fundamentally different way of defining workflows. The right abstraction level is the business domain itself. An Invoice is a declared concept with an explicit definition: what it means, what it contains, why it matters. A NonCompeteClause is not just "some text from a contract"; it is a concept you define once, with its purpose and characteristics spelled out in the language itself, not in a comment or a README or someone's head. That declaration is what removes ambiguity.

A method is the documentation, except it's also executable. A business expert reads it and sees the logic of their domain. An engineer reads it and sees something they can validate, test, and deploy. An AI agent reads it and sees something it can build, modify, and execute. One artifact, three audiences, no translation required.

Imagine agents that transform natural-language requirements into working methods. They design each transformation step (or reuse existing ones), test against real or synthetic data, incorporate expert feedback, and iterate to improve quality while reducing costs.

This is how agents finally retain know-how: by encoding what works into conceptual methods they can build, share, and execute on demand.

The Language must be Structured

When concepts also carry typed structures, the language gains capabilities that text-only instructions cannot support.

Validation before runtime. A JobDescription and a CandidateProfile might both be strings under the hood. No traditional type checker flags the swap. But feeding a candidate profile where a job description is expected is a semantic error, and in an AI workflow, the result isn't a crash. It's confident, plausible, wrong output. On the contrary, concept-level typing surfaces that mistake at design time, long before you hit production.

Discovery and composability. Every method carries a typed signature: declared input and output concepts. That makes methods queryable, composable, and verifiable at design time. When an ecosystem of typed methods exists, something more powerful emerges.

The Know-How Graph: A Typed Network of Composable Methods

Each method should stand on the shoulders of others, composing like LEGO bricks to build increasingly sophisticated cognitive systems.

What emerges is a Know-How Graph: not just static knowledge, but executable methods that connect and build upon one another. Unlike a knowledge graph that maps facts, this maps procedures: the actual know-how of getting cognitive work done.

Every method has a typed signature: declared input concepts and output concepts. This makes the graph machine-readable in a way that text-based systems cannot match.

Type-driven discovery. "I have a Contract, I need a NonCompeteClause" becomes a structured lookup across all published methods, matching input and output concepts. Not keyword search. Not description matching. Concept-compatible resolution across the entire ecosystem.

Auto-composition. When no single method bridges the gap, you find a path through the graph. One method produces a RiskAssessment from a LoanApplication. Another produces an UnderwritingDecision from a RiskAssessment. The system verifies that the two connect cleanly at design time. Compatibility is provable, not assumed. You get pathfinding in conceptual space.

Know-how is as shareable as knowledge

Think about the explosion of prompt sharing since 2023 — all those people trading their best ChatGPT prompts on Twitter, GitHub, Reddit. Then Agent Skills took it further: portable capability bundles that work across agent environments, shared like dotfiles, forked like repos, with real ecosystem effects already emerging. Now imagine that same viral sharing, but with complete, tested, composable, typed workflows instead of fragile prompts or unstructured instructions.

Software package managers, SQL views, Docker images, dbt packages: composable standards create ecosystems where everyone's work makes everyone else more productive. Methods are designed for the same pattern. Common tasks get solved once and shared openly. The workflows that give your company its edge? That's your secret sauce, and it stays private. Open commons, proprietary layers on top.

The MTHDS Open Standard

MTHDS is an open standard for defining, packaging, and distributing AI methods as typed, composable, human-readable files.

A .mthds file captures a method in plain TOML: declared concepts as inputs and outputs at every level, from the method itself down to each processing step, where each step can tap into the cognitive power of any AI model or run as pure deterministic logic. Orchestration is explicit: sequences, conditions, batches, parallel branches.

A METHODS.toml manifest turns a collection of .mthds files into a distributable package with dependencies, version constraints, and exports. Distribution is federated: packages live in Git repositories, registries provide discovery.

Like Skills, MTHDS files live in directories, are Git-native, and scale from personal use to enterprise deployment. Unlike Skills, they carry typed structure, validated outputs (JSON), and deterministic orchestration.

MIT-licensed. Designed for portability. The method outlives any vendor or model version.

mthds.ai | github.com/mthds-ai

Pipelex: The Reference Runtime

Pipelex is the open-source reference runtime for the MTHDS standard. It reads, validates, and executes .mthds files, and ships as a runtime, CLI, Claude Code plugin, cookbook, and documentation.

github.com/Pipelex/pipelex | docs.pipelex.com

Join Us

Start with one method: extract invoice data, process applications, analyze reports. Share what works. Build on what others share. The future of AI needs both: Skills that give agents latitude to explore and adapt, and typed methods that guarantee execution when the output matters. They are complementary.

If this Viewpoint resonates, please share it.

Licensed under a CC BY 4.0 license.

Agents + MTHDS = The Know-How Graph

MTHDS Standard | Pipelex Runtime | Documentation | Discord