Rivet

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Canonical URL

https://heyclau.de/entry/tools/rivet

Source URLs

https://rivet.ironcladapp.com/docs, https://github.com/Ironclad/rivet, https://rivet.ironcladapp.com/

Brand

Rivet

Brand domain

rivet.ironcladapp.com

Brand asset source

brandfetch

Safety notes

Rivet graphs can include nodes that call LLMs, run code, make HTTP requests, and call into your application's functions, so review what a graph and its nodes do before running it, especially graphs from untrusted sources., The desktop app and embedded graphs use the model-provider API keys and integration credentials you configure; scope those credentials to the minimum needed., When embedding Rivet Core in an application, treat graph inputs and node outputs as untrusted, and gate any node that performs writes or external actions., Node types that execute code or make network calls should run with least privilege and appropriate timeouts., Keep production graphs and their permissions narrower than example graphs.

Privacy notes

Running a Rivet graph sends prompts, inputs, and node data to the configured model providers and any integrated services., Nodes that call your application's code, HTTP endpoints, or data sources can pass local or workspace data into the graph and the model., Prompts, node outputs, and debugging traces in the app or your logs can retain data, so apply normal retention and access-control policies., Model-provider and integration credentials live in the app configuration or your application's environment; keep them out of version control.

Author

Ironclad

Submitted by

davion-knight

Claim status

unclaimed

Last verified

2026-07-09

• Running a Rivet graph sends prompts, inputs, and node data to the configured model providers and any integrated services.
• Nodes that call your application's code, HTTP endpoints, or data sources can pass local or workspace data into the graph and the model.
• Prompts, node outputs, and debugging traces in the app or your logs can retain data, so apply normal retention and access-control policies.
• Model-provider and integration credentials live in the app configuration or your application's environment; keep them out of version control.

• The Rivet desktop application (for authoring graphs), or Node.js and npm to embed `@ironclad/rivet-core` or `@ironclad/rivet-node` in an application.
• Model-provider API keys for the LLM providers a graph uses, plus credentials for any integrations the graph calls.
• A clear boundary for which application functions and data sources Rivet graphs may call, and vice versa, before embedding.
• A plan for how graphs are versioned, reviewed, and promoted from local authoring to production use.
• Observability and retention decisions for prompts, node outputs, and debugging traces.

Show that Rivet is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

