The main point was simple:

• Semantic search should help the agent find candidate rows.

• SQL should still be responsible for grounding, joining, filtering and returning the final evidence.

That post was mostly about the design pattern.

This one is about a concrete example.

I want to show what actually happens when a user asks a natural language question that cannot be solved well with plain SQL alone, but also should not be answered directly from a vector index.

The goal is not to show that the agent can generate a clever SQL query.

That would miss the point.

The interesting part is that the question mixes two different kinds of intent:

1. A semantic intent: find publications about a concept.

2. Structured constraints: restrict the search by language and publication year.

That is exactly the kind of case where hybrid SQL + semantic search becomes useful.

The example question

The user asks:

At first sight this looks simple.

But there is quite a lot happening inside that sentence.

The user is not asking for publications whose title contains the exact words:

They are asking for publications that are semantically related to that topic.

At the same time, they are not asking for any publication in any language and any year. They want:

And they want structured output:

That means the agent has to combine semantic retrieval with structured database grounding.

This is the kind of query I wanted to test.

Why this query?

I selected this query because it exercises several important parts of the architecture at the same time.

It is not just a Text-to-SQL benchmark question.

A pure SQL agent could try something like this:

WHERE LOWER(title) LIKE '%natural language interfaces for databases%'

But that would be too brittle.

It might miss papers about:

On the other hand, a pure semantic search system could return documents that are conceptually close, but it would have no strong reason to respect structured constraints such as publication year, language, source metadata or final database joins.

So this query is useful because it forces the agent to do three things:

1. Understand that semantic search is needed.

2. Ground natural language filters into real database values.

3. Use SQL to retrieve final structured evidence from the source tables.

That is the behavior I want from a data assistant.

Not just “generate SQL”.

Not just “search embeddings”.

But orchestrate both.

Why OpenAlex?

For this experiment I used OpenAlex.

OpenAlex is an open catalog of scholarly works, authors, institutions, venues, concepts and related academic metadata. It is useful for this kind of test because it contains both structured and semi-structured information:

• publication titles

• abstracts or searchable text

• publication years

• languages

• source names

• citation counts

• identifiers

• relationships between works and other academic entities

That makes it a good dataset for hybrid SQL + semantic search.

If the database only had clean numeric columns, SQL would be enough.

If the database only had unstructured text, a vector search demo would be enough.

OpenAlex sits in the middle. It has enough structure to require SQL, and enough text to make semantic search useful.

In this setup, the source database contains the canonical relational data, while a semantic projection is synchronized for retrieval.

A simplified view looks like this:

The key point is that:

The semantic layer is not a second source of truth. It is a retrieval projection that helps the agent find candidate documents. The final answer still comes from the structured OpenAlex tables.

High-level flow

The high-level flow is:

Each step has a clear responsibility.

The assistant first understands the task. Then it grounds the filters. Then it searches semantically, but only inside the filtered subset. Then it uses SQL to join the semantic candidates back to structured OpenAlex data. Finally, it composes a grounded answer.

Let’s walk through those steps.

Step 1: understanding the ask

The first thing the assistant has to do is classify the request.

This is not a direct identifier lookup.

The user is not saying:

The user is also not asking for a simple aggregate such as:

Instead, the user is asking for a ranked list of publications related to a topic.

That makes it a semantic research task over a SQL database.

A simplified structured interpretation of the request could look like this:

{
  "data_source”: "openalex_duckdb",
  "task_type”: "semantic_publication_search",
  "semantic_query": "natural language interfaces for databases",
  "expected_output": [
    "title",
    "publication_year",
    "source_name",
    "cited_by_count",
    "semantic_score"
  ],
  "constraints": {
    "language”: "English",
    "publication_year": {
      "gte": 2016
    }
  },
  "requires_semantic_search": true,
  "requires_sql_grounding": true
}

This structured representation is important because it separates the parts of the question.

The phrase:

belongs to semantic search.

The phrase:

does not belong to semantic search. It is a metadata filter.

The phrase:

is also a metadata filter.

And the requested fields belong to the SQL grounding step.

That separation is what allows the agent to avoid mixing everything into a single fragile SQL expression.

Step 2: filter grounding

This was one of the most interesting parts of the example.

A naive agent might translate that directly into:

language = 'English'

That looks reasonable from a natural language point of view.

But it may be wrong from a database point of view.

In the OpenAlex data, the canonical value for English is:

not:

This matters a lot.

If the agent sends the wrong filter into the semantic search layer, it may get zero candidates or, even worse, noisy candidates. And if it sends the wrong filter into SQL, the final query may return no rows even when relevant data exists.

