Repository navigation
Description
Context
IBM Consulting users get model access through the IBM Consulting Advantage (ICA) gateway. Their team manages the keys, and regional instances keep client delivery work in approved environments. Several consulting users have asked to run DAM agents on it. One team got a Claude Code agent working with environment variables as a workaround. Another user already runs Codex on ICA locally. Research task #6013 asked whether this is possible, and these reports answer part of it.
Problem
ICA isn't a provider option in DAM. A consulting user must use a provider their team doesn't fund, or hand-wire environment variables that only someone who knows the gateway's API can set up. Teams that are only cleared to use ICA for client work can't use DAM there at all.
Goal
A user can pick ICA as a provider, paste their ICA key, and run an agent on ICA models with no manual setup.
User Stories
- As a user, I want to add my ICA key as a provider so that my agents use the models my team already pays for.
- As a user, I want to choose ICA models for an agent so that client work stays on an approved gateway.
Done when
AC-1 — ICA is a provider option
Given a user opens the provider setup in the web UI
When they look at the list of providers
Then they see an IBM Consulting Advantage option that asks for an API key
AC-2 — An agent runs on ICA
Given a user has added a valid ICA key
When they create an agent on an ICA model and send it a message in chat
Then the agent replies
AC-3 — A bad key is caught
Given a user enters an invalid ICA key
When they save it
Then they see an error saying the key was rejected
Open Questions
- Which harnesses work: Codex only, or Claude Code too? The reports conflict.
- The global instance only, or regional instances too?
- Does ICA report usage, so the spend screens stay accurate?
- Who owns the gateway, and do they need to approve access from DAM?
Additional resources
- Research task Can DAM agents use the IBM Consulting Advantage gateway as a model provider? #6013
- ICA exposes an OpenAI-compatible Responses API at
https://api.servicesessentials.ibm.com/v1, keyed by an API key
Follow up
- User request: https://ibm.enterprise.slack.com/archives/C0CBV9Z6YDD/p1793298923627599 (DM with jenna-winkler)
- User request: https://ibm.enterprise.slack.com/archives/D09E5MQ16F4/p1793392409916719 (DM with jenna-winkler)
- User request: https://ibm-research.slack.com/archives/C0B09BF65CP/p1793110794977739
Activity
BrUn3y commentedon Nov 2, 2026
Hey @jenna-winkler
I validated Claude Code on DAM against the global ICA endpoint by switching an existing agent from LiteLLM to ICA. This provides a working example for the Claude Code compatibility question.
ICA also exposes an Anthropic-compatible Messages API, in addition to the OpenAI-compatible API mentioned in the issue:
Base URL: https://api.servicesessentials.ibm.com
Messages endpoint: POST /v1/messages
Authentication: Authorization: Bearer
Model discovery: GET /v1/models
The working environment configuration was:
ANTHROPIC_BASE_URL=https://api.servicesessentials.ibm.com
ANTHROPIC_MODEL=claude-advantage-assist
ANTHROPIC_SMALL_FAST_MODEL=claude-haiku-5-5[1m]
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1
ANTHROPIC_DEFAULT_FABLE_MODEL=claude-advantage-assist
ANTHROPIC_DEFAULT_OPUS_MODEL=claude-advantage-assist
ANTHROPIC_DEFAULT_SONNET_MODEL=claude-advantage-assist
ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-5-5[1m]
The workaround used an anthropic-oauth connection template with a custom host and bearer credential. The environment was saved through agents.update, and the connection was assigned through connections.setAgentConnections.
DAM regenerated these managed files:
No agent source files required manual changes. After restarting, the configuration persisted, an actual dam run completed successfully, and telemetry recorded claude-advantage-assist. Both the primary and fast models returned HTTP 200 in direct API tests.
A few findings could help refine the implementation and acceptance criteria:
This validation covers the global endpoint and the Claude Code harness. Regional endpoints and Codex were not tested in this setup.