NeMo Guardrails and LangChain integration

NeMo Guardrails and LangChain integration: what it adds to your application

NeMo Guardrails can be attached to LangChain through an opt-in integration, and this page covers four patterns: agent middleware for tool-calling agents, RunnableRails around an existing chain, chains used as guardrail actions, and LangSmith tracing to review blocked and allowed calls. If your team runs LangChain chains or tool-calling agents and needs controls on user inputs, model outputs and tool calls, this section explains what each pattern adds before you choose how to build it. The rails are defined in Colang files and a config.yml file, with optional Python actions. The project is licensed under Apache 2.0, so the library itself carries no license fee for your team to budget.

The integration gives you access to the rail types the library provides. Input rails check user messages before the model sees them. Output rails check responses before they reach the user. Execution rails apply to custom actions and tools, which matters most for tool-calling agents, because the arguments a model proposes can be checked before a tool runs. Dialog rails shape conversation flow, and retrieval rails apply to chunks returned by a RAG pipeline. Your first task is to decide which of these your application needs. A chat assistant that only answers questions has different needs from an agent that can write to a ticketing system or a payments service, and the rail list should follow from that difference.

Each pattern places the guardrail in a different spot. Agent middleware wraps the agent loop, so checks run around each reasoning and tool step. RunnableRails wraps an existing runnable, which lets you add guardrails to a chain that already works. Chains used as guardrail actions let a LangChain chain perform a check, such as a classifier or policy prompt, that a rail then calls. That last pattern adds a model call per check, so latency and token cost grow with every rail that uses it. Ask your engineers to measure the added latency per request for each pattern in a staging build before choosing a design for production traffic.

LangSmith tracing records which rail blocked or allowed each call, which is the evidence your reviewers need when tuning rules or investigating a complaint. Traces often contain prompts and user content, so confirm where they are stored, who can read them, how long they are kept and whether that meets your data handling rules. Before you start, check the Python version (the library supports 3.10 through 3.13), pin the library version, and confirm which Colang version your configuration uses, since Colang 1.0 is the default and Colang 2.x is also supported. Confirm the LangChain integration steps against the current NeMo Guardrails documentation for the version you pin.

What you need before starting the NeMo Guardrails and LangChain integration

Close these items in your own environment before changing any application code. The integration depends on a supported Python runtime, a working LangChain application, one environment variable, credentials, network paths and a deployment model. Confirm the exact LangChain version pins with the NeMo Guardrails documentation for your release.

Python 3.10 to 3.13 and nemoguardrails

NeMo Guardrails supports Python 3.10, 3.11, 3.12 and 3.13, so the hosts or container images that run your LangChain application must use one of these versions. Install the nemoguardrails package from PyPI into a virtual environment or image that pins the interpreter. Check that your existing LangChain dependencies resolve alongside it, since conflicting pins can block installation. Record the installed version so tests and deployments stay reproducible.

A runnable LangChain application

Have a LangChain application that already runs end to end before adding guardrails. Choose the integration pattern you need: agent middleware for tool-calling agents, RunnableRails around an existing chain, or a chain used as a guardrail action. Each pattern changes where checks sit in the call path, so the target application determines the work. Keep a baseline of its inputs, outputs and tool calls so you can compare behavior after guardrails are added. A test harness from the start makes regressions visible.

The LangChain opt-in environment variable

The LangChain integration is opt-in. Set NEMOGUARDRAILS_LLM_FRAMEWORK=langchain in every environment where the integration should run, including local development, CI and production. Without it, the library does not enable the LangChain path, so a test that passes locally can behave differently in a deployment that omits the variable. Keep the setting in the same configuration source as other application settings so that changes to it are reviewed with code.

Provider credentials and LangSmith access

Guardrails calls model endpoints for the main LLM and for any moderation or check models you configure, so each provider needs credentials issued and stored under your secrets process. Decide which service accounts or keys each environment uses and who can rotate them. If you want traces of blocked and allowed calls, you also need LangSmith access, a project for the application and a decision on which prompt content may leave your boundary. Confirm what your provider and tracing setup require.

Network paths to model endpoints

The runtime that executes guardrails must reach every configured model endpoint, whether hosted by a provider or served inside your network. Map each path, including egress rules, proxies, DNS and TLS trust for internal endpoints. Check these paths from every environment, including staging and production, because a missing route often appears only after deployment. Confirm that any tracing endpoint you enable is reachable and allowed by your egress policy.

