Common Library

AI Abstractions

ai.promethist.ai defines how the platform talks to language models, inference models and tools. The engine provides the implementations — see Engine AI Layer.

Model Factory

LLMFactory<CM, SCM> is the provider-agnostic contract for obtaining a model for a component (the object that is about to call it) and a context:

interface LLMFactory<CM, SCM> {
    fun getStreamingModel(component: Any, context: Context?): SCM
    fun getStreamingModel(component: Any, context: Context?, configuration: LLMConfiguration): SCM
    fun getModel(component: Any, context: Context?): CM
    fun getModel(component: Any, context: Context?, configuration: LLMConfiguration): CM
}

SpringAiLLMFactory specializes it to Spring AI’s ChatModel and StreamingChatModel. Passing the calling component is what makes per-component model configuration possible — the factory resolves the configuration from the component’s class name.

Model Configuration

LLMConfiguration is a sealed interface with one nested data class per provider flavour, Jackson polymorphic so it can be stored on an agent. Every variant carries modelName, temperature and timeout.

Configuration Provider-specific options

OpenAiChatModelConfiguration

maxTokens, topP, jsonOutput, enableStreamUsage.

OpenAiReasoningModelConfiguration

reasoningEffort, jsonOutput, enableStreamUsage; temperature is fixed.

AzureOpenAiChatModelConfiguration

deploymentName, maxTokens, topP, enableStreamUsage.

AzureOpenAiReasoningModelConfiguration

deploymentName, maxCompletionTokens, reasoningEffort.

AnthropicChatModelConfiguration

maxTokens.

GoogleGenAiChatModelConfiguration

topP, topK, candidateCount, useGoogleSearch, jsonOutput, thinkingLevel.

ModelProvider enumerates the providers the platform knows: OpenAi, OpenAiReasoning, AzureOpenAi, AzureOpenAiReasoning, Anthropic, GoogleGenAi, Triton.

LLMProperties and LLMComponents (a NamedProperties<LLMProperties> alias) carry the per-component configuration read from promethist.ai.llm-components.*, with a custom serializer so the provider-specific block deserializes into the right configuration type.

Tool Boxes

Tools are how an agent does something other than talk. The ToolBox contract, the structural implementations (EmptyToolBox, MultiToolBox, AnnotatedToolBox) and the supporting types have their own page — see Tool Boxes.

Tool Call Classification

ToolCallClassificator decides for one turn whether each tool covered by criteria should have been called, and turns that decision into a verdict. Its input, ToolCallTurn, is independent of where the turn comes from. ToolNamePattern matches tool names against patterns with * and derives a tool’s tool box from its {toolBox}_{tool} name, and ToolCallOutcome derives the outcome of an executed call. See Tool Call Analysis.

Prompts and Logging

SystemPrompt, PromptInvocation and PreparedPromptInvocation model a prompt and its invocation, so what was actually sent can be captured per turn. LLMLogger is the contract the engine implements to persist those invocations.

Inference Models

Separate from chat models, InferenceModel/https://gitlab.com/promethistai/promethist/-/tree/main/common/src/main/kotlin/ai/promethist/ai/InferenceMultiModel.kt[InferenceMultiModel] abstract a served model — primarily Triton:

interface InferenceMultiModel {
    val name: String
    fun predict(inputs: Map<String, List<Any>>, outputs: List<String> = listOf(), params: Map<String, Any> = mapOf()): Mono<InferenceModelResult>
}

interface InferenceModel<I : Any, R : Any> : InferenceMultiModel {
    fun predict(input: I, params: Map<String, Any> = mapOf()): Mono<R>
    fun predict(inputs: List<I>, params: Map<String, Any> = mapOf()): Mono<List<R>>
}

TritonModel, TritonMultiModel and TritonClassification are the implementations, over the gRPC client generated in this module; TritonService in ai.promethist.service wraps them.

Realtime (speech-to-speech) providers are a different contract again — RealtimeModel, with implementations in the engine.

Embeddings

ReactiveEmbeddingModel is the reactive wrapper the memory layer uses for indexing and search; InMemoryEmbeddingStore is an in-memory vector store used in tests and for small ad-hoc sets.

In this section