TQL Was Designed for LLMs to Write — Here's How It Works

The failure modes are predictable: implicit Cartesian products from missed join conditions, ambiguous column references after multi-table joins, NULL semantics that models reason about incorrectly, and quoting rules that vary by dialect. Each one looks like a one-off bug; collectively they make agent-generated SQL unreliable past a few joins.

TQL is declarative without being relational. Queries name what you want by type, not by table. There are no joins because the data model doesn't have foreign keys to chase — the participants in a fact are endpoints on the hyperedge, each identified by its role. And temporal, branch, and confidence context are first-class, so “high confidence, valid in the last 90 days” is a filter you attach, not a subquery you assemble.

The effect is that no clause depends on column-resolution order and there are no JOIN ON conditions to forget. That's the property that makes a language easy for a model to get right on the first try: fewer places where a plausible-looking query is silently wrong.

The job of an enterprise database in 2026 is to be queryable correctly by a non-deterministic process. The cost of an off-by-one in an LLM-generated WHERE clause shows up in regulator reports. Languages that constrain the model towards right answers — not languages that maximally expose database internals — are what the next decade calls for.

SQL was designed for humans to write rarely. TQL was designed for agents to write constantly. Same problem space, very different design constraints.

Tessera also accepts Cypher and SQL over the same data, so existing skills port and you're never locked into one language. But measure your agent's success rate across all three on the queries your application actually generates. We did, and TQL won by a margin that decided the project.