TramAI - governed AI workflows for Java and Kotlin

Current Limitations

This page is intentionally blunt. It lists what TramAI 0.6.0 does not do, so you can plan around the gaps instead of discovering them in production.

Status Level

TramAI 0.6.0 is a pre-1.0 release. It is usable, and parts of it are well tested, but there is no 1.0 API, and the sovereign runtime is a release candidate.

It is in good shape for:

  • typed service-style AI integration
  • structured extraction and classification
  • local and cloud provider integration
  • Spring Boot and standalone applications
  • deterministic tests with fake providers and shared TCKs
  • governed workflows — policy, DLP, approval gates, replay-safe resume, audit — in environments you validate yourself

It is not a production-complete 1.0 and it is not a certified platform.

Not Implemented

  • Governed MCP client/connector. TramAI ships an MCP workflow server that exposes registered workflows over stdio and SSE, and tramai-orchestration provides a stdio mcpStep for calling a tool on a local MCP server under an allowlist. The reverse direction is not implemented: remote MCP tools cannot yet be imported into the TramAI tool registry and governed through the tool-permission lifecycle. The repository's MCP governance boundary document describes exactly this as a design boundary for future work, and states that nothing in it constitutes a runtime guarantee.
  • Provider-native structured output modes. Structured output runs through TramAI's schema-in-prompt pipeline for every provider. No provider's native JSON-schema mode is used.
  • Generated proxy code or KSP support. Service proxies are built at runtime through reflection.
  • Key rotation for sovereign persistence encryption keys.
  • Production deployment certification. No cloud-provider production certification exists, and the sovereign runtime is not certified for regulated deployment.
  • A production-grade reviewer UI, enterprise IAM, and a production-grade admin REST surface. The reviewer UI ships disabled by default, and the approval REST/control-plane surfaces are preview.

Partially Implemented Or Reserved

  • Codex/ChatGPT auth-file reuse exists in the OpenAI adapters but is experimental, and intended for local experimentation.
  • Streaming failover applies only before the first token reaches the caller. TramAI makes no attempt at partial mid-stream recovery across providers.
  • Approval control plane and reviewer UI are preview surfaces; the reviewer UI is disabled by default.
  • Operational modules — tramai-dashboard, tramai-mcp, tramai-memory-store, tramai-server — are implemented in the repository but are internal and not published in 0.6.0. Do not treat them as consumer artifacts. See API Stability.
  • Workflow ergonomics are preview even though the sovereign store and runtime SPIs are release-candidate stable.
  • JDBC persistence provisioning. The application database must have the TramAI schema migrations applied before startup; migration execution is not part of the documented startup path.
  • Per-provider timeout and retry policy configuration does not exist. Timeouts and provider retries are set per operation.

Practical Consequences

Before you put TramAI behind real traffic, you still have to decide:

  • how aggressive your fallback topology should be for your workload
  • which secret backend you use, and whether the bundled env: / file: / Vault / AWS resolvers are enough
  • how much provider-specific behavior you accept, since provider adapters are preview
  • which JDK line you run on, and how you validate the sovereign release candidate in your own environment

What Is Solid Already

These areas are implemented and tested; several are still evolving, but they are not stubs:

  • typed service proxies, structured-output schema generation, validation, and the retry loop
  • explicit provider registry and routing, provider retries for transient failures, and per-attempt timeouts
  • streaming with explicit terminal failure semantics
  • engine-owned tool calling and tool-result filtering
  • standalone builder and Spring Boot auto-configuration
  • policy engine, DLP redaction, approval gates, and replay-safe resume
  • sovereign routing with trust zones and local/cloud enforcement
  • encrypted file-backed persistence, JDBC persistence, audit chain, audit outbox, and worker recovery
  • runtime evidence export
  • OpenTelemetry observers and metrics, and engine-owned token budgets based on provider-reported usage
  • orchestration with step-boundary checkpointing and lease-aware worker coordination
  • deterministic test support, shared provider and store TCKs, and consumer compilation gates

Recommended Usage Today

TramAI is in its best shape for:

  • internal tools
  • developer platforms
  • service-side extraction and classification workloads
  • production pilots with explicit guardrails
  • governed workflow deployments where you own the operational validation

If you need a certified platform, a stable 1.0 API, or fully autonomous multi-agent behavior, wait for a later release or build those layers explicitly on top.

Related Pages

Previous
Next