TramAI - governed AI workflows for Java and Kotlin

JVM AI Integration for Kotlin and Java Applications

Teams building on the JVM usually do not want an AI framework that drags them into a completely different programming model. They want to add AI to an existing application without sacrificing type safety, architecture clarity, or operational visibility.

That is the problem TramAI is designed to solve.

What JVM Teams Usually Need

  • Kotlin and Java APIs that fit normal application code
  • clear integration with Spring Boot or standalone runtimes
  • structured output instead of brittle string parsing
  • the ability to route across providers without rewriting business logic
  • observability for AI operations in production

Why TramAI Fits This Better

0.6.0 is a published release candidate: pin dev.tramai:tramai-bom:0.6.0 and check API stability for what carries a compatibility promise.

TramAI starts from typed interfaces and annotated operations. That means AI integration looks closer to normal backend code and less like embedding a separate prompt framework throughout the application.

dependencies {
    implementation(platform("dev.tramai:tramai-bom:0.6.0"))
    implementation("dev.tramai:tramai-standalone")            // plain JVM
    // or:
    implementation("dev.tramai:tramai-spring-boot-starter")   // Spring Boot
    implementation("dev.tramai:tramai-spring-provider-openai")
}

You define the contract. TramAI handles the provider call, schema generation, parsing, retries, and supporting execution concerns around that contract.

@AiService
interface InvoiceAnalyzer {
    @Operation(
        prompt = "Analyze the invoice and return a structured status",
        model = "gpt-4o",
        tools = ["customer_lookup"],
        providerRetries = 3,
    )
    suspend fun analyze(invoiceText: String): InvoiceStatus
}

@Operation carries the prompt, the logical model (or an explicit provider), the tool names available to the operation, structured retries (maxRetries), provider transport retries (providerRetries), a per-attempt timeout, and opt-in response caching. Tool methods are annotated with @AiTool(description = ...), and their security metadata (permission, risk level, approval mode) is what the policy engine evaluates.

Typical Use Cases

  • document analysis inside enterprise backends
  • approval and review workflows
  • internal support automation
  • AI-assisted classification, extraction, and enrichment
  • governed model access in systems that already run on Kotlin or Java

What Makes This Production-Shaped

  • Structured output for typed response handling
  • Observability through metrics and tracing
  • Testing support so AI behavior can be validated without live calls
  • Provider flexibility across the 7 published adapter modules — OpenAI (and OpenAI-compatible gateways), Anthropic, Gemini, Ollama, Azure OpenAI, DeepSeek, and Bedrock — plus Spring property adapters for OpenAI, Anthropic, and Ollama
  • Framework choice between Spring Boot integration (tramai-spring-boot-starter, with tramai.profile: standard | sovereign) and standalone usage (tramai-standalone plus a provider module)
  • Governed execution when the workload needs it — deny-by-default policy, tool permission decisions, human approval gates, and audit evidence, in the same runtime

Where To Go Next

Previous
Next