SovrenAI
Internal apps built on company data, with a person confirming every guessed join
We built Enterprise Builder for SovrenAI, an AI builder that turns an organization's own databases into internal apps, with guardrails that can be checked. A guessed join stops the build for a person, every query passes EXPLAIN first, and nothing publishes until a security scan passes.
B2B SoftwareEnterprise Builder, an AI internal app builderBuilt from zero
The challenge
An agent writing queries over unknown schemas can silently join the wrong tables and return numbers that look right but are not, and buyers want proof that agents are measured.
What we did
Agents pause on a guessed join, EXPLAIN checks each query before a sample run, a scan gates every publish, and an evals harness scores the build agent.
The outcome
The guardrails and governance layer are built and tested, and the founder has a measured baseline for the build agent instead of a demo. Azure deployment comes next.
- Joins
- A guessed join pauses the build for approval
- Queries
- EXPLAIN on Postgres, MySQL or Snowflake first
- Publishing
- Blocked on leaked secrets, unsafe SQL or PII columns
- Governance
- SSO, append-only audit log, model per organization
The starting point
Enterprise Builder is an AI builder from SovrenAI that lets organizations connect their databases and build internal dashboards and workflow apps on them. It is the enterprise member of a family of builders we already engineer for the same founder.
What had to change
Organizations need small internal apps on their structured data, but an agent writing queries over unknown schemas can silently join the wrong tables. A wrong number that looks right is worse than no app at all.
What could not break
- The AI never guesses how tables join; a person confirms
- Queries are checked by the database before any sample run
- Starter ideas come from metadata, never table contents
- Nothing publishes with leaked secrets, unsafe SQL or PII columns
- Every sign in, member, model and publish event is recorded
The calls we made
We chose guardrails that can be checked rather than promised: the agent shows its joins, the database checks its queries, a scan gates publishing and a harness measures the whole build.
- 01
Grade every join
Agents grade each join against the data catalog. A guessed or unknown join pauses the build for a person, a rejected join sends it back to table selection, and an edit that adds an unconfirmed join asks as well.
Ruled outLetting the agent infer joins silently from column names.
- 02
EXPLAIN before running
Every generated query goes through EXPLAIN on Postgres, MySQL or Snowflake before any sample run, and errors feed a repair loop, so planning mistakes surface without reading data.
Ruled outSample runs on company data before the query is checked.
- 03
Measure with golden prompts
An evals harness runs golden prompts through the real build agent in throwaway databases and compares runs. It caught a structured output problem with one model, and we reverted that change.
- 04
Suggest from metadata only
Starter app ideas come from PII safe catalog metadata, with a rule based fallback, and are stored with a fingerprint of the catalog they came from.
Ruled outSending table rows to the model to suggest apps.
- 05
Security a reviewer can check
Before an app publishes, a scan looks for leaked secrets, unsafe SQL, unsafe content and PII columns and blocks serious issues. Sign in runs through Microsoft Entra ID or Okta, and an append-only audit log records sign in, member, model and publish events.
Ruled outPublishing generated apps unscanned and leaving audit to the database logs.
How the system fits together
What we built
Governance layer
Security scans that block publishing on serious issues, single sign on with Microsoft Entra ID and Okta, per organization model routing with an audit entry, and an append-only audit log with filters, search and CSV export.
Starter apps from metadata
Three to five suggested starter apps per data source, generated from PII safe catalog metadata with a rule based fallback and shown on the generate screen.
Join approval
Approval cards for guessed or unknown joins, in new builds and in edits made with the edit agent, with a rejected join sending the build back to table selection.
SQL validator
EXPLAIN checks on Postgres, MySQL and Snowflake before any sample run, with every error fed into a repair loop.
Evals harness
Golden prompts, starting with a set of retail cases, run through the real build agent in throwaway databases and are scored on build success, spec validity, query success, answer accuracy against reference SQL, tables used, PII use, repairs, fallbacks and time, with runs compared side by side.
How it works
Connect
An organization connects a database, and the builder reads its catalog.
Suggest
The AI suggests three to five starter apps from PII-safe metadata.
Plan joins
The agent grades each join against the catalog, and a guessed one waits for a person to approve it.
Check the query
Each query passes EXPLAIN before a sample run, and failures go to a repair loop.
Build and edit
The app is generated, and later edits go through the same approvals.
A closer look
{
"case": "retail_weekly_orders_by_store",
"prompt": "Weekly orders by store, with returns",
"database": "throwaway_retail_db",
"build_success": true,
"spec_valid": true,
"query_success": true,
"answer_matches_reference_sql": true,
"tables_used": ["orders", "stores", "returns"],
"pii_columns_used": 0,
"repairs": 1,
"ai_fallbacks": 0,
"time_s": 38,
"result": "pass"
}What changed
The guardrails are built and tested, with join approval covered by its own tests and eval case. The evals harness gives the founder a measured baseline for the build agent instead of a demo. The product is in development and not yet used by customers.
Under the hood
- Datics role
- Product built by Datics
- Agents
- LangGraph agents behind a FastAPI backend, with a CopilotKit chat in a Next.js front end, and Azure OpenAI or Claude chosen per organization with a default fallback.
- Data boundary
- Starter ideas use PII safe catalog metadata, joins are graded against the catalog, and queries pass EXPLAIN before they touch data.
- Identity and audit
- Microsoft Entra ID and Okta single sign on, rate limits and security headers, and an append-only audit log with CSV export.
- Deployment
- An Azure package of Dockerfiles, Bicep templates and a GitHub Actions workflow, with OpenTelemetry tracing and Langfuse for agent runs; hosted, hybrid or client side models planned.
AI and models
Apps and APIs
Also in the stack
How it shipped
Direction and design
We proposed the enterprise version, scoped it to structured data, and designed the landing page, main screens, a UI kit and a prototype.
Front end first
We built the front end first, from sign in to the generate screen and its chat, and reused backend components from the founder's other builders.
Status checked against code
We reviewed the founder's feature status list against the code, found features marked not started that were partly built, and planned the rest as MVP, V1 and V2.
Guardrails, governance and evals
Join approval, the SQL validator, the edit agent, the evals harness, starter apps, publish scans, SSO, the audit log and an Azure deployment package were built and tested in the browser.
Scoped with the founder
We framed the split with the founder: his grounded content engine handles documents, and this builder handles structured data such as databases and CSVs.
Tested in the browser
Each feature was integration tested and checked in the browser, with a test script, a status report and a test guide for the MVP.
What this unlocked
Next are the remaining MVP items and deployment to Azure, with the founder's own company data, from CSVs to accounting and invoicing systems, as the first use case.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.