[![Listed on HeyClaude](https://heyclau.de/badge/tools/rivet.svg)](https://heyclau.de/entry/tools/rivet)

Rivet side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

Field	Rivet Open-source visual AI programming environment from Ironclad for building, debugging, and embedding complex LLM agents and prompt-chaining graphs, with a desktop app and a TypeScript library. Open dossier	Agenta Open-source LLMOps platform for prompt management, prompt versioning, evaluation, and observability across LLM applications. Open dossier	BAML Open-source domain-specific language from BoundaryML for writing typed LLM functions with structured inputs and outputs, a VSCode playground, and generated clients you can call from Python, TypeScript, Go, and more. Open dossier	DSPy Python framework from Stanford NLP for programming language-model systems with signatures, modules, tools, metrics, and optimizers instead of hand-written prompts. Open dossier
Next steps	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing	Open dossierAPI JSONOpen LLMOpen sourceNewsletterClaim listing
Trust	Review first	Review first	Review first	Review first
Review status	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed	ReviewedMaintainer reviewed
Package trust	Package not verified	Package not verified	Package not verified	Package not verified
Source provenance	Source-backed	Source-backed	Source-backed	Source-backed
SubmitterDiffers	davion-knight	oktofeesh1	davion-knight	oktofeesh1
Install risk	Review first	Review first	Review first	Review first
Notes	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓	Safety ✓ Privacy ✓
Brand	Rivet	Agenta	BAML	DSPy
Category	tools	tools	tools	tools
Source	source-backed	source-backed	source-backed	source-backed
Author	Ironclad	Agenta	BoundaryML	Stanford NLP
Added	2026-07-09	2026-06-03	2026-07-09	2026-06-03
Platforms	CLI	CLI	CLI	CLI
Source repo	—	—	—	—
Safety notes	✓Rivet graphs can include nodes that call LLMs, run code, make HTTP requests, and call into your application's functions, so review what a graph and its nodes do before running it, especially graphs from untrusted sources. The desktop app and embedded graphs use the model-provider API keys and integration credentials you configure; scope those credentials to the minimum needed. When embedding Rivet Core in an application, treat graph inputs and node outputs as untrusted, and gate any node that performs writes or external actions. Node types that execute code or make network calls should run with least privilege and appropriate timeouts. Keep production graphs and their permissions narrower than example graphs.	✓Agenta can manage and deploy prompt or configuration changes, so production updates should go through review and rollback controls. Webhooks and GitHub automations tied to prompt or deployment changes should be scoped to trusted repositories and guarded workflows. Evaluation and online monitoring results should support, not replace, domain review for high-risk application behavior.	✓BAML functions call LLM providers using the credentials you configure, so scope those provider keys to the minimum needed and keep them out of source control. BAML generates client code that runs inside your application; review generated clients before shipping, and treat typed outputs as untrusted input for account, billing, data, or infrastructure actions. Static typing and schema validation reduce parsing errors, but they do not guarantee that a model's answer is correct, complete, or safe. The BAML CLI and VSCode extension run locally and write generated code into your project; run them in an environment where writing those files is expected. Keep production usage and permissions narrower than playground or example projects.	✓DSPy changes how language-model systems are constructed and optimized, but it does not prove that a generated answer, optimized prompt, ReAct tool action, retrieved passage, or fine-tuned model is correct or safe. Optimizers can issue many model calls, generate examples, explore instructions, tune prompts, or fine-tune model weights; set budgets, rate limits, evaluation gates, rollback rules, and review ownership before running them. ReAct modules, Python interpreter tools, function tools, retrieval tools, and MCP-converted tools can trigger external APIs, local code, file access, or business actions if wired into a program. Metrics and evaluation datasets can overfit, reward the wrong behavior, or miss safety failures; treat optimizer scores as development signals rather than production approval. Saved programs, optimized prompts, bootstrapped demonstrations, fine-tuning datasets, and experiment artifacts should be reviewed before sharing because they can encode private data or brittle task assumptions. Local model servers, provider endpoints, and LiteLLM-compatible routes need normal timeout, retry, budget, abuse, model-selection, and credential-handling controls.
Privacy notes	✓Running a Rivet graph sends prompts, inputs, and node data to the configured model providers and any integrated services. Nodes that call your application's code, HTTP endpoints, or data sources can pass local or workspace data into the graph and the model. Prompts, node outputs, and debugging traces in the app or your logs can retain data, so apply normal retention and access-control policies. Model-provider and integration credentials live in the app configuration or your application's environment; keep them out of version control.	✓Prompt records, variants, test sets, traces, model inputs and outputs, feedback, annotations, and evaluation results may be stored in Agenta. Hosted Agenta use sends that data to Agenta Cloud; self-hosted deployments still require retention, access-control, and backup policies. Review Agenta's sensitive-data redaction and retention guidance before sending production, customer, or regulated data.	✓BAML functions send prompts and inputs to the configured model providers, which process that data under their own data-handling terms. Prompt templates, test inputs, and example data can contain personal or proprietary information, so keep them and provider credentials out of version control. Generated outputs, and any logging or tracing you add around BAML calls, can retain prompts and results outside the library. Apply normal retention and access-control policies to BAML source files, generated clients, and test fixtures that include real data.	✓DSPy programs can send prompts, messages, typed inputs, retrieved context, tool arguments, generated outputs, optimizer traces, examples, metrics, and fine-tuning data to configured model providers. DSPy LM history can retain prompts, messages, call kwargs, responses, outputs, token usage, cost metadata, and related debugging information unless applications define cleanup and access controls. Caches, saved programs, optimized prompt artifacts, demonstration sets, serialized LM state, experiment logs, and evaluation reports can preserve sensitive task data outside the original source system. MCP integrations and tool calls can move user data, tool descriptions, tool arguments, and tool results into external servers, agent transcripts, provider logs, and downstream system logs. Local models reduce third-party provider exposure but can still leave data in process logs, tracing systems, prompt caches, generated artifacts, and shared infrastructure storage.
Prerequisites	The Rivet desktop application (for authoring graphs), or Node.js and npm to embed `@ironclad/rivet-core` or `@ironclad/rivet-node` in an application. Model-provider API keys for the LLM providers a graph uses, plus credentials for any integrations the graph calls. A clear boundary for which application functions and data sources Rivet graphs may call, and vice versa, before embedding. A plan for how graphs are versioned, reviewed, and promoted from local authoring to production use.	LLM application, prompt workflow, or agent workflow whose prompts and configurations need shared management. Access to Agenta Cloud or a reviewed self-hosted Agenta deployment. Provider credentials and a release policy for test sets, traces, prompt versions, and production deployment approvals.	A way to install the BAML toolchain (for example the CLI via Homebrew) and, for embedding, the language SDK such as `@boundaryml/baml` for TypeScript or `baml-py` for Python. Model-provider credentials for the LLM providers your BAML functions call. Defined input and output types for each BAML function before generating clients. A build step to regenerate BAML clients when function definitions change, and a place to review the generated code.	Python 3.10 or newer and a dependency manager for installing `dspy` and optional extras for MCP, retrieval, local models, or deployment workflows. Model provider credentials, local model endpoint, Databricks environment, or LiteLLM-compatible provider configuration for the language models used by the DSPy program. Training examples, validation examples, metrics, expected outputs, and reviewer ownership before running DSPy optimizers or using optimized programs in production workflows. Reviewed data sources, retrieval systems, tools, MCP servers, and Python execution paths before connecting DSPy modules to real files, APIs, databases, or account actions.
Install	—	—	—	—
Config	—	—	—	—
Citations	Source repositorygithub.com 2026-07-09T20:13:32+00:00 Documentationrivet.ironcladapp.com Websiterivet.ironcladapp.com Submitted by davion-knight2026-07-09 Source methodology →	Source repositorygithub.com 2026-07-09T20:13:32+00:00 Documentationagenta.ai Submitted by oktofeesh12026-06-03 Source methodology →	Source repositorygithub.com 2026-07-09T20:13:32+00:00 Documentationdocs.boundaryml.com Submitted by davion-knight2026-07-09 Source methodology →	Source repositorygithub.com 2026-07-09T20:13:32+00:00 Documentationdspy.ai Submitted by oktofeesh12026-06-03 Source methodology →
Claim	Unclaimed	Unclaimed	Unclaimed	Unclaimed

Source-backed guides for putting this to work.