Skip to content
Uvilo OS
archived Visibility internal Owner erik@uvilo.com Approver _ Created _ Updated _

Libre Agents Requirements

Purpose

Solve the configuration management problem that arises from LibreChat’s agent-model binding. Currently, agents are locked to a single LLM model at creation time, making it difficult to maintain multiple agents with identical tool configurations but different models. This project explores alternatives and recommends a solution.

Background

In LibreChat, agents are assigned an LLM model during creation. Once a conversation starts with an agent, the model cannot be overridden or switched. This creates several operational problems:

  1. Model lock-in: If you want to test how a different model handles the same task with the same tools, you must create a separate agent with the same configuration but a different model.

  2. Tool configuration sprawl: When a new MCP server is added to librechat.yaml, it must be manually enabled in every agent that needs it. There is no mechanism to apply MCP servers globally across agents.

  3. Duplication tedium: The current workaround — configure one agent, duplicate it, rename it, change its model, and repeat for every model variant — is time-consuming and error-prone. Any subsequent configuration change (e.g., adding a new MCP tool, updating instructions) must be applied to every duplicate individually.

Requirements

Functional Requirements

  • FR-1: A user must be able to use the same set of MCP tools across multiple LLM models without manually configuring each model-agent combination.
  • FR-2: When a new MCP server is added to librechat.yaml, it must become available to all relevant configurations without per-agent manual intervention.
  • FR-3: A user must be able to switch between LLM models mid-conversation (or start new conversations with different models) while retaining access to the same tools.
  • FR-4: The solution must preserve agent-level system instructions and configuration (temperature, max tokens, etc.) across model variants.

Non-Functional Requirements

  • NFR-1: The solution must not require forking or modifying LibreChat’s source code.
  • NFR-2: The solution must work with the current deployment on Railway (Docker-based, single instance).
  • NFR-3: The solution must be maintainable — adding a new model variant should require minimal effort.
  • NFR-4: The solution should not degrade the user experience compared to the current agent-based workflow.

Constraints

  • LibreChat agents are inherently bound to a single model at creation time — this is a platform design decision, not a bug.
  • MCP servers configured in librechat.yaml are available globally, but must be explicitly added to each agent via the Agent Builder UI.
  • There is no native “agent template” or “tool group” feature in LibreChat as of v0.8.x.