Think inside your AI world.
Text-to-SQL is not the answer
Text-to-SQL is a genuine advance at what it does: you ask in English, it writes the query, the number comes back. But notice what it returns — a figure. It has translated your question into retrieval and solved retrieval, which was rarely the thing standing between you and a decision. “Is this good enough” does not compile to SQL, because the bar it needs is not in the database.
Ask “what’s our conversion rate” and text-to-SQL earns its keep: the query is fiddly, the English is easy, the number is correct. Ask “is our conversion rate acceptable” and it has nowhere to go — acceptability is not a column. Unl supplies exactly what the query cannot: the ratified bar and its reason, so the read returns a verdict, not just the figure the SQL correctly fetched.
What does text-to-SQL actually solve?
It collapses the distance between a question and a query. Writing SQL is a real skill and a real bottleneck, and turning “how many trials converted last month” into correct joins and filters, instantly, is a meaningful convenience. For retrieval — getting the right number out of the warehouse — it is a fine tool and often a delightful one.
But retrieval was the part that already worked, more or less; an analyst could always fetch the number, and now you can too. What text-to-SQL speeds up is the step that was least in the way. The step that was in the way — deciding whether the fetched number is fine — it does not touch, because that step never involved a query.
Why can’t the query return the verdict?
Because the verdict needs a value that is not in the schema. Say you are an analytics engineer who can generate flawless SQL for any metric your team asks for. When a founder asks “is our activation healthy,” the query returns 44% correctly — and the word healthy has no referent in the tables. Healthy is defined by a bar someone set: 47%, the point below which the paid funnel doesn’t sustain itself. No SELECT reaches that number, because it was never stored as data.
So text-to-SQL faithfully answers a question one step short of the one that was asked. It returns 44% when what was wanted was “44%, under the 47% health line, so no.” The gap is not query quality; the SQL is perfect. The gap is that the standard lives in a decision, and a decision is not something a query language can join to.
What has to sit on top of the query?
The criteria layer — and it has to be ratified, not generated. A tempting shortcut is to have the model also invent the bar (“47% seems healthy for a SaaS funnel”), but an invented bar is the auditability problem again: a standard nobody agreed, gone by the next question. The read is only a verdict you can stand behind if the bar it cites is one your team actually ratified.
Put the two together and the division of labour is clean: text-to-SQL fetches 44% from the warehouse; the criteria layer holds the 47% line and why it is 47%; the read composes them into “44%, under your 47% health line, so no — and here is why the line is there.” The query was necessary and never sufficient. Retrieval is solved; judgement is the layer above it.
Text-to-SQL solves retrieval — turning a question into a query and returning a figure — which was rarely the barrier; the barrier is whether the figure clears a bar, and that bar is a ratified decision no query can join to, so a verdict needs the criteria layer sitting above the SQL.
Reads through Unl arrive with measured context — in the presence of the decisions you’ve already settled. The reach lane is live: one box, paste anything. If it speaks MCP, Unl can reach it. Readings arrive unprompted, the data beside the criterion; Unl is a courier, not a warehouse, and keeps only your keys and the frame.
Read further
Questions people ask
Is text-to-SQL enough to answer business questions?
It’s enough to fetch the number — it turns English into a correct query and returns the figure, which is a real convenience. It’s not enough to answer ‘is that good enough’, because acceptability isn’t a column. That question needs a ratified bar the database doesn’t hold, so the query lands one step short of the decision.
Why can’t a generated query tell me if a number is good?
Because ‘good’ is defined by a bar someone set — ‘47% activation, below which the paid funnel doesn’t sustain itself’ — and no SELECT reaches that value, because it was never stored as data. The SQL correctly returns 44%; the verdict ‘44%, under your 47% line, so no’ needs a standard that lives in a decision, not the schema.
What do you add on top of text-to-SQL?
A ratified criteria layer — not a bar the model invents, which would just be unauditable again, but the line your team actually agreed and the reason behind it. Text-to-SQL fetches the figure; the criteria layer supplies the standard; the read composes them into a verdict. The reach lane is live: one box, paste anything. If it speaks MCP, Unl can reach it. Readings arrive unprompted, the data beside the criterion; Unl is a courier, not a warehouse, and keeps only your keys and the frame.
What this is
Think inside your AI world — you stay in command
Unlimitless (Unl to friends) holds what you've settled, reads what your tools are showing, and catches what's changed out in the world — and hands your AI whatever bears on the work, the moment it's needed, without you asking. The right thing, in front of the model, unprompted, with you in command of the call. So you keep moving toward what you set out to build, on top of everything you've already decided.
It plugs into Claude, Claude Code, ChatGPT and Cursor as an MCP connector. Quick to connect, in a couple of steps.
Unlimitless is open now to invited Alpha. Apply for the Beta waitlist to come in ahead of the full launch:
Alpha is invite-only · free at launch.