StackMap
Subscribe

Guardrails vs plano

NVIDIA's programmable guardrails for LLM apps: input, output, dialog and retrieval rails defined in Colang, wrapping any model or LangChain runnable. — versus — AI-native Envoy-based proxy for agentic apps: agent orchestration via a 4B routing model, smart LLM routing, guardrail filter chains and zero-code OTEL traces. Rust, framework-agnostic.

The curated verdict

Two places to enforce guardrails: NeMo Guardrails runs Colang rails in-process around a model or chain, Plano enforces moderation/jailbreak filters at the proxy so every agent inherits them without code changes.

Guardrailsplano
Stars6.7k6.9k
Forks771469
LanguagePythonRust
LicenseNOASSERTIONApache-2.0
Last activitytoday3 days ago
Topicssecuritygateway, orchestration
Curated connections44

Guardrails — the curator's take

For when policy needs to be programmable, not a blocklist: topic bans, jailbreak checks, tool-use constraints and dialog flows written in Colang, enforced as input/output/dialog/retrieval rails around any LLM — RunnableRails drops it straight into a LangChain pipeline. NOT free at runtime: every rail is extra LLM calls and latency, Colang is its own language to learn, and rails mitigate rather than guarantee — you still red-team the result (that's garak's job).

plano — the curator's take

Reach for it when multi-agent code is drowning in hidden middleware — intent routing, provider quirks, guardrail hooks, tracing glue. Plano moves all of that out-of-process: agents are plain OpenAI-compatible HTTP servers in any language, orchestration is YAML plus a purpose-built 4B router model. NOT for a quick single-agent demo (it adds an infra hop and Envoy operational surface), and note the catch: the hosted Plano-Orchestrator LLM is free-tier only — production means running the routing models yourself or getting API keys. If you only need provider unification, LiteLLM is lighter.