So the agent needs to ground filter values before using them.

The corrected filter payload looks like this:

{
  "original_constraints": {
    "language": "English",
    "publication_year": {
      "gte": 2016
    }
  },
  "grounded_filters": {
    "language": "en",
    "publication_year": {
      "gte": 2016
    }
  },
  "canonicalization": [
    {
      "field": "language",
      "original_value": "English",
      "canonical_value": "en",
      "reason": "observed_standard_code_alias_dominates_literal",
      "confidence": "high"
    }
  ]
}

This is a small detail, but it is a very important one.

The system should not invent literal database values from natural language. It should inspect or infer them from observed data when needed.

In this case, the agent learns that `en` is the correct database value for English-language publications.

The year filter is easier. It is already a numeric constraint:

{
  "publication_year": {
    "gte": 2016
  }
}

So the final grounded metadata filters are:

{
  "language": "en",
  "publication_year": {
    "gte": 2016
  }
}

These filters are then passed both to semantic search and to SQL grounding.

That is the behavior we want.

Step 3: semantic search with metadata filters

The next step is semantic search.

But the key point is this:

The semantic search should not run over the whole index and then let SQL filter the results afterwards.

That would introduce unnecessary noise.

If the user asked for English publications from 2016 onwards, the vector search should only rank documents inside that subset.

This is where metadata filtering matters.

The semantic search request can be represented like this:

{
   "connection":"openalex_duckdb",
   "semantic_query":"natural language interfaces for databases",
   "source_table":"semantic_documents",
   "metadata_filters":{
      "language":"en",
      "publication_year":{
         "gte":2016
      }
   },
   "top_k":10,
   "ranking":{
      "mode":"phrase_aware",
      "signals":[
         "semantic_score",
         "lexical_score",
         "phrase_score",
         "ordered_proximity_score",
         "technical_anchor_score"
      ]
   }
}

This is the important architectural difference.

The system is not doing this:

It is doing this:

That means the vector search budget is spent on the relevant subset, not on the whole database.

A reduced semantic search output might look like this:

{
   "retrieval_mode":"vector_with_metadata_filters",
   "metadata_filters":{
      "language":"en",
      "publication_year":{
         "gte":2016
      }
   },
   "candidates":[
      {
         "document_id":"https://openalex.org/W2950067395",
         "semantic_rank":1,
         "semantic_score":0.895867,
         "matched_phrases":[
            "natural language",
            "natural language interface",
            "natural language interface database"
         ]
      },
      {
         "document_id":"https://openalex.org/W2443450302",
         "semantic_rank":2,
         "semantic_score":0.669739,
         "matched_terms":[
            "database",
            "interface",
            "language"
         ]
      },
      {
         "document_id":"https://openalex.org/W2922266198",
         "semantic_rank":3,
         "semantic_score":0.661938,
         "matched_phrases":[
            "natural language"
         ]
      }
   ]
}

At this point, the system has not answered the user yet.

It has only produced a grounded candidate set.

That distinction is essential.

Semantic search says:

It does not say:

The final answer still needs SQL.

Step 4: SQL grounding

The semantic candidate set contains document IDs and scores.

But the user asked for publication fields:

The semantic index may contain some metadata, but the source SQL database remains the system of record.

So the agent builds a SQL query that joins the candidate IDs back to the OpenAlex tables.

A simplified version of the final SQL looks like this:

WITH semantic_candidates (
    document_id,
    semantic_rank,
    semantic_score
) AS (
    VALUES
        ('https://openalex.org/W2950067395', 1, 0.895867),
        ('https://openalex.org/W2443450302', 2, 0.669739),
        ('https://openalex.org/W2922266198', 3, 0.661938),
        ('https://openalex.org/W2977173717', 4, 0.639299),
        ('https://openalex.org/W2135577628', 5, 0.633553)
)
SELECT
    w.title,
    w.publication_year,
    w.source_name,
    w.cited_by_count,
    sc.semantic_score
FROM semantic_candidates sc
JOIN works w
    ON w.id = sc.document_id
WHERE w.language = ‘en'
  AND w.publication_year >= 2016
ORDER BY sc.semantic_rank
LIMIT 10;

There are two things worth noticing here.

First, the SQL query does not try to recreate semantic search using `LIKE`.

It does not do this:

WHERE topic_name ILIKE '%natural language interfaces for databases%'

That would be a different operation. It would not preserve the semantic score from the retrieval step, and it would not be equivalent to vector search.

Second, the SQL query keeps the metadata filters:

WHERE w.language = 'en'
  AND w.publication_year >= 2016

