[Enhancement]: Support external prompt management providers for agent/system instructions

[davidrellstab]

What features would you like to see added?

I would like LibreChat to support loading agent or system instructions from an external prompt management provider, instead of requiring the prompt content to be stored directly in LibreChat configuration or agent data.

The goal would be to introduce a provider-agnostic abstraction that allows LibreChat to resolve a prompt at runtime from an external system and use the resulting content as agent/system instructions.

For example, an agent configuration could reference an external prompt instead of embedding the full prompt text:

instructions:
  source: external
  provider: my-prompt-provider
  prompt: customer-support-system
  label: production

The exact configuration syntax is only illustrative.

The important part would be that LibreChat supports a generic prompt-provider interface rather than implementing logic tied to a specific vendor.

Possible external providers could include:

• prompt management platforms such as Langfuse
• internal enterprise prompt services
• Git-backed prompt stores
• self-hosted prompt registries
• other API-based prompt management systems

Motivation

In larger or production-oriented LibreChat deployments, system prompts are often treated as managed application artifacts rather than static configuration.

External prompt management can provide capabilities such as:

• prompt versioning
• promotion between development, staging and production
• rollback to previous prompt versions
• separation of prompt changes from application deployments
• central management across multiple applications
• prompt-specific metadata
• evaluation and observability linked to a specific prompt version

Currently, prompt content typically needs to be maintained within LibreChat itself. This makes it harder to use an external system as the source of truth for production prompts. This feature would allow LibreChat to delegate prompt lifecycle management while continuing to handle conversations, agents, tools and model requests.

Proposed architecture

LibreChat would request a prompt using a logical identifier such as:

prompt: customer-support-system
label: production

The provider could return:

{
  "content": "You are a customer support assistant...",
  "version": "42",
  "metadata": {
    "environment": "production"
  }
}

LibreChat would then use the returned content as the system or agent instructions.

It would be useful if this were implemented through a generic provider-agnostic interface. This would make it possible to add different implementations without coupling LibreChat to one prompt-management product.

If supported, LibreChat could optionally pass runtime variables to the provider or perform interpolation after resolving the prompt.

Caching and availability

External prompt resolution should preferably not make every chat request fully dependent on the availability of the external service.

Possible safeguards could include:

• in-memory caching
• configurable TTL
• stale-cache fallback
• refresh on startup
• optional local fallback prompt

Observability

If the external provider returns a version, revision or other identifier, it would be useful for LibreChat to retain this information as request metadata.

For example:

{
  "prompt_name": "general-assistant",
  "prompt_version": "42",
  "prompt_label": "production"
}

This metadata could later be passed to observability integrations where supported. This would make it possible to correlate a generated response with the exact prompt revision that produced it.

Summary

This feature would be especially useful for deployments where prompts are treated similarly to versioned application configuration and need an independent lifecycle from the LibreChat application itself.

It could also complement existing work around prompt variables, prompt metadata and external integrations without introducing a dependency on a specific provider.

Code of Conduct

I agree to follow this project's Code of Conduct.