adm_ai_agent_profile_api

Points the two bundled AI agents at the provider and model an administrator chose.

The AI Pack ships two uc_ai prompt profiles - ADM_DOC_ASSISTANT (the document-discovery assistant) and ADM_DOC_AGENT (the single-document assistant) - and uc_ai_agents_api.execute_agent takes no provider or model override. The profile row is therefore the only place a provider can be chosen, and this package writes the settings into it.

What it reads

Five settings, all in the AI_PACK category, all seeded empty:

AI_AGENT_PROVIDER           openai | anthropic | google | ollama | oci | xai |
                            openrouter | mistral | responses_api
AI_AGENT_MODEL              gpt-5.4, claude-sonnet-4-6, llama3.1, ...
AI_AGENT_WEB_CREDENTIAL_ID  APEX Web Credential static id, empty for a local Ollama
AI_AGENT_REASONING_LEVEL    NONE | LOW | MEDIUM | HIGH
AI_AGENT_MODEL_CONFIG       optional JSON object, merged over everything above

Out of the box every one of them is empty, which means this package writes nothing: the profiles run on whatever dml/adm_ai_assistant_profile.sql created them with (OpenAI, at the time of writing), and anything changed directly through the uc_ai APIs survives. Filling AI_AGENT_PROVIDER in is what hands them over.

Empty is meaningful on the other keys too, and not the same thing on each:

AI_AGENT_MODEL may not be empty once a provider is set - a provider without a model is refused rather than half-applied.
An empty AI_AGENT_WEB_CREDENTIAL_ID removes the credential from the profile. The credential belongs to the provider you picked, so carrying the previous provider’s one over would be a bug; a local Ollama needs exactly this.
An empty AI_AGENT_REASONING_LEVEL leaves the profile’s reasoning alone. It is a per-model tuning knob, not part of the provider identity.

What it writes, and what it leaves alone

Only the model-related parts of a profile: provider, model and the g_apex_web_credential, g_enable_reasoning and g_reasoning_level keys of model_config_json, plus whatever AI_AGENT_MODEL_CONFIG adds on top.

The rest of the config is patched around rather than rebuilt, because g_tool_tags carries the uc_ai_memory tag that uc_ai_memory.enable_for_agent added, so rebuilding the config from scratch would turn agent memory off on every settings change. The system prompts, g_max_tool_calls and any tool tag added by a customer are preserved for the same reason.

The five settings are a shortcut for the handful of uc_ai options an ADM administrator changes; they are not the whole surface. Everything else uc_ai accepts in a model config goes through AI_AGENT_MODEL_CONFIG verbatim - see the UC AI documentation at https://www.united-codes.com/products/uc-ai/docs/ for what it takes.

When it runs

Automatically, through the compound trigger adm_ai_agent_settings_aiu on adm_settings - so an edit in the Preferences page, from SQLcl or in a script all reach the profiles - and from the install DML. Call it directly after editing a profile by hand to put the configured values back:

begin
  adm_ai_agent_profile_api.apply_model_settings;
  commit;
end;
/

Functions and Procedures

apply_model_settings

Writes the configured provider, model, web credential and reasoning level into both shipped prompt profiles.

Validates first, so an unusable configuration is refused before a profile is touched: an unknown provider, a provider without a model, an unknown reasoning level or an AI_AGENT_MODEL_CONFIG that is not a JSON object all raise. Called from a trigger on adm_settings, that refusal is what stops the bad value being saved at all.

Does nothing when no provider is configured. A profile that does not exist - deleted, or never installed - is logged and skipped rather than raised on: a missing profile must not make the settings page unsavable.

Does not commit; the caller owns the transaction.

Signature:

procedure apply_model_settings;