Even though the semantic search was already filtered, keeping the SQL filters is useful as a final grounding check.

The semantic index is a projection. The source database remains the truth.

The SQL step confirms that the returned publications are still valid according to the structured constraints.

Step 5: final answer composition

After SQL execution, the agent has a small table of grounded rows.

A reduced version of the result looks like this:

{
  "rows": [
    {
      "title": "A comparative survey of recent natural language interfaces for databases",
      "publication_year": 2019,
      "source_name": "The VLDB Journal",
      "cited_by_count": 168,
      "semantic_score": 0.895867
    },
    {
      "title": "Computer-Assisted Query Formulation",
      "publication_year": 2016,
      "source_name": "Foundations and Trends® in Programming Languages",
      "cited_by_count": 9,
      "semantic_score": 0.669739
    },
    {
      "title": "NADAQ: Natural Language Database Querying Based on Deep Learning",
      "publication_year": 2019,
      "source_name": "IEEE Access",
      "cited_by_count": 31,
      "semantic_score": 0.661938
    }
  ],
  "grounding": {
    "semantic_candidates_are_not_final_answers": true,
    "final_answer_uses_sql_rows": true,
    "metadata_filters_applied_before_vector_search": true,
    "metadata_filters_confirmed_in_sql": true
  }
}

The assistant can now produce a user-facing answer:

The exact final answer can be formatted as a table, because the user asked for structured fields.

But the important part is not the formatting.

The important part is the evidence path:

Why this example matters

This example is useful because it shows the difference between a demo and a data assistant that can be debugged.

A simple vector search demo could return plausible publications.

A simple SQL agent could generate a query.

But this flow does something more interesting.

It keeps the boundaries explicit:

That boundary is important.

Without it, the system can easily drift into one of two bad patterns.

The first bad pattern is trying to solve semantic questions with brittle SQL:

LOWER(title) LIKE '%natural language interfaces for databases%'

That misses paraphrases and related terminology.

The second bad pattern is letting the vector index become the answer engine.

That makes it hard to enforce structured filters, joins, counts, permissions and auditability.

The hybrid pattern avoids both extremes.

Semantic search is used as candidate generation.

SQL is used for grounding.

The subtle bug this example exposed

This example also exposed a subtle but important failure mode.

The user said:

The first naive interpretation was:

But the OpenAlex data uses:

as the canonical value.

That means the agent must not blindly trust natural language literals.

It has to ground them.

This is especially important for categorical columns:

Natural language values often do not match stored database values exactly.

The user may say:

while the database stores:

The user may say:

while the database stores:

The user may say:

while the database stores:

A robust assistant needs a way to inspect observed values and canonicalize filters before using them.

In this example, that is what happened:

{
  "field": "language",
  "natural_value": "English",
  "observed_canonical_value": "en",
  "applied_value": "en"
}

This is not just a convenience feature.

It directly affects retrieval quality.

If the semantic search runs with the wrong metadata filter, it can return no candidates or the wrong candidates. If it runs without filters, it can waste the top-k window on irrelevant documents.

So filter grounding has to happen before semantic search, not after.

What this says about the architecture

The previous post described the direction I wanted to move toward: filtered semantic retrieval.

This example shows that pattern working in a concrete case.

The semantic projection contains enough metadata to filter before vector ranking:

That allows the agent to ask the retrieval layer:

Instead of:

That difference matters because vector retrieval is top-k based.

If the search space is too broad, good candidates inside the structured subset may never appear in the candidate window.

By pushing metadata filters into the semantic search step, the system improves both efficiency and relevance.

The architecture becomes:

The semantic projection is not a replacement for the database.

It is a carefully synchronized retrieval layer.

That is the balance I want in DataTerreno:

• keep the database as the source of truth;

• give the agent semantic discovery capabilities;

• preserve traceability and auditability;

• avoid turning the vector index into an uncontrolled data copy.

What I would improve next

This example is a good milestone, but it is not the end of the work.

A few areas are still worth improving.

First, the ranking can be refined. The top results are strong, but later results can become more peripheral. That is normal in semantic retrieval, but there is room for better reranking.

Second, the system should expose filter canonicalization more explicitly in traces. It is useful to know not only that the final filter was `language = ‘en’`, but also why the system changed `English` to `en`.

Third, semantic search should continue evolving from a simple vector lookup into a controlled retrieval subsystem with:

Fourth, evaluation matters. It is not enough for the assistant to return something plausible. We need benchmarks that test whether semantic candidates are relevant, filters are applied before retrieval, and final SQL results are grounded.

That is the kind of boring but necessary work that makes the system trustworthy.

Final thought

This example is small, but it captures the core idea.

