NeMo Relay runtime behavior is configured through API objects and registration calls rather than a global configuration file.
Most applications configure NeMo Relay by:
Use scope-local registration when behavior must be tied to one request, session, or agent run.
Plugins use a structured plugin configuration with:
Start with Define a Plugin when you need reusable middleware, subscribers, or adaptive behavior.
Use NeMo Guardrails Configuration when
you want the built-in first-party nemo_guardrails component.
The nemo-relay CLI gateway reads plugin files named plugins.toml. See
Plugin Configuration Files
for file locations, precedence, merge behavior, editor controls, and validation
rules.
Agent Trajectory Observability Format (ATOF) exporters, Agent Trajectory
Interchange Format (ATIF) exporters, OpenTelemetry subscribers, and
OpenInference subscribers can be configured directly through binding-native
config objects. Use the built-in observability plugin when you want one
plugin component to own standard exporter setup and teardown. See
Observability Configuration
and Observability
for the supported export paths.
NeMo Relay does not require application-level environment variables for normal runtime use. Configure most behavior through API objects, registration calls, or plugin configuration.
OTEL_* variables are only relevant when the underlying OpenTelemetry exporter
reads endpoint settings from the environment. Prefer explicit config objects in
application code so the active export settings are visible in docs, tests, and
deployment manifests.
Adaptive tuning is enabled through the adaptive plugin component and binding helper APIs. See Adaptive Configuration.