Ora v2.0 Agentic Intelligence Release

The v2.0 release transforms Ora from a pipeline-based NL2SQL system into a fully agentic runtime that reasons about its own work, learns from every interaction, and gets measurably smarter over time.

Ora v2.0 — full demo walkthrough

Contents

Architecture: ReAct Orchestrator

The v1.0 multi-node pipeline (12 nodes, conditional routing) is replaced by a single ReAct orchestrator that thinks, delegates, validates, and re-routes in one loop.

Ora ReAct Orchestrator (single node) | +-- Phase 1: Decompose | intent, entities, query structure, cross-source detection | +-- Phase 2: Semantic Resolve | alias pre-check, pattern injection, failure reflection | +-- Phase 3: Schema Context | CHESS LSH pruning, column validation against actual schema | +-- Phase 4: SQL Generation | 3 candidates, parallel, self-correct up to 3x | +-- Phase 5: Semantic Fitness Check | LLM reviews "does this result answer the question?" | +-- Phase 6: Validate & Learn evolve semantic layer, record rule outcomes | +-> respond (NL summary + chart + follow-ups) +-> learn (aliases, patterns, enrichments, rules) LangGraph: ora -> respond -> learn (3 nodes)

What Ora validates at each step

Semantic Layer Evolution

The semantic layer evolves through 4 layers, each building on the previous:

Layer 1: Foundation connect time

analyze_source() discovers domain, column meanings, abbreviation maps, dimension/measure classification. build_initial_taxonomy() detects cross-source join candidates and entity types.

Layer 2: Inferred from data patterns

Entity aliases, value mappings (e.g., "friday" -> 5), cross-source joins detected via column name/type matching.

Layer 3: Confirmed from successful queries

evolve_semantic_layer() runs after every successful query. Saves aliases (+3% confidence per confirmation), relationships (with query count), filter patterns (auto-injected after 3+ uses), and column enrichments.

Layer 4: Corrected from user feedback

Structured rules created from corrections with confidence lifecycle. Resolution failures recorded as anti-patterns so the agent avoids repeating mistakes.

Semantic Agent Reasoning Loop

  1. Pre-check — high-confidence aliases (>=0.93) resolved deterministically. Known patterns and column enrichments injected. Past failures loaded as anti-patterns.
  2. LLM reasoning — entity mapping with full schema context, column meanings, and learned vocabulary.
  3. Schema search — for unresolved entities, targeted DB lookups across text columns.
  4. Refinement — merge findings, update confidence, save resolution log entry.

Persistence

All semantic layer state persisted to ~/.sqlagent/uploads/{workspace_id}/:

FilePurpose
semantic_manifest.jsonVersioned iteration tracking with history
semantic_{source_id}.jsonPer-source context (domain, column meanings, tips)
aliases_{source_id}.jsonLearned entity mappings with confidence
relationships.jsonConfirmed table joins with query count
query_patterns.jsonCommon filter combinations
column_enrichments.jsonColumn usage context
resolution_log.jsonResolution audit trail (last 200)
rules.jsonStructured rules from corrections

Structured Rule Engine

New file: sqlagent/rules.py

from sqlagent.rules import load_rules, create_rule, record_rule_outcome

rules = load_rules(workspace_id)  # sorted by confidence * log(hit_count)
create_rule(workspace_id, text="DuckDB doesn't support YEAR()", source="user_correction")
record_rule_outcome(workspace_id, rule_ids, succeeded=True)  # +0.05 confidence

Rule lifecycle

Semantic Fitness Check

After SQL executes successfully (rows > 0), Ora asks the LLM: "Does this SQL + result actually answer the original question?"

The fitness check catches:

If not fit, Ora re-routes with the specific fix hint from the LLM.

REST API Connectors

New framework: sqlagent/connectors/rest_connector.py

from sqlagent.connectors.catalog.shopify import ShopifyConnector

conn = ShopifyConnector(source_id="shop", store_name="mystore", api_key="shpat_xxx")
await conn.connect()  # pulls data into DuckDB
result = await conn.execute("SELECT * FROM orders LIMIT 10")

Built-in connectors

ConnectorTablesConnection URL
Shopifyorders, customers, products, inventory, collectionsshopify://store?api_key=xxx
Salesforceaccounts, contacts, opportunities, leads, casessalesforce://instance?access_token=xxx
Stripecharges, customers, subscriptions, invoices, payoutsstripe://?api_key=xxx
HubSpotcontacts, companies, deals, ticketshubspot://?api_key=xxx
Google Analytics 4sessions, users, eventsga4://property_id?access_token=xxx
Airbyte (300+)any Airbyte sourceairbyte://?source=source-name

The RestConnector base class handles OAuth2 (with refresh), API key, Bearer token, Basic auth, cursor/offset/link-header pagination, and token-bucket rate limiting.

Knowledge Page

The Knowledge page is the Semantic Agent's working memory — three tabs:

Learning System

How learning improves queries

  1. Training pairs — every thumbs-up/correction saved to Qdrant (persistent on disk). Retrieved via cosine similarity for few-shot prompting.
  2. Context rules — extracted from corrections, injected into every SQL generation prompt.
  3. Entity aliases — learned mappings (e.g., "friday" -> 5) pre-resolved before LLM call at >=93% confidence.
  4. Filter patterns — common filters (e.g., sex='Total') auto-injected after 3+ confirmations.
  5. Failure reflection — past resolution failures loaded as anti-patterns.

Observable in traces

Every query trace shows an "Applied learned context" node:

Applied learned context
  3 past examples (best: 'top selling product' sim:0.94)
  2 rules applied
  4 context notes
  12 pre-resolved aliases
  semantic layer v8

Learn page metrics

UI Updates

New API Endpoints

EndpointMethodPurpose
/learn/re-executePOSTExecute edited SQL from correction flow
/api/semantic/historyGETSemantic layer evolution history
/api/semantic/graphGETGraph-ready semantic model
/api/learn/impactGETAccuracy trend and rule inventory

Bug Fixes