The user asks a natural language question.

The assistant does not simply translate it into SQL.

It does not simply ask a vector database for an answer.

Instead, it decomposes the request:

That decomposition is where the value of the agent appears.

The agent is not useful because it can write a fancy query.

It is useful because it can coordinate multiple evidence paths while keeping the final answer grounded in real data.

That is the direction I want to keep exploring.

Because “talk to your data” sounds simple.

But the real challenge is not talking.

The real challenge is knowing when meaning belongs to semantic search, when structure belongs to SQL, and how to keep both connected without losing control.

This post goes one layer deeper.

The question I am exploring now is very specific:

Does it make sense to introduce hybrid SQL + semantic search inside a data agent?

Not as a replacement for SQL. Not as a magic vector database that suddenly understands the business. And definitely not as a shortcut to skip data modelling.

The idea is more modest:

Use semantic search to find candidate rows when the user asks fuzzy, conceptual or free-text questions, and then use SQL to validate, filter, join, aggregate and produce the final grounded evidence.

That distinction matters.

Semantic search is good at finding things that are about something. SQL is good at computing exact answers over structured data. A useful agent needs both, but it also needs to know where one ends and the other begins.

The limitation I hit with plain SQL agents

A classic SQL agent works reasonably well when the question maps cleanly to relational operations.

For example, in a CRM database:

How many opportunities were closed last month?

That is a natural fit for SQL:

SELECT COUNT(*)
FROM opportunities
WHERE status = ‘Closed Won’
 AND close_date >= DATE ‘2026-04-01’
 AND close_date < DATE ‘2026-05-01’;

The user asks for a count. The database has a status column and a date column. SQL is exactly the right tool.

But real questions are often messier:

Show me the opportunities related to cloud migration from last quarter.

Now we have two different kinds of intent mixed together:

1. Structured filtering: “from last quarter”.

2. Semantic matching: “related to cloud migration”.

The date filter belongs in SQL. The concept “cloud migration” may be hidden inside fields like opportunity notes, project description, meeting summaries or customer requirements.

Trying to solve this with only SQL usually means falling back to brittle LIKE predicates:

WHERE LOWER(description) LIKE ‘%cloud%’
 OR LOWER(description) LIKE ‘%migration%’

That works for obvious cases, but it misses synonyms, paraphrases and domain language:

• workload modernization

• move from on-prem to hosted infrastructure

• data center exit

• application replatforming

• hybrid cloud adoption

This is where semantic search starts to make sense.

The high-level idea

At a high level, the agent should not choose between SQL and semantic search. It should orchestrate both.

The semantic index does not answer the question. It only says:

These rows look semantically relevant.

The source database still has to answer:

Which of those rows actually match the structured constraints, permissions, joins and aggregations required by the user?

That is the core design principle I am using.

What we have implemented so far

In the current backend, the SQL agent is implemented as a self-contained TAG-style agent.

The flow is roughly:

A few details are important.

First, semantic search is exposed as an internal agent tool called sql_semantic_search. Its job is to search a private semantic index for configured SQL table rows. It returns candidate matches, primary keys, semantic rank, similarity and a ready-to-use SQL CTE snippet.

Second, the final answer is not allowed to come directly from the semantic index. The tool contract is explicit: semantic matches are private candidate rows; SQL execution over the configured database is still required for final row values, counts, joins and aggregations.

Third, the SQL agent validates every query before execution. The validator only accepts read-only SELECT or WITH statements and rejects dangerous operations such as INSERT, UPDATE, DELETE, DROP, ALTER, COPY, LOAD, PRAGMA, and similar commands.

This is not just a safety detail. It is what keeps the agent grounded in a controlled data workflow instead of turning it into a free-form code generator connected to a database.

Choosing what to index

One of the first architectural decisions is deciding which columns deserve semantic indexing.

Not every column should be embedded.

Good candidates are columns that contain free text and where exact matching is likely to fail:

• case descriptions

• opportunity notes

• support tickets

• product reviews

• contract descriptions

• tender titles

• meeting summaries

• customer requirements

Poor candidates are columns that already have precise structure:

• dates

• numeric amounts

• foreign keys

• status codes

• identifiers

• booleans

• controlled categorical values

In the backend this is configured per SQL connection using a semantic profile. A table can enable semantic search and declare its primary key and text columns.

A simplified CRM-style configuration would look like this:

{
  “connections”: [
    {
      “name”: “crm”,
      “dialect”: “postgresql”,
      “connection_uri”: “postgresql://...”,
      “default_schema”: “public”,
      “semantic_profile”: {
        “tables”: {
          “opportunities”: {
            “primary_key”: [”opportunity_id”],
            “semantic_search”: {
              “enabled”: true,
              “text_columns”: [”title”, “description”, “next_steps”],
              “batch_size”: 500
            }
          }
        }
      }
    }
  ]
}

The important part is that this is explicit. The system should not blindly embed every column in every table. That would create noise, increase cost and make the retrieval layer harder to reason about.

Mapping semantic candidates back to real rows

Once a row is embedded, we need a stable way to map the vector back to the original data.

In the current implementation, each indexed row is linked to the source table through:

• tenant id

• user id

• connection name

• source schema

• source table

• source key

• source key hash

The source key is derived from the configured primary key. If the table has a simple primary key, the source key can be just that value. If the table uses a composite key, the key is serialized as a JSON array.

This is a small but critical detail.

The semantic index should not become a second source of truth. It should behave more like a search accelerator. It helps the agent find candidates, but the source database is still responsible for returning the actual rows.

That also keeps the index compact. The current model stores the vector, source identity, content hash, embedding model and synchronization metadata. It does not keep a full duplicated copy of the original row.

That is good for control and simplicity, but it also creates one of the next challenges: filter pushdown.

More on that later.

Why CTEs are useful here

A CTE, or Common Table Expression, is a temporary named result set inside a SQL query.

It is defined using WITH and can then be referenced by the main query.

Simple example:

WITH recent_opportunities AS (
 SELECT *
 FROM opportunities
 WHERE close_date >= DATE ‘2026-04-01’
)
SELECT owner_id, COUNT(*)
FROM recent_opportunities
GROUP BY owner_id;

You can think of it as a readable intermediate step:

In our hybrid SQL + semantic search flow, CTEs are useful because the semantic tool can return a small candidate set as a SQL fragment.

For example:

WITH semantic_candidates_opportunities(
  opportunity_id,
  semantic_rank,
  semantic_similarity
) AS (
  VALUES
  (’OPP-001’, 1, 0.91),
  (’OPP-017’, 2, 0.88),
  (’OPP-042’, 3, 0.84)
)
SELECT
  o.opportunity_id,
  o.title,
  o.stage,
  o.close_date,
  sem.semantic_rank,
  sem.semantic_similarity
FROM opportunities o
JOIN semantic_candidates_opportunities sem
  ON o.opportunity_id = sem.opportunity_id
WHERE o.close_date >= DATE ‘2026-04-01’
  AND o.close_date < DATE ‘2026-05-01’
ORDER BY sem.semantic_rank;

The CTE acts as a bridge between the semantic retrieval layer and the relational database.

This pattern is simple, debuggable and portable enough to test across different SQL engines.

It is also very useful for agents because the CTE is explicit. The model does not need to invent a vector function inside SQL. It receives concrete candidate keys and joins them back to the source table.

The filtering problem

Now comes the interesting part.

Suppose the user asks:

Find sales of products related to technology during last month.

There are two possible execution strategies.

The naive strategy is:

1. Run semantic search for “technology” across all products.

2. Get the top semantic candidates.

3. Use SQL to filter those candidates to last month’s sales.

This works, but it can be inefficient and noisy.

Why?

Because the semantic search was performed over the full product universe, not over the subset of products that were actually sold last month.

The top semantic results may include products that are conceptually related to technology but irrelevant to the time window. By the time SQL applies the date filter, many good candidates may already have been lost because the vector search spent its top-k budget on rows outside the structured constraint.

The better strategy is:

1. Use SQL-like filters first to restrict the candidate universe.

2. Run semantic search only inside that filtered universe.

3. Return candidates that are both semantically relevant and structurally valid.

This is the architectural tension.

To do filtered semantic search efficiently, the semantic index needs to know more than just embeddings. It also needs enough structured metadata to apply filters before vector search:

• dates

• tenant / user scope

• source table

• identifiers

• foreign keys

• status fields

• maybe some categorical dimensions

That means the semantic index starts to look like a synchronized projection of part of the SQL database.

And that requires a synchronization mechanism.

Where the current implementation stands

The current backend already has the synchronization mechanism for semantic indexing.

It scans configured source tables in batches, extracts the configured primary key and text columns, builds an embedding payload from the text, computes hashes, calls the embedding provider in batches and upserts rows into a PostgreSQL/pgvector-backed semantic index.

The index is scoped by tenant and user. That is important because semantic retrieval is not a public search operation. It happens inside the user’s private context.

The current implementation also keeps the semantic index intentionally compact. Legacy payload columns are cleared when possible, and the index keeps the source key and embedding metadata rather than becoming a full copy of the source table.

