ESRA — the Enterprise Semantic Retrieval Agent — lets an AI client ask a question in plain language and get back governed evidence from the enterprise databases you already run, with no separate searchable copy of your data required.
ESRA is published to AI clients as an ordinary MCP tool through the Runtime, so everything that already governs a tool call — authentication, access policy, audit, tenant isolation — governs a retrieval call too, unchanged.
From a plain-language question to cited evidence, without ever letting the model write or run SQL against your data.
Databases are modelled in business terms — what to search, what identifies a record, what carries its title and business date. Which columns may be filtered on or must be masked stays a deliberate governance decision, never a guess.
A service LLM selects the relevant sources from their business descriptions — never schemas, never credentials — and plans several search strategies per source: exact phrase, broad keyword, synonyms, acronym expansion.
The model produces structured intent, never SQL. Every plan is validated deterministically, then executed as parameterized full-text queries against a read-only database principal, with per-source timeouts and row caps.
Record-level access restrictions derived from the caller's claims are applied inside the query itself, as a parameterized predicate — not by filtering results in memory after the fact.
Results are normalized, merged, deduplicated, and reranked semantically. Where the exposure permits it, ESRA composes a grounded answer citing only the evidence it retrieved — no evidence means no answer.
Retrieval and follow-up fetch are published as ordinary MCP tools through the Runtime, so discovery, authorization, audit, and tenant scoping work exactly as they do for every other tool.
A deliberate choice with concrete consequences for security, explainability, and operational cost.
Retrieval runs on the native full-text engine of the database itself — PostgreSQL tsvector / ts_rank_cd / ts_headline, or SQL Server CONTAINSTABLE with native RANK. There is no embedding job, no vector store to secure, and no staleness window between a record changing and an index catching up.
A result's score traces to term matches in named fields with configured weights — not to a distance in an opaque embedding space. That is a difference auditors and engineers both care about.
No separate indexing infrastructure to license, size, or keep in sync. ESRA runs inside your licensed Runtime capacity and searches databases you already operate.
A source, a capability, and an exposure — each one can only narrow what the level beneath it permits. The same capability can be published twice, to two different audiences over two different sets of sources, without duplicating configuration.
Connection, search mappings, fields, and limits. Onboarding starts by reading the database catalog — relations, columns, types, existing full-text indexes — and proposing what to search. Which fields may be filtered or must be masked is always a governance decision, set explicitly.
Response modes, top-K result count, time budgets, and the model profile used for planning and reranking — configured once, reused across every exposure built on it.
Which audience, which access policy, which sources. An exposure may remove a source, lower a top-K, or drop a response mode — never grant more than the capability, and the capability never grants more than the source permits.
ESRA adds no separate governance surface. Authentication, access policy, audit, and tenant isolation are the platform's — retrieval just uses them.
ESRA connects to the relational, search, and document engines you already run. Every source is modelled the same way regardless of provider — read from the database's own catalog, then narrowed by an operator, never guessed.
Native tsvector / ts_rank_cd / ts_headline full-text search, read directly off the database's own catalog.
CONTAINSTABLE with native RANK. Configurable transaction isolation — read committed by default, snapshot where the database allows it.
Native full-text indexes read through the same connection-string-plus-secrets shape as every other ADO provider.
Reads the catalog for relations and columns; full-text search requires an existing index or Oracle Text licensing.
Reached over REST with a credential-free base URL and an API key or HTTP basic auth mode, both resolved from a secret.
Native binary protocol, not ADO or REST. Configurable read preference (secondary-preferred by default) keeps search load off the primary.
A tenant-unique name, the provider type, and a selection mode — Mandatory, Optional, PolicyForced, or Disabled. Draft, Published, or Retired lifecycle state and an independent Enabled kill switch decide whether the source can serve at all.
provider: "PostgreSql" selection: "Optional" priority: 10 enabled: true
A connection-string template or base URL that never contains credentials — username, password, and API keys are secret-store references resolved per use. Every host is checked against the platform's outbound allow-list before a connection opens, and the principal must be read-only.
connectionString: "Host={h};Database={d}"
username: secret://db-user
password: secret://db-pass
requireReadOnly: true
requireTls: trueEach searchable entity names its relation, record key field, title field, and business timestamp. Every column is flagged Searchable, Returnable, Filterable, or Restricted — a field with none of the three is invisible to ESRA entirely.
recordKeyField: "id" titleField: "subject" fields: body: [Searchable, Returnable] ssn: [Restricted]
An allowed response-field list, per-field masking (Full, PartialTail, or Hash), and a record filter template bound from the caller's claims at request time — applied inside the query itself, never after it. A missing claim fails closed.
filter: "tenant_id = @claim:tenant_id"
masking: { ssn: "PartialTail" }
allowAnswerGeneration: trueSix documents covering data sources, capabilities, the retrieval pipeline, governance, the document store, and operations.
Connections, search mappings, and fields.
Read more →Retrieval behaviour and publication.
Read more →How a retrieval call executes end to end.
Read more →Roles, authorization layers, record-level filters.
Read more →The internal document repository and upload.
Read more →Audit records, metrics, health, and diagnostics.
Read more →ESRA is not licensed separately. It runs inside your licensed Runtime capacity, with no per-document, per-query, or per-index charge — on Starter, Team, and Enterprise alike.