Plasm — Typed API plans for agents

01 · LANGUAGE

Catalogs define meaning. Plans make data movement inspectable.

Agents stay in catalog vocabulary—including field labels and action semantics—so Plasm can validate plan shape, check how data flows before any live credentials are used, and compile approved work into real API calls with an inspectable trace.

plasm.session · workspace

Planning language

What agents author.

Programs bind entities, fields, and actions from your catalogs—the same vocabulary the planner type-checks—across every API you wire in, not vendor JSON pasted into the prompt.

# workflow (session verbs)

discover · add context · compile plan · check flows · run

# catalog slice (illustrative)

Repository, Issue, PullRequest, User

# field & flow context (catalog-backed)

issue.body · data_class: untrusted

slack.postMessage · destination: external_send

# Plan Security (hosted rules)

forbidden · untrusted → external_send

MCP-native integration

One contract exposed to your agent through MCP. Whatever model your host runs, it talks to Plasm through the same MCP surface.
Versioned catalogs

Promote, diff, and ship catalog revisions like product code.

plan → APIs · trace

Compiled plan

From typed intent to live calls.

A compiled plan is the artifact between language and API calls: validated reads/writes, normalized rows, flow checks against your rules, and an execution trace—not a shell transcript.

plan · issue_triage · state · flow_check_failed

surface loaded · Issue, Repository, SlackChannel

reads · issues.search · repo.metadata.get

normalize · rows[id, title, assignee.login]

flow · untrusted body → external_send · blocked

write · slack.postMessage · does not run

trace · proposed, checked, and executed steps

Authn, pagination, retries

Built in behind the plan. No per-provider glue code in your agent prompt.
Review before run

See the plan, the field flows Plasm checked, and what rules allowed or blocked—before live credentials are used. Traces stay inspectable after run.

02 · MAPPINGS

Autonomously authorable API mappings—in a real language.

Integration is not “the model wrote some glue.” Plasm is a constrained language for API mapping: semantic catalogs plus explicit wire templates. Agents can draft and iterate from OpenAPI and docs; humans diff, review, and promote before anything touches production—same operational muscle as agent-native tooling like Printing Press, with typed surfaces and audit trails instead of unconstrained scripts.

01 / teaching table

CGS

What exists and what agents may do.

Entities, relations, capabilities, and field semantics—the business contract the model reasons over. Authored and versioned like product code, not pasted endpoint prose.

02 / WIRE

CML

How calls compile to HTTP, GraphQL, and more.

Vendor churn stays behind the mapping boundary. The planning language and catalog vocabulary your agent sees stay stable while backends evolve.

03 / OPS

Review

Safer than generic agent-generated software.

Catalogs declare what fields mean and where actions send data, so plans are reviewable artifacts with stable semantics—not opaque tool calls. Flow checks run before execution; blocked plans do not run.

03 · OUTCOMES

Reliability you can ship.

Typed planning plus bounded mappings means fewer retries, leaner tool surfaces, and plans worth reviewing—including how sensitive fields move through multi-step work. The runtime parallelizes independent reads and keeps agent-visible payloads tight.

01 / RETRIES

Preflight

Fewer model retries.

Preflight validation rejects bad calls before they hit your backend, so the model isn't burning tokens recovering from its own mistakes.

02 / TOOLS

5×

Smaller tool descriptions vs JSON.

In typical packaged setups, Plasm tool descriptions are about 5× smaller than equivalent JSON tool schemas—compact catalog actions instead of pages of parameters and examples.

03 / REVIEW

Readable

Plans worth reviewing.

Multi-step work surfaces as plans you can read and check. See which fields flow where, what rules allow or block, and what ran—with traces instead of log archaeology.

04 · HOW IT WORKS

Operational loop: author mappings, run plans.

You extend coverage the same way you ship other infra: domain (what exists) and mappings (how wire calls work) evolve together. Agents draft from specs and docs inside Plasm’s mapping language; reviewers promote revisions. The runtime compiles agent plans against that surface—vendor churn stays in CML, not in the model’s head.

01

Author the semantic catalog (CGS).

Entities, relations, capabilities—the typed contract agents plan against. Iterated from OpenAPI and docs, then validated—not a wall of raw JSON tools in the prompt.

02

Wire mappings (CML) to real backends.

REST, GraphQL, gRPC, internal services. Explicit templates per capability—auth, pagination, decoding, and rate limits live behind the mapping boundary.

03

Connect over MCP.

Today Plasm speaks MCP. Register it from your agent framework or dev host: production stacks (e.g. AWS Agent Core) and local IDE agents (Cursor, Claude Desktop, …) alike.

The catalog surface stays stable — you are not hand-wiring vendor tools per model SDK.

04

Check flows, review, run, trace.

Every multi-step action is a reviewable plan. Plasm checks how fields move through the plan against Plan Security rules configured in the hosted environment—or your policy snapshot locally. Blocked flows do not run. Approved work executes with full provenance.

Catalog · illustrative slice

GitHub workspace

Root entity Action / query Relationship

05 · COMPARISON

One planning language—not a connector zoo.

