Website | Source

Catalog-hosted path expressions over typed API graphs, with session-scoped opaque symbols, dry-run execution plans, and federated multi-API sessions.

Camp: Orchestration
Also spans: Syntactic
Author: Ryan Roberts
Implementation language: Rust
Compilation target: Native binaries (HTTP/API execution plans)
Licence: Business Source License 1.1 (Change Date 2030-04-24, Change Licence Apache-2.0)
First seen: April 2026
Maturity: working compiler

Agent tooling:
- AGENTS.md
- CLAUDE.md
- SKILL.md
- MCP server (plasm_context, discover_capabilities, plasm, plasm_run)
- plasm CLI client (init, search, context, run)
- Teaching TSV (session symbol map)

Key idea

APIs are authored as typed capability graphs (CGS); agents write compact
path-expression programs against a live teaching table of opaque e#/m#/p#/r#
symbols instead of memorising vendor JSON schemas. Programs lower to
reviewable execution plans (dry-run before live HTTP), with federated
sessions keeping one append-only symbol space across multiple catalogs.

Thesis

Plasm treats the agent integration problem as a language and plan problem, not a transport problem. MCP and HTTP give agents a common way to call tools; Plasm asks what typed domain those calls should compose over. APIs are authored as Capability Graph Schemas (CGS): entities, relations, queries, searches, and declared effects mapped to real HTTP or GraphQL via CML templates. Agents do not memorise OpenAPI field names per vendor — they copy opaque e# / m# / p# / r# symbols from a live teaching table (TSV) and write path-expression programs that the runtime type-checks and lowers to an execution DAG.

Plan before live HTTP. The same program string is reviewed dry-run, then executed live. Agents reach that flow through two execution environments: Streamable HTTP MCP (plasm_contextplasmplasm_run, server-held session and teaching TSV) and the plasm CLI client (initsearchcontextrun against a remote HTTP host, with the client-owned symbol table under .plasm/). Both compile the same surface language to the same plan IR; they differ in transport and where session symbols are authoritative.

What it looks like

issues = e1{p46="open"}.page_size(50)
labels = issues.r3
report = labels[p50] <<RPT
{% for r in rows %}{{ r.p50 }}
{% endfor %}
RPT
sent = e1.m13(p91=report.content)
issues, sent

Symbols are session-local: e1 might mean GitHub Issue in one federated session and Linear Issue as e2 when both catalogs are seeded. The grammar rules are stable; the vocabulary is catalog-parameterised (like SQL over a schema). Canonical surface spec: Plasm language definition.

Distinctive moves

Maturity

Open-source workspace PlasmTools/plasm-core, Rust compiler/runtime, v0.1.x releases. Conformance is an executable plasm_language_matrix e2e suite (parse → DAG → dry → live Hermit) against dedicated fixtures — not production API catalogs. Dozens of packaged API catalogs (GitHub, Linear, Notion, …) ship as CGS + mappings. The Additional Use Grant under Business Source License 1.1 permits personal and internal-infrastructure use but excludes competing execution-as-a-service products; the four-year Change Date converts the licence to Apache-2.0 on 2030-04-24. A Lean-oriented formal sketch exists in the language definition; it is not a complete verification story — camp fit is orchestration with syntactic secondary (symbol tuning), not SMT/refinement typing.

Agent tooling

Plasm ships two agent execution environments for the same language:

Authoring and eval: root AGENTS.md, CLAUDE.md, and the plasm-authoring skill suite for CGS catalogs; plasm-eval for NL conformance against the teaching table. plasm-server / plasm-mcp provide the HTTP + MCP listener; plasm-repl remains a local schema debugger, not the remote agent path.

Design constraints

Compared to Code Mode-style "write code against one API," Plasm optimises for multi-catalog row workflows under governance: typed graphs, composable row sets, and reviewable plans rather than an unconstrained sandbox script.

Design DNA


Tags: language   ai   orchestration   syntactic  

Last modified 21 June 2026