In-process or guardrails server

Decide whether guardrails run inside the LangChain process through the Python API or as a separate guardrails server that loads configurations from a folder and exposes an HTTP API. In-process keeps one deployment unit and avoids a network hop, but each application instance loads its own configuration. A server centralizes configuration and can be built from the provided Dockerfile, which changes how you version, scale and secure it. Make this choice before writing deployment manifests, since it sets the service boundary.

Choosing between agent middleware, RunnableRails and guardrail actions

Choose the attachment point by deciding which part of the application the team needs to change. Some teams need rails inside the agent loop, deciding what the model may do and when tools run. Others have a fixed chain and need checks added around it without touching its steps. A third group wants only input and output checks, with the orchestration left alone. Each of the three options fits one of these needs, and choosing the wrong one usually means rewriting the integration later. Before committing, confirm the current class names, supported LangChain versions and parameters in the NeMo Guardrails documentation, because this integration area changes between releases and this section does not replace that check.

Agent middleware suits a tool-calling agent where the team wants a rail at each decision point in the loop, such as before a model call, before a tool executes and before the final answer is returned. The code change sits where the agent is constructed, so the application team adds the middleware and keeps it aligned with agent updates. Rail logic is usually written as Colang flows and a config.yml file, which a security or platform group can own, but the application team still owns the wiring. Confirm which hook points the installed version exposes and how a blocked tool call is reported back to the model, because the agent's behavior after a block depends on that answer.

RunnableRails wraps an existing chain without changing its internal steps. The application team keeps the chain and calls the wrapped object through the same interface as before, so the rest of the application sees little change. This suits deterministic pipelines such as retrieval followed by generation, where the team wants input and output checks at the edges. Ownership splits cleanly: application engineers maintain the chain, while a governance or security group can review and version the Colang flows and configuration. Confirm how input and output rails apply to intermediate outputs, and whether the wrapped object supports streaming responses in the version you plan to run.

Using an existing chain as a guardrail action fits checks that need their own reasoning or multi-step evaluation, especially when the team has already built that evaluation as a LangChain chain. The main application chain stays untouched, and a flow calls the evaluation chain as a custom action. This keeps the check logic in a separate artifact that can be tested on its own, but every guarded step adds at least one more model call, which increases latency and cost. Ask the team to measure that overhead in its own environment, and confirm how action inputs, outputs and errors are passed back into the flow before relying on this pattern.

Configuring NeMo Guardrails and LangChain integration step by step

Application and platform engineers work through six ordered steps to take NeMo Guardrails from an environment variable to a tested, deployed policy around a LangChain application. Each step closes with a check, such as a blocked test prompt, a logged rail trigger or a passing unit test. The result is a version-controlled configuration that gives the same decisions in tests and in the deployed endpoint.