Most stacks still grow a fresh tool dialect per vendor. Plasm keeps one typed planning surface and one mapping language for how those plans compile to real calls—so cross-system work stays legible, reviewable, and traceable.

Dimension

Raw schema / tool stack

Plasm

Prompt surface

Large schemas, payloads and tool descriptions in every call.

Compact, typed business language. Fewer tokens for the model to wade through.

Agent contract

The model learns each vendor's params, paths, quirks.

The model works against business entities, relationships, and typed actions.

Workflow review

Multi-step work is reconstructed from tail logs after the fact.

Multi-step plans are first-class artifacts. See field flows, what rules allowed or blocked, and replay with provenance.

Cross-system work

Each integration gets its own bespoke style and failure modes.

One runtime. Same shapes across providers, with traceable joins.

Reliability

Validation failures and recovery loops happen after the model emits the call.

Typed validation and correction feedback before the call leaves the runtime.

Governance

Tool allowlists and policy bolted on after integration is done.

Field-level flow checks on typed plans before execution; blocked flows do not run. Plan Security rules live in the same catalog surface agents already use.

Integration authoring

Ad hoc scripts and opaque agent-generated glue—hard to audit and risky to ship.

Agents draft CGS + CML inside a constrained mapping language; humans diff and promote. Not arbitrary software sprawl.

System feel

Powerful, but often visibly complex at the edges.

More like a control room — one consistent agent-facing language, even when many vendor APIs run underneath.

06 · TRUST & CONTROL

Information-flow checks on the plan—not hope after the call.

Plasm is built for this: semantic catalogs carry field meaning, typed plans expose data movement, and Plan Security rules decide whether a proposed flow can run. Blocked plans do not run. Traces show what was proposed, checked, and executed.

Field flows, not tool gates alone.

Catalogs declare field labels, action semantics, and destinations. Plasm checks how data moves through the whole plan—not just whether an action name is on an allowlist.

issue.body · untrusted → slack.postMessage · external_send

Checked before execution.

Flow checks run at plan review time, before live credentials are used. If a rule blocks the flow, the work does not run—there is no silent bypass.

flow check · denied → plan does not run

Auditable mappings.

Each business action maps to explicit backend calls — so "what the agent asked for" and "what the API issued" stay connected.

issue_query → graphql.search ⨯ 1, rest.issues.get ⨯ 12

Plan Security rules.

In the hosted environment, teams configure forbidden flows, effect rules, and approvals in Plan Security—the same project surface where catalogs and MCP configs live.

forbidden · sensitive → external_send

07 · EVALUATE

If your agent has to work across your stack, start here.

Four questions to ask before you commit to another tool list. They surface most of the issues teams hit going from demo to production.

Q · 01

Evaluate the prompt surface.

How much schema, examples, and "how to call this vendor" prose are you still pasting into the prompt before the business task starts?

Q · 02

Evaluate the plan surface.

Can your users see what will be read, which fields flow where, and what rules allow or block before anything touches a live system?

Q · 03

Evaluate the mapping surface.

Are new APIs expressed as reviewable catalog + mapping artifacts—or as more bespoke scripts and tool strings only the authoring model understands?

Q · 04

Evaluate the judge in the loop.

Can a person — or LLM reviewer — gain or close a connection from a few words and a structured plan, or a buried object that is gone in disconnected tool traces?

08 · FAQ

Questions teams ask first.

Short answers to the things product engineers and ML leads check before they pick anything up.

Do I have to throw out my existing agent?

No. Plasm is a typed planning language plus a runtime, exposed as an MCP server today. If your stack already runs through an MCP-capable client, you add Plasm there; you are not locked into a single vendor’s native tool API.

How is this different from a tool registry or function-calling SDK?

Tool registries describe individual endpoints. Plasm is a planning language over a catalog contract (entities, fields, relations, capabilities) with explicit wire mappings—operationalized over time with agents drafting from docs and humans reviewing. The model plans in that vocabulary; Plasm checks how fields flow through each plan before execution, then compiles approved work to real APIs with traces.

What does this do to latency and cost?

Smaller tool prompts (about 5× smaller in typical packaged setups) and preflight rejection cut down avoidable re-prompting after bad calls. The runtime parallelizes independent work and caches safe reads where policy allows, trimming repeated round-trips. Projections and other processing in Plasm programs shape what crosses into agent context—less bulk every turn, so windows fill with signal instead of entire payloads. Exact latency and token impact depend on your workload—we avoid quoting universal benchmarks.

How do approvals work?

Sensitive work is governed at the plan level, not just per tool. Catalogs declare field meaning and destinations; Plan Security rules (in the hosted environment) define forbidden flows, required approvals, and other dispositions. Plasm checks the full plan before execution—if a rule blocks the flow, the work does not run. Human approval is one outcome when a flow needs review, not the whole safety model. Every decision stays in the trace.

Where does data live?

With the open-core runtime you control where execution runs—typically on your machine or infra for the free local tier. Hosted Plasm (preview) will add a managed option; catalogs and traces stay scoped to your environment. We never train on your data.

What's pricing like?

The operating layer is open-core with a free tier you run locally; hosted Plasm is in preview. plasm-core on GitHub or platform.plasm.tools.

Plasm turns agent work into typed plans you can check before they run.