#Connect an LLM provider

An LLM provider adapter tells Chester which protocol a model provider speaks, while the address and the API key live on the system's environments.

Agents need a language model. Where that model comes from is set up under Systems, the same way as any other external service: a system for the provider, an adapter that says how to talk to it, and one environment per account you use.

#How the parts relate

flowchart LR
  S["System: Langdock"] --> A["LLM provider adapter: protocol OpenAI-compatible"]
  S --> E1["Environment Test: base URL + API key credential"]
  S --> E2["Environment Production: base URL + API key credential"]
  A -. "models discovered live through" .-> E1
  A -. "models discovered live through" .-> E2

The adapter itself holds no address and no key. It only knows the protocol and, once a connection test has run, what the provider is able to do. Everything that differs between a test account and a production account is on the environment.

#Add the adapter

Under the provider's system, add an adapter and choose the technology LLM provider. Then pick the protocol:

The adapter has no actions. It is not something a service task calls; it is what an agent runs on.

For the OpenAI-compatible protocol you can list additional model ids by hand, one per line. Chester asks the provider for its model list, and some services do not answer or list models that are not usable for agents. The ids you add are offered next to whatever was discovered.

#Add an environment with the address and the key

Each environment of the system carries:

• A base URL. For a direct Anthropic, OpenAI or Google account this is the provider's own address, which the adapter form shows you. For an OpenAI-compatible service it is the endpoint that service documents, for example the regional URL Langdock gives you.
• A credential of type API key or bearer token that holds the key. For the OpenAI-compatible protocol the connection test and the model list also work without one, for a service that needs no key — an agent, however, only runs on an environment that has a credential.

The base URL must be a public https address. An address that points at a private network or at the machine itself is refused when you save the environment.

Create one environment per account: a test account and a production account are two environments on the same system, and the agent picks which one it uses.

#Test the connection

On the adapter's page, choose an environment and a model and run the connection test. Chester makes one small request that asks the model to call a tool, and one that streams a reply. The result is stored on the adapter as its capabilities:

• Tool calls. Required for agents. An adapter without confirmed tool calls is still saved, and the adapter's page shows tool calls as not confirmed.
• Streaming.
• Attachments and temperature are not measured by the test. They keep the values the protocol starts with, and you can change them by hand.

Run the test again after the provider changes something, or set a capability yourself if you know better than the test.

#Which models are offered

The model list is never typed in and never stored. When you pick a model for the connection test, Chester asks the provider for its current models through the chosen environment and shows what it gets back, cached for an hour. A model that the provider retires disappears on its own; a new one appears on its own.

#Use the provider in an agent

On the agent's Configuration tab, pick the LLM provider adapter, then one of its system's environments, then a model. The environment list offers only environments that have a credential; if exactly one qualifies it is chosen for you. The model list is the provider's live answer for that environment, so it is the same list the adapter's connection test shows.

An adapter whose connection test has not confirmed tool calls appears in the picker greyed out with a not tool-capable badge. Agents work through tool calls, so such an adapter cannot run one. Run the test on the adapter, or set the capability yourself if you know the provider supports it, and the adapter becomes selectable.

An agent that has no adapter, no environment or no model, whose environment has no credential, or whose adapter is not tool-capable is marked as invalid and cannot be deployed. The message names what is missing. An agent that was set up before LLM provider adapters existed and was never moved over shows this message too: pick an adapter, an environment and a model on its Configuration tab and deploy it again.

Switching an agent from a test environment to a production environment changes the endpoint and the key the agent runs against without touching anything else on the agent. Deploy the agent again after the change; a running deployment keeps the provider it was deployed with.

#Testing agents in the Element Workbench

The workbench runs only against environments classified as Development or Test. That rule covers the agent's LLM environment as well: a workbench run of an agent whose provider environment is classified as production, or is not classified at all, is refused with the same message as any other production target. To test an agent, give the provider system a second environment of kind Test (the same key is fine) and select it on the agent.