Set the LangChain framework environment variable
Platform or application engineers set NEMOGUARDRAILS_LLM_FRAMEWORK=langchain in the environment where the application runs, such as the service unit, container definition or deployment manifest. The LangChain integration is opt-in, so without this variable NeMo Guardrails does not load its LangChain path. Confirm the runtime uses Python 3.10, 3.11, 3.12 or 3.13, which are the supported versions. The step is done when a small script started in the application's own environment prints the variable's value and the library imports without error.
Create the config folder with config.yml and Colang files
Developers create a configuration folder containing config.yml, which names the model, the rails enabled and any Python actions, plus one or more Colang files that define the messages and flows the rails match. Colang 1.0 is the default, so new configurations start there. If the team already has Colang 2.0 configurations, follow the documented NVIDIA migration path, which uses the nemoguardrails convert tool, and plan a manual review of the converted files. Keep the folder in version control. The step is done when the library loads the folder without parse errors and the startup log lists the model and rails it declared.
Define input, output and execution rails for the tools
Security and application engineers choose which of the five rail types the application needs: input rails for user messages, output rails for model responses, and execution rails for custom actions and tools. Each tool the agent can call gets an execution rail that checks arguments before the call and results before they return to the model. Enable built-in checks such as self-check input moderation or jailbreak and injection detection only where the threat model requires them, and confirm that each model or service they call is approved for the data involved. The step is done when an illustrative prompt asking the agent to call a tool outside its permitted set is blocked and the trigger appears in the logs.
Wire the chosen LangChain pattern in code
Application engineers select one pattern: agent middleware for tool-calling agents, RunnableRails wrapped around an existing chain, or a chain called as a guardrail action. Middleware fits agents whose tool calls need checking at each step. RunnableRails fits a chain that already works and needs a guard placed in front of it. Calling a chain as an action fits checks that need their own LLM logic. Leave the rest of the chain unchanged so the code diff stays small. The step is done when a unit test sends one allowed and one disallowed input through the wrapped component, asserts both outcomes, and passes in CI.
Load the configuration through the Python API or server
Platform engineers choose how the application reaches the rails. They either import the Python API inside the application process or run the guardrails server, which loads configurations from a folder and exposes an HTTP API. A Dockerfile is provided for building a server image. The server route suits several applications that share one policy. Confirm that the chosen runtime loads the same folder used in tests. The NeMo Guardrails microservice is a separate production container deployed on Kubernetes with Helm, so confirm whether you need it before choosing that route. The step is done when the deployed endpoint and the local tests return the same decision for the same illustrative input.
Trace blocked and allowed calls in LangSmith
Platform and security engineers enable LangSmith tracing for the LangChain application and review traces for both blocked and allowed calls. Each trace should show which rail fired, the input or tool call that triggered it, and the response the user received. Confirm with the team which trace fields may contain personal or confidential data and who may access them before tracing production traffic. Use the traces to tune rail definitions and to confirm that the rules from step three behave as written. The step is done when the illustrative blocked prompt from step three appears as a trace with the triggering rail identified, and an allowed prompt appears alongside it.

How NeMo Guardrails and LangChain integration maps messages, tool calls and retrieved chunks

This table maps each LangChain element to its NeMo Guardrails rail, then lists the fields and identifiers teams must agree on at each boundary. Read it before writing Colang flows or wrapping chains, and treat every field name as something to verify against the versions you pin.

Element	NeMo Guardrails counterpart	Fields to agree on	Transformation and audit notes
User input	Input rails	Message role, user text, session or thread identifier	Input is usually a single user message converted to the framework's message format; carry the thread identifier so blocked inputs can be traced to a conversation.
Model output	Output rails	Assistant role, generated text, finish reason where exposed	Rails may rewrite or replace the response, so log both the raw model output and the returned text under the same request identifier.
Tool call	Execution rails	Tool name, arguments object, tool call identifier	Arguments are often serialized to strings at the LangChain boundary; confirm the parsed form the rail receives before writing validation logic.
Tool result	Execution rails (post-execution)	Tool name, returned content, tool call identifier	Match results to their originating call by identifier, not by order, so audit records stay correct when calls run in parallel.
Retrieved documents	Retrieval rails	Chunk text, source identifier, metadata such as tenant, classification or document ID	Retriever metadata keys vary by loader and vector store; list the exact keys your pipeline sets and confirm they survive the conversion.
Conversation turns	Dialog rails	Turn order, role sequence, intent or flow name	Dialog rails reason over the turn history, so truncation or memory summaries in LangChain change what the rail sees; document the window size.
Blocked or modified response	Rail decision output	Rail name, decision, reason, original and final text	Keep the rail name and reason with the trace identifier so reviewers can distinguish a policy block from a model error.
Trace and audit identifiers	Logs and LangSmith traces linked to rail events	Run ID, request ID, configuration version, package version	Pass these identifiers across the boundary on every call; confirm the exact attribute names in your pinned NeMo Guardrails and LangChain versions.

Securing the integration: secrets, tool permissions and blocked-call handling

Guardrails only hold when the surrounding setup is controlled. The cards cover the credentials the integration uses, the permissions behind tool and database calls, the files that define guardrail behavior, the HTTP surface of the guardrails server, and what users and logs see when a call is blocked. Independent testing of this setup is covered in the testing section.

LLM and LangSmith credentials

Model provider keys and LangSmith API keys should reach the process through environment variables or a secrets manager at startup, and stay out of config.yml and Colang files. Decide who can create, rotate and revoke each key, and use separate keys for development, staging and production so a leaked development key cannot spend production model quota or write to production traces. Confirm which LangSmith project receives traces, because traces can contain user prompts and tool outputs.