That is a good first step.

But it also means that full filter pushdown is not implemented yet.

At query time, the current agent usually does this:

1. Run semantic search across the configured semantic table.

2. Get candidate primary keys.

3. Build a CTE with those candidates.

4. Join the CTE back to the source table.

5. Apply SQL filters such as dates, status or exact identifiers.

6. Generate the final answer only from executed SQL results.

This gives us grounding and correctness control, but not always optimal retrieval efficiency.

If the structured filter is very selective, we still pay the cost of searching the broader semantic space first. The SQL filter happens after candidate retrieval, not before it.

So the current implementation is a working hybrid pattern, but not the final optimized version.

Why not just put everything into the vector database?

One possible reaction is:

Why not store all fields in the vector database and query everything there?

Because then we risk rebuilding a weaker database next to the real one.

SQL databases already know how to filter, join, count, sort, group, aggregate and enforce structure. Vector databases are useful, but they should not become the place where we reimplement relational semantics badly.

The more useful direction, at least for what I am exploring, is a controlled projection:

The projection should contain only what semantic retrieval needs:

• the embedding

• the source key

• enough metadata to pre-filter safely

• synchronization hashes

• scope and ownership fields

Not the whole operational dataset.

This keeps a clear boundary:

• SQL remains the system of record.

• The semantic index remains an acceleration and discovery layer.

• The agent orchestrates both.

The role of filter columns

The backend already has the concept of profile-declared filter columns at the agent level.

This is useful when the user explicitly scopes a value to a field.

For example:

Show opportunities where customer is ACME Corp.

The word “ACME Corp” should not be treated as a broad semantic concept. It is an exact field constraint. The agent should bind it to the configured source column, such as customer_name, and use SQL.

This avoids a common failure mode: using semantic search when the user actually gave an explicit structured condition.

However, this is different from true metadata filtering inside the semantic index.

Today, the agent can use filter hints to decide when not to run semantic search, or how to apply SQL constraints after candidates are retrieved. The next optimization step is to persist selected filterable metadata in the semantic index itself so that semantic retrieval can be narrowed before vector ranking.

That would make questions like this more efficient:

Show support cases related to authentication errors opened last week.

Instead of searching every support case ever indexed, the semantic search could first restrict the index to cases opened last week, then rank only that subset for “authentication errors”.

A possible next architecture

The next version of the hybrid search layer could look like this:

In a CRM example, the semantic projection for opportunities might include:

embedding: vector(description + notes + next_steps)
source_key: opportunity_id
source_table: opportunities
owner_id: structured metadata
account_id: structured metadata
stage: structured metadata
close_date: structured metadata
created_at: structured metadata
updated_at: structured metadata

Then the agent can push down filters like:

• last month

• account = ACME

• owner = Maria

• stage = Closed Won

• region = EMEA

before ranking semantically.

That reduces noise, improves recall inside the relevant subset and avoids wasting the top-k semantic window on rows that SQL will later discard.

But synchronization becomes a real subsystem

The moment we keep a semantic projection of SQL data, we need to answer uncomfortable questions:

• How often is the index refreshed?

• Is synchronization full, incremental or event-driven?

• How do we detect deleted rows?

• What happens when the embedding model changes?

• How do we avoid indexing stale data?

• How do we handle permissions per tenant and user?

• Which metadata columns are safe and useful to duplicate?

• How do we avoid turning the semantic index into an uncontrolled data copy?

The current backend already deals with some of this.

It uses content hashes to detect whether a text payload changed. It tracks the embedding model, so rows can be refreshed when the model changes. It uses a synchronization run ID and last_seen_at metadata. It only deletes stale rows after a complete source scan, avoiding unsafe deletion after partial syncs. It supports batch sizes, embedding batch sizes, dry runs, row limits, batch limits and commit intervals.

That is the kind of boring machinery that makes the architecture real.

The exciting part is “talk to your data”. The hard part is keeping the index coherent enough that the assistant does not talk to yesterday’s data by mistake.

Why this belongs inside an agent

Hybrid SQL + semantic search could be implemented as a fixed pipeline, but an agent adds something useful: decision-making.

Not every question needs semantic search.

For example:

• “Give me opportunity OPP-123” should be a direct identifier lookup.

• “How many opportunities closed last month?” should be SQL only.

• “Show opportunities related to cloud migration” may need semantic search.

• “Show ACME opportunities related to authentication issues opened last week” may need both.

The agent’s job is not just to generate SQL. It has to decide which evidence path makes sense.

In the backend, this is handled through a query-intent plan. The agent extracts hints such as:

• base table

• text columns

