Custom Providers
Ship your own provider as a Business Central app extension on AI Open SDK.
A custom provider is a separate app that depends on AI Open SDK (core) and returns models through the same interfaces as Anthropic, OpenAI, and OpenCode Zen.
What you implement
| Interface | Required when |
|---|---|
"AIOS Language Model" | Text generation |
"AIOS Image Model" | Image generation |
"AIOS Provider" | Factory surface (GetName, bind helpers) matching shipped providers |
"AIOS Chat Format" | Your HTTP message/tool JSON differs from the built-in formats |
Core already ships reusable formats:
"AIOS OpenAI Compatible Format""AIOS Anthropic Format"
Reuse one of those when your endpoint matches that schema. Implement "AIOS Chat Format" when the wire shape is different.
Extension layout
- Create a new AL app with its own
idRangesand App Id. - Add a dependency on AI Open SDK (core) in
app.json. - Implement the language (and optional image) model codeunits.
- Expose a public factory codeunit (same pattern as
"AIOS Anthropic"):Model(ModelId, KeyValue),SetApiKey, optionalSetBaseUrl/ version helpers. - Cover behavior with
"AIOS Mock"(in Core) in tests. Live keys stay out of CI.
"dependencies": [
{
"id": "<core-app-id>",
"name": "AI Open SDK",
"publisher": "Guillermo Padilla",
"version": "0.1.0.0"
}
]Consumer usage
Downstream apps depend on core plus your provider app, then call your factory and "AIOS Client":
MyProvider: Codeunit "My AIOS Provider";
Client: Codeunit "AIOS Client";
Result: Codeunit "AIOS Generate Result";
ApiKey: SecretText;
begin
Result := Client.GenerateText(
MyProvider.Model('my-model', ApiKey),
Prompt);
end;
Contract stability
Changes to "AIOS Language Model", "AIOS Chat Request" / response tables, and structured-output validation are high impact. Additional provider adapters are additive. See Governance.