Least-privilege execution rails

Execution rails call the custom actions and tools that reach systems of record, so each one should hold only the database roles, API scopes and network paths its task requires. Reporting tools should use read-only database accounts, and actions that change data should be limited to the operations the business has approved. Compare the registered actions with the tools the agent can actually invoke, since a registered action that a flow calls will still run.

Custom actions run with app permissions

Python actions loaded by NeMo Guardrails execute in the same process as the host application, under the same operating system user, file access, environment variables and network reach. A guardrail does not sandbox them. Review each action as application code, pin its dependencies, and confirm the server process cannot read secrets that only other services need. Apply the same change control to a new action file as to a new API endpoint.

Version control for Colang and config

config.yml, Python actions and Colang files define what the guardrails allow, block and say, so they belong in version control with protected branches and required review. Colang 1.0 is the default and Colang 2.0 is also supported, so record which version each configuration folder uses. Changes to flows, thresholds or model references should trigger the same tests as application code, and the deployed folder should match a tagged commit.

HTTP exposure of the guardrails server

The guardrails server loads configurations from a folder and exposes an HTTP API, and a Dockerfile is available to build its image. Keep it on a private network, place it behind your gateway with authentication, and publish only the endpoints the application calls. Confirm the route list for the exact version you deploy, and check the image contents before it moves to production.

Blocked-call responses and logs

Decide what a blocked call returns to the user, usually a neutral refusal that does not reveal which rail fired or which policy text matched. Decide separately what is logged: the rail name, the decision and a request identifier are often enough for review, while full prompts and tool arguments may contain personal data. Set retention and access rules for LangSmith traces before enabling them for blocked calls.

How LangSmith tracing shows blocked and allowed calls

A reviewer needs one trace per user call that shows the original input, every rail that ran, whether each rail allowed or blocked the message, the tool call decision, and the final response returned to the user. Without those five elements, a blocked request looks like an ordinary error or a silent refusal, and a security or compliance reviewer cannot tell whether the guardrail worked as designed. When you scope the integration, ask for these fields to be captured as a defined requirement rather than left to default tracing output.

Structure the traces so guardrail work is easy to find. In practice this means wrapping the NeMo Guardrails call in its own run or span inside the LangChain application, naming it consistently (for example, one name for the input rail stage and one for the tool execution stage), and attaching metadata such as the configuration version, the rail names and an outcome field with values for allowed and blocked. Those fields let reviewers filter for blocked calls directly in LangSmith instead of reading every run. The exact metadata keys and filtering options depend on your LangChain and LangSmith versions, so confirm which trace fields and tags your versions support, and test them with a deliberately blocked prompt before the design is signed off.

Decide in advance who reviews traces and with what access. Security operations may need blocked calls for incident investigation, product teams may need them to tune rails, and compliance staff may need evidence of control operation. Each group needs a documented role, a reason for access, and an approval path. Limit project access to those roles, and check whether your LangSmith deployment and plan support the role separation and audit logging you need. Also confirm whether reviewers need access to the full trace or only to the decision metadata.

Set retention before the first production trace is written. Ask how long your organization needs blocked-call evidence, how long allowed-call traces are useful for quality work, and who approves deletion. Retention periods should be written into your policy and matched to what your LangSmith setup can enforce. Keep in mind that traces may be copied into other tools or backups, so the retention rule must cover those copies as well.

Traces often contain personal data. The user input, retrieved context and model output may include names, account numbers, health or financial details, and content from tool results. Before enabling full tracing, classify what each trace field can hold, decide which fields to mask or omit, and confirm with your privacy and legal teams whether the processing is covered by your records and notices. Test masking on sample data that includes realistic-looking identifiers from your own domain, not only generic examples. Confirm the masking options that your LangChain and LangSmith versions provide, and plan for a fallback where full tracing is disabled for sensitive flows.

Testing each pattern before go-live

Agent middleware sits between the model's tool-calling loop and the tools themselves, so the tests must confirm that the guardrail sees every proposed tool call before it runs. Start with allowed requests: a set of realistic user tasks that the agent should complete without interruption, recorded with the expected tool sequence. Then write blocked-prompt cases that try to make the agent leave its intended purpose, including requests phrased to avoid obvious keywords.

The core checks for this pattern are:

Allowed requests: tasks inside policy complete with the expected tools and arguments.
Blocked prompts: off-topic and jailbreak-style requests are refused before any tool runs.
Out-of-policy tool calls: the agent proposes a tool or argument value outside policy, and the middleware stops the call.
Injected retrieval content: documents returned by a search tool contain instructions such as "ignore prior rules", and the agent does not act on them.
Regression after change: rerun the full set after any Colang file, guardrail configuration or LangChain or NeMo Guardrails dependency change.

Confirm with your engineers which tool calls the middleware can intercept in your LangChain version, since coverage depends on that boundary. Record the results so an auditor can trace each control to a passing test.

Common failures in NeMo Guardrails and LangChain integration

This table lists common failures when NeMo Guardrails runs inside a LangChain application, with the likely cause, a diagnostic step and a fix for each. Work through it when rails seem inactive, a tool runs unchecked or traces look incomplete. Converted Colang configurations need manual review, as NVIDIA's migration guide advises, before you rely on them in production.

Failure	Likely cause	Diagnostic step	Fix
LangChain integration inactive	NEMOGUARDRAILS_LLM_FRAMEWORK is unset in the process that starts the application	Print the variable in the same shell or container that launches the app	Set NEMOGUARDRAILS_LLM_FRAMEWORK=langchain in the runtime environment and restart the process
Mixed Colang 1.0 and 2.0 syntax	A partial migration left some files in the older Colang syntax	Check each .co file for the syntax version it uses and list any mismatches	Convert every file, then review converted flows manually as NVIDIA's migration guide advises
Rails never fire	The flow name in Colang does not match the name the configuration or rail expects	Enable verbose logging and confirm which flows match a known test prompt	Align flow names exactly across Colang files and config.yml, then retest with known inputs
Tool calls bypass execution rails	The agent invokes tools directly, outside the rails path	Trace one tool call and confirm an execution rail step runs before the tool	Route every tool through the rails wrapper and test blocked tool calls before release
Latency from rail models	Self-check or moderation models run on every turn, often through remote calls	Time each rail step in traces, with and without the rail enabled	Limit rails to the flows that need them, choose lighter models where accuracy allows, and size inference for peak load
Traces missing guardrail steps	Tracing is not attached to the rails-wrapped chain or runnable	Open the LangSmith run for a blocked call and look for rail spans	Attach tracing configuration to the wrapped runnable, then confirm spans appear for allowed and blocked calls

Questions buyers ask about NeMo Guardrails and LangChain integration

How much does it cost to add NeMo Guardrails to a LangChain app?

DeployOpen does not publish prices. A quote follows from a written scope, and the main cost drivers are the number of rails, the number of tools and agents, whether a Colang migration is needed, and how deep the testing and tracing review goes.

Cost drivers:

Each rail needs design, configuration and test cases.
Each tool or agent adds call paths that must be mapped to the right rails and checked.
A Colang 1.0 to 2.x migration adds conversion and manual review, since NVIDIA says converted configurations still need that review.
Testing and LangSmith trace review scale with the number of flows you need to prove.

One-time work covers design, build, testing and handover. Recurring costs include model usage, hosting and any upgrades you choose to run. The NeMo Guardrails library is licensed under Apache 2.0, so the license is not the main line item. Ask for a quote that lists each driver separately so you can adjust scope.

How long does a NeMo Guardrails LangChain integration take?

There is no fixed duration. The timeline is a driver-based estimate that depends on the same factors as cost: the number of rails, the number of tools and agents, whether configurations must be migrated to Colang 2.x, and how much testing and trace review your organization requires.

Schedule also depends on your side of the work. Access to LangChain code, a tool inventory, approved policies, test data and named reviewers all affect when work can move forward. Delays in any of these usually extend the schedule more than the build itself.

The written scope sets the deliverables and the timeline agreed for them. Ask for the timeline to be tied to named milestones, such as design sign-off, test completion and handover, so you can see which driver is moving the date.

Can our internal team integrate NeMo Guardrails with LangChain without outside help?

Yes, an internal team can do it alone if it already has Python, LangChain and guardrail design experience and enough time to build and test. The library supports Python 3.10 through 3.13, and LangChain integration is opt-in, enabled with the NEMOGUARDRAILS_LLM_FRAMEWORK=langchain environment variable.

