Why we built an agent platform on Spring Boot/Java 21, schema-per-tenant Postgres, and Keycloak

Multi-tenancy in most agent tools means rows tagged with a workspace ID in shared tables — one missed WHERE clause away from showing one customer another customer's data. VegaDūtagives every tenant its own Postgres schema. An agency running agents for twenty clients gets twenty isolated schemas under one deployment; a query physically cannot wander into a neighbour's tables.

Secrets follow the same boundary: provider API keys and channel credentials are encrypted at rest, per tenant. Isolation this hard is what the big workflow tools sell as white-label enterprise contracts; here it is the default architecture, on every plan.

Agents that act on your business need brakes, not just prompts. VegaDūta's runtime enforces guardrails in the platform — including credential redaction on tool traffic — rather than trusting each agent's prompt to behave. Consequential actions can be routed through an explicit human-approval step: the agent proposes, a person approves, and only then does the action execute.

Everything lands in an audit log, scoped to the tenant. When someone asks "why did the agent say that, and who approved the refund?" there is an answer — which is the difference between a demo and a system a bank-adjacent buyer will sit through a review with.

Identity is not homegrown. Authentication and session management are delegated to Keycloak, the same open-source identity server used across enterprises — OAuth2/OIDC with PKCE, not a bespoke login table.

The fastest way to lose trust in an AI platform is a surprise model bill. VegaDūtameters model spend per user per day against a configurable dollar budget, enforced in the platform — when the budget is reached, the platform degrades predictably instead of billing infinitely. Combined with a hosted-model pool that falls back across providers when one fails, cost and availability are runtime concerns the platform owns, not spreadsheet estimates.

Java is not fashionable in AI, and that is precisely the point. Indian IT services, banks, and mid-market enterprises run on the JVM; their engineers can audit a Spring Boot codebase, their ops teams know how to run one, and their security reviews know what questions to ask of it. A typed, multi-module Java 21 backend with explicit module boundaries (billing, tenancy, agents, guardrails, channels, audit) is easier to reason about under load than a prototype that grew organically.

The AI-native parts live where they belong: Python services handle knowledge/RAG-pipeline work and codebase intelligence, fronted by the same Java core and the same identity, tenancy and audit rules. Voice and Indic language support run through Sarvam's India-built models. The stack is boring where boring wins, and modern where it matters.

Honesty is cheaper than a failed procurement call, so here is the current state, stated without varnish:

• Self-hosted, single-region today. The platform runs on infrastructure we operate in one region. Automated backups, restore drills and alerting are the active engineering priority; multi-region high availability is on the roadmap, not in production.
• No SOC 2 or ISO certification yet. We run internal security reviews and will pursue formal certification when enterprise engagements require it. If your procurement process requires a certificate today, we are not there yet — we would rather tell you that here than in week six of an evaluation.
• A smaller ecosystem. Dozens of tool integrations (via MCP connectors and built-in tools), not the hundreds a decade-old automation platform has.

What is real today: schema-per-tenant isolation, Keycloak-fronted auth, guardrails with human approval and audit, per-user budgets, WhatsApp/Telegram/voice channels in 22 Indian languages, UPI billing, and a sandbox you can open without an account.