• identifier columns

• literal terms

• strong literal terms

• date filters

• whether the user wants a count, detail list or ranking

• whether semantic search should be skipped

This is still heuristic and under active refinement, but it is already useful. It prevents some bad behavior, such as running semantic search for exact identifiers or treating a column-scoped filter as free text.

Semantic candidates are not counts

One important lesson: a semantic candidate set is not the same thing as a complete result set.

If the semantic tool returns 30 candidates, that does not mean there are only 30 matching rows in the database.

It means:

The semantic retriever returned 30 candidate rows under the current retrieval settings.

This distinction matters for questions like:

How many opportunities are related to cloud migration?

If we simply count the top 30 semantic candidates, we are not answering the question. We are counting the retrieval window.

The current implementation carries this warning explicitly in the semantic payload: the candidate count is not a full database count unless a separate SQL count over a complete predicate is executed.

This is one of the reasons I do not want the final answer to come directly from vector search. Retrieval is evidence discovery. SQL is where exact computation should happen.

The pragmatic trade-off

So, is hybrid SQL + semantic search inside an agent a good idea?

My current answer is:

Yes, but only if semantic search is treated as candidate generation, not as the source of truth.

The pattern solves a real problem: SQL agents struggle with conceptual free-text questions, and pure RAG struggles with structured computation. Combining them gives the agent a better chance of answering questions that contain both fuzzy meaning and exact constraints.

But it introduces new architectural complexity:

• semantic profiles must be designed per table;

• text columns must be selected carefully;

• primary keys must be stable;

• synchronization must be reliable;

• stale rows must be handled safely;

• filter pushdown requires metadata duplication;

• query planning must decide when semantic search is useful;

• final answers must remain grounded in executed SQL results.

This is not a free lunch.

It is more like adding a new implement to the data field: useful, but only if it is attached to the right machinery.

Where I am going next

The current implementation is a first working version, not the final design.

The next area I want to optimize is filtered semantic retrieval.

The goal is to move from this:

To this:

That requires extending the semantic index from a pure vector + source-key structure into a controlled, synchronized semantic projection with selected filterable fields.

I do not know yet if this will be the most efficient approach in every case. There may be better options depending on the database engine, vector backend, data volume, query pattern and latency constraints.

But this is the path I am exploring now.

It keeps the database in charge of structured truth. It gives the agent a way to work with meaning. And it preserves a clear architectural boundary between search, computation and answer generation.

That boundary is where most of the interesting work is happening.

Because “talk to your data” sounds simple.

But once the questions become real, the system has to cultivate both sides of the field: the structure of the database and the semantics of human language.

Data has become one of the most valuable assets any person, team or organization can own. But owning data is not the same as controlling it. And controlling it is not the same as understanding it.

That gap is where this blog starts.

Over the last few years, I have been working around data platforms, Data Lakehouse architectures, language models, conversational assistants and agentic AI. What began as an academic project - Talk to your data, a final degree project about Table-Augmented Generation - has gradually turned into a much broader exploration: how can we make data more accessible without giving up control over it?

That question is technical, but it is also strategic.

Because every time an organization moves its data, its models, its metadata, its identity layer or its analytical workflows into someone else’s black box, it gains convenience but loses part of its autonomy. Sometimes that trade-off makes sense. Sometimes it does not. But it should always be a conscious decision.

This blog is a place to document that journey.

Not as a collection of polished marketing stories, but as a field notebook: things tested, things broken, architectures explored, design decisions, failed assumptions, small discoveries, technical trade-offs and lessons learned while building systems around data sovereignty, AI and modern analytics.

The core idea: cultivate your own knowledge

At DataTerreno, the metaphor is simple: data is raw land.

You do not get value from land just by owning it. You need to work it. You need to prepare it, clean it, structure it, protect it and make it productive. The same happens with data.

Raw data is messy. It comes from different systems, in different formats, with different levels of quality and trust. Before it can support decisions, it needs engineering. Before it can feed AI, it needs context. Before it can become knowledge, it needs to be governed.

But there is a second part to the metaphor: the land is yours.

The point is not to hand over control of your data to intermediaries and hope for the best. The point is to build tools that allow organizations to understand, protect and grow their own knowledge without unnecessary dependencies.

That does not mean rejecting cloud, commercial platforms or managed services by default. It means avoiding blind dependency. It means keeping architectural options open. It means understanding what is happening under the hood. It means being able to decide where your data lives, who can access it, what models process it and how the results are audited.

Data sovereignty is not nostalgia for on-premises infrastructure. It is the ability to choose.

From “talk to your data” to agentic systems

The first major milestone in this journey was my final degree project: an assistant capable of interacting with structured data using natural language.

The original idea was simple to explain but difficult to implement well: what if a user could ask a database a question in plain language and receive a useful answer without knowing SQL, table schemas or query engines?

Classic Text-to-SQL is part of the answer, but not the whole answer. Translating a question into SQL works well when the question maps cleanly to relational operations. But real questions are often messier. They may require interpretation, classification, summarization, external knowledge or multi-step reasoning.

That is where Table-Augmented Generation becomes interesting.

TAG connects three worlds:

1. The precision of database systems.

2. The semantic flexibility of language models.

3. The conversational interface that makes data accessible to more people.

Instead of treating the language model as a magic box, the system must orchestrate it with tools: inspect schemas, generate queries, execute them, validate results and compose a final answer grounded in real data.

This naturally led to agentic patterns such as ReAct, where the model alternates between reasoning and acting. In practice, that means the assistant can think about the task, decide to inspect a schema, execute SQL, observe the result, correct itself if needed and then produce an answer.

That loop is where many interesting problems appear: hallucinations, invalid SQL, schema ambiguity, context limits, tool errors, infinite loops, unclear user intent, permission boundaries and evaluation difficulties.

Those problems are exactly the kind of material this blog will explore.

The platform underneath matters

A conversational assistant is only as useful as the data platform behind it.

That is why another line of work has focused on building and orchestrating an on-premises Data Lakehouse platform: object storage, metadata services, query engines, identity, permissions, deployment automation and operational visibility.

The goal is not to rebuild a hyperscaler from scratch. The goal is to understand which components are needed to run a modern data platform under your own control.

A typical pattern looks like this:

A sovereign architecture is not just about running services on-premises. It is about keeping data, metadata, identity, permissions, inference and auditability under conscious control.

The hard part is not deploying containers. The hard part is making the system coherent:

• identity should be centralized;

• permissions should follow the user;

• data access should be auditable;

• models should not bypass governance;

• assistants should not invent answers;

• generated artifacts should be traceable;

• and the platform should remain portable.

This is where data architecture and AI architecture stop being separate disciplines.

What I will write about

This blog will be mainly technical, but not purely theoretical. The idea is to write from the trenches: what I am building, testing, debugging and learning.

Some of the topics I expect to cover:

Data sovereignty and architecture. What it means to design platforms that preserve control, portability and independence. Where on-premises makes sense, where cloud makes sense, and where hybrid models become unavoidable.

Data Lakehouse platforms. Storage, compute, metadata, federation, open formats, Kubernetes deployments, identity integration, observability and operational patterns.

AI assistants over data. TAG, Text-to-SQL, RAG, semantic search, SQL agents, tool calling, query validation, result grounding and conversational interfaces.

Agentic AI. ReAct-style loops, supervisors, worker agents, tool registries, traces, memory, routing, failure handling and the difference between a demo agent and a reliable system.

Evaluation. How to test assistants that interact with data. Benchmarks, difficulty levels, deterministic validation, qualitative metrics and why “it answered something plausible” is not good enough.

Security and governance. Authentication, authorization, guardrails, audit trails, tenant isolation, data permissions and the risks of connecting LLMs directly to enterprise data.

Open-source and local AI. Running models with vLLM, using open models, deploying inference services locally, embedding models, GPU constraints and the trade-offs between control and convenience.

And probably many unexpected things along the way.

Because every real project starts with a clean diagram and ends with logs, edge cases and uncomfortable questions.

The tone of this blog

This will not be a blog about hype.

AI is useful, but it is not magic. LLMs can reason surprisingly well in some contexts and fail absurdly in others. Agents can automate workflows, but they can also loop, hallucinate or call the wrong tool with total confidence. Data platforms can provide powerful abstractions, but they still depend on good engineering.

So the tone here will be pragmatic.

When something works, I will explain why I think it works. When something fails, I will try to understand the failure. When a design decision has trade-offs, I will make them explicit. When I am not sure, I will say so.

The objective is not to sell a perfect architecture. The objective is to learn in public.

A starting point

This blog starts from one conviction:

Organizations should be able to extract value from their data without losing control over it.

That requires more than technology. It requires architecture, governance, security, usability and a clear understanding of what AI can and cannot do.

But technology matters. Tools shape possibilities. If the only practical way to use AI over your data is to send everything to an external platform, then sovereignty becomes theoretical. If only technical experts can access information, then data-driven decision-making remains limited. If assistants cannot be audited, they cannot be trusted.

So the challenge is clear: build systems that make data easier to use while keeping it under control.

That is the ground this blog will cultivate.