Teams that build alone most often struggle with three areas: writing Colang flows that match real call paths, defining what counts as a blocked or allowed call, and testing edge cases across tool-calling agents. Outside help is most useful for scoping those decisions, reviewing the design, completing a migration, or building test and trace review.

For a clear answer, compare your team's skills against the drivers in the written scope, then decide which parts to keep in-house.

What must we provide before a NeMo Guardrails integration starts?

Before work starts, your team needs to provide five inputs:

LangChain code: the chains, agents and tool-calling paths the guardrails will wrap.
Tool inventory: every tool and external action the agent can call, with its purpose and data sensitivity.
Policies: approved rules for allowed topics, refusals, data handling and escalation.
Test data: representative prompts, expected blocks and expected allows, including adversarial cases.
Reviewers: named people who can approve designs, judge test results and review blocked-call traces.

Missing inputs are the most common cause of schedule slips. If policies are unsettled or reviewers are unavailable, the design and testing phases cannot close. Confirm these items in the written scope so that responsibilities are clear before any build time is committed.

Does moving from Colang 1.0 to Colang 2.x need a separate project?

It can be planned as its own phase, and it often is. Colang 1.0 is the default in NeMo Guardrails, and Colang 2.0 is also supported. NVIDIA documents a migration path using the nemoguardrails convert tool, and states that converted configurations still need manual review.

The migration adds effort in three places: converting configurations, reviewing the converted flows against your policies, and re-running the tests that prove the rails still behave as intended. If your existing rails are small and well tested, the migration is a smaller share of the work. If they are large or poorly documented, expect more review time.

Ask the partner to state whether the migration is in scope, how converted flows will be reviewed, and which test cases will be rerun.

How do tracing and blocked-call review affect the scope of the work?

Tracing and review set how much evidence you get that the guardrails behave as designed. The integration can route traces into LangSmith, which lets reviewers see what was blocked, what was allowed and why, for each call through the chain or agent.

The depth of review is a cost driver. A light review checks a sample of traces against the test plan. A deeper review covers every tool path, every rail and the edge cases your policies name, and it requires more reviewer time from your side. The number of reviewers and their availability also affect the timeline.

Define the review depth in the written scope. State which traces are reviewed, who signs off, and how findings are recorded, so the review can be planned and costed accurately.

Which NeMo Guardrails version should we pin for a LangChain project?

Pin a specific release and test against it before you deploy. The latest release covered by the supplied facts is v0.24.1, released on 16 September 2026, and the project publishes its release notes on GitHub. Check those notes before choosing a version.

Confirm three things in your own environment:

The Python version you run is one of 3.10, 3.11, 3.12 or 3.13.
The LangChain version you use works with the NeMo Guardrails release you pin. Test this in a staging build, because compatibility depends on your exact dependency set.
Whether you use the Python API, the guardrails server or the NeMo Guardrails microservice, since each affects deployment and upgrades.

The written scope should name the version to be used and state how upgrades will be handled after handover.

How DeployOpen scopes, delivers and supports this integration

DeployOpen plans NeMo Guardrails and LangChain integration as a designed change to your application. We agree the integration pattern first, whether agent middleware, RunnableRails around an existing chain, or chains as guardrail actions, then build, test and document it in infrastructure you control. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

The written scope names which integration pattern fits each LangChain application: agent middleware, RunnableRails or chain actions.
Scope records which rail types apply, such as input, output, dialog, retrieval or execution rails, and why.
Scope also confirms Python version, LangChain version and whether LangSmith tracing is in use.

How we build

Configure config.yml, Colang files and any Python actions, with LangChain enabled through the framework environment variable.
Wrap chains you already run as guardrail actions, so existing business logic stays under your own review.
Where Colang 1.0 configurations exist, migrate to Colang 2.x with the convert tool and review every output manually.

How we hand over

Test suites cover blocked and allowed tool calls, refusals and dialog paths, with results kept in the handover record.
LangSmith tracing setup lets your reviewers inspect why each call was blocked or allowed.
Documentation covers the deployment, configuration layout, runbooks and how to change rails safely.

How we support

Ongoing support can run as a retainer covering NeMo Guardrails upgrades, rail updates and regression testing.
Upgrades are planned against the NeMo Guardrails release notes, with each version tested in a staging environment first.
Confirm with your team who owns rail changes after handover, since policy updates affect live LangChain agents.