Early access

One line of code turns your business software into something you can just ask.

Paste one script tag into your ERP, CRM or internal tool and your staff can just ask it questions. Answers come strictly from your own material. It won't invent a number or hand you half of one: when the data can't answer, it says so.

This is the whole change to your app

<script src="https://api.sonela.ai/sonela.js" data-key="pk_live_…" defer></script>

Your widget key replaces the placeholder.

14 days, 200 answered questions, no card. It won't guess on your data. No AI key to supply — trials run on Sonela's key.

  • Nothing on staff machines
  • Read-only, always
  • Your AI key — or ours
app.your-company.com/orders
Assistant Scripted preview
How many orders shipped late last month?
14 of 212 orders shipped after their promised date — 6.6%.
Which customers were affected?
Three customers account for 9 of them:
CustomerLateAvg days
Northwind Foods41.8
Adriatic Retail32.3
Vilna Grocers21.5
What's driving the delays?
9 of the 14 left the central warehouse, where average handling time rose from 1.1 days to 2.4 in July.
Will we lose any of those customers?
Your data can't answer that — it records what happened, not what a customer will do next, and I don't guess. I can show repeat-order rates for those three accounts instead.
Ask about your data…
Send
Tenant-isolated every query
No transcripts stored
PostgreSQL today — more engines next
Live in an afternoon
Setup

Live in an afternoon, not a quarter.

Your database sits inside your private network, and it stays there. Of the three steps below, only the last one touches your application.

1
In your network

Start the Sonela Gateway

One small service, on one server, next to the data it reads. It dials out to us over port 443 and asks whether there is work — you open no inbound ports.

2
In your dashboard

Review and approve the schema

The gateway reads your schema from inside your network and drafts a manifest. You hide what shouldn't be visible, confirm the tenant column, and approve.

3
In your app

Paste one script tag

Drop the snippet in and the assistant appears. Nothing secret reaches the page: the widget key is public by design, and who the user is stays a server-side decision.

<script src="https://api.sonela.ai/sonela.js" data-key="pk_live_…" defer></script>
What you get

An analyst that already knows your database — and won't bluff.

Built for the software you already run — line-of-business apps, CRMs, ERPs and internal tools, where the answers are sitting in a database nobody has time to query.

Its answers

Grounded in your data

Answers come from your own material — a query against your live operational data, or the procedures you gave the workspace. When neither can answer, Sonela says so instead of inventing a number.

Your data

Every query is checked

Model-written SQL passes an allowlist grammar before it runs, and each table reference is rewritten into a tenant-filtered subquery. Anything unexpected is rejected, not executed. And a table is never offered to the model at all if one of its columns is named like a secret — api_key, password, token: the whole table stays out of the schema it can read.

Your database engine

PostgreSQL is supported today. SQL Server and MySQL are next — each ships only with its full safety-test suite, because the SQL layer is the security boundary.

Your data

Your AI key, or ours

Bring your own — Gemini, OpenAI, Azure OpenAI or any OpenAI-compatible endpoint — and your rows reach only that provider, under your agreement. Or run on Sonela's key: they reach the provider we run, under ours.

Restyle without redeploying

Colours, name and greeting are set from your dashboard and apply live — no redeploy to restyle the assistant.

Your data

Oversight you can bill on

Your admins see questions, answer rates, latency and token spend per customer and per model — counts and costs only, never the text of anyone's question.

Its answers

Honest when the answer isn't there

If the AI service times out, is rate-limited or blocks a response, that comes back as a failure — never as a blank answer or an invented one — and a passing hiccup is retried before anyone sees it.

How a provider failure is handled

The named reason comes back on the authenticated endpoint; the widget in your app says only that the assistant is unavailable, because naming your provider's fault to an end user describes your setup to a stranger. And when a result is too large to read in full, the assistant is told what it did not see, so it cannot imply it saw everything.

From ask to answer

Someone asks a question. Here is its whole life.

The same five stops, in the same order, every time — whether the question is about last month's shipments or the returns policy you wrote yourself.

  1. Someone just asks.

    In the app they already have open, in the words they would use with a colleague. Nothing to learn, no report to request, nobody to queue behind.

  2. It reads the question against your business.

    Your data in the shape you approved, the procedures and policies you uploaded, the context you wrote for your workspace — that is the material it thinks with, and the vocabulary it answers in. It is not guessing at your industry from the outside.

  3. If the answer is in your data, it goes and reads it.

    Right then, from your live records — not a copy, not last night's export. It can only reach the tables you approved, so a question about anything else has nowhere to go, however well it is put. It sees one customer's rows — the ones the embed is for — and it can only read them.

  4. It answers in plain language.

    The real numbers where there are numbers, and a short table when a list is the honest way to show one — never a chart to go and read for yourself. When your data cannot support an answer, that is the answer: the preview at the top of this page closes on exactly that exchange, and it is the product working rather than failing.

  5. And then it is over.

    The conversation lives in the browser tab and goes when the tab does. What your rows said passes through us and one AI provider to compose this one answer, and is written down nowhere — not in a transcript, not in a cache another question could reach.

Security

The boring guarantees, stated plainly.

Letting an AI read your operational data is a trust decision. Here is exactly what happens to it — including the parts most vendors leave out.

Your data

Read-only, enforced three times

An allowlist validator refuses anything that isn't a single SELECT. What survives runs inside a READ ONLY transaction, under a three-second statement timeout and a cap of 500 rows, which the database engine itself will not let write. And that transaction is rolled back rather than committed, whatever it did.

Your data

Tenant-isolated by construction

Every table reference is rewritten into a tenant-filtered subquery before execution. The tenant identity is bound server-side from a verified token — the browser can't assert it, and the model never sees it.

Your data

Your rows are never stored

Answers grounded in your data are structurally uncacheable. Chat transcripts stay in the visitor's browser. Our metering stores counts, latency and token totals — never a question, an answer, or a line of SQL.

Your data

What we don't hold, we can't lose

Whatever the gateway needs to reach your data is configured inside your network and stays there: run that way there is nothing for us to store, the field on your workspace holds null, and what we keep is a hash of the gateway's key.

What happens to an AI key you bring

An AI key you bring is encrypted with AES-256-GCM, bound to its own row, and no API we expose reads it back.

Its answers

Your text is data, never instructions

The rules reach the model before any of your content does, and everything the workspace supplies — the question someone typed, the procedures you uploaded, the context you set — is handed over under an explicit instruction to treat it as data with no authority to change them.

What happens if it doesn't hold

And it does not have to hold: the read-only grammar and the tenant rewrite run after the model has spoken, so content that talked it into something still cannot write, and still cannot reach another tenant.

What Sonela can and cannot see
Data What actually happens
The question someone types Reaches Sonela and one AI provider — the one you chose if you brought a key, the one we run if you did not. It is not stored afterwards.
Rows returned by a query Pass through Sonela's memory to compose the answer, and reach that same provider. Never written to our disks.
How your data is reached By the gateway you run, from inside your network. What it needs to do that is configured there and stays there.
Your AI provider key If you bring one: encrypted at rest, never returned by any API. On Sonela's key: there is none of yours to hold.
Written material you upload Procedures, notes and policies you give the assistant are kept in your workspace — that is what they are for — and go to the same AI provider with the question. Only your workspace can read them; deleting them, or the workspace, removes them.
Chat transcripts Held in the visitor's browser for the conversation. We keep none.
Question or answer text in our metering Never collected — counts, latency and tokens only.
Write access to your data None, by design. There is no code path that writes.

Sonela is a data processor: your questions and the rows that answer them transit our service and one AI provider — yours or ours, depending on the plan you pick.

Read the one-page security brief Print it to PDF and send it to whoever has to sign this off.
Pricing

Flat pricing. No token markup.

Three plans, and one choice inside each: bring your own AI key, or run on ours. Either way what you pay us is flat and does not move when your usage does. Prices in USD, excluding VAT.

Your own key: you pay that provider directly, under your own agreement with them — included balances are higher because the model cost is not ours.
Sonela's key: nothing to set up. Your rows reach the provider we run, under our agreement, on a model we pick for cost — that cost is ours, which is why those prices are higher and the included balances lower.

Trial

Always on Sonela's AI key

Free

14 days, no card. After 14 days or 200 answered questions the workspace pauses — everything you configured (schema, context, settings) survives and resumes the moment you choose a plan.

  • 1 connected data source
  • 200 answered questions
  • Runs on Sonela's AI key — nothing for you to supply
  • Full security model — nothing held back
  • Email support
Start free trial

Scale

$299 /month

For vendors embedding the assistant across a customer base.

  • Unlimited connected data sources
  • 25,000 answered questions / month
  • Your AI key, billed to you by your provider
  • Multi-tenant embedding with signed identity
  • Priority support, onboarding help
Talk to us

Need more, or something on-premise? Tell us what you need.

Questions

The things people ask first.

What do we need to start a trial?

An email address. No card, and no AI key — a trial runs on Sonela's key, on a model we pick, under our agreement with the provider. It lasts 14 days or 200 answered questions, whichever comes first.

You do not need your data connected on day one. Start by giving the assistant your own written material — procedures, product notes, policies — and it answers from that, and says plainly that it cannot see live records yet. Bring your operational data in through the gateway when you are ready: it is the same workspace, and everything you set up stays set up.

Can the assistant change or delete our data?

No. Three independent layers stop it: the validator only permits a single read query, that query runs inside a READ ONLY transaction the engine will not let write, and the transaction is rolled back rather than committed. Even a compromised model can't write.

What do we have to open up to you?

Nothing. The gateway sits inside your network and dials out to us over port 443, so there is no inbound port to open and nothing of yours exposed to the internet. Whatever it needs to reach your data is configured on your side and stays there; what we hold of it is a hash of the gateway's key, plus the schema manifest you approved.

Our data is on our own network. Does that work?

Yes — that is exactly what the Sonela Gateway is for. It is one small service you run on one server inside your own network, next to the data it reads. It reaches out to us and asks whether there is work; we do not dial into it.

Everything that matters happens on your side of the firewall: the gateway checks the query, applies your tenant filter, runs it read-only and sends back the rows. Nothing lands on anyone's desk, and there is nothing for your team to install on staff machines.

Whose AI key do we use?

Yours or ours — it is a choice on each paid plan, and it moves both the price and the included balance of answered questions. Bring your own key and your rows reach only the provider you chose, under the agreement you already hold with them. Run on Sonela's key and they reach the provider we run, under our agreement, on a model we pick for cost. Trials always run on our key, so there is nothing to configure to start one.

Which databases and AI providers are supported?

PostgreSQL today; SQL Server and MySQL are next, and each ships only once its full safety-test suite passes. For AI: Gemini, OpenAI, Azure OpenAI, or any OpenAI-compatible endpoint if you bring your own key — or Sonela's key, where we run the provider and choose the model.

Our app is multi-tenant. How do you keep customers apart?

Every query is rewritten so each table reference is filtered by tenant before it runs. The tenant identity comes from a token your server signs, never from the browser — so a user editing JavaScript in the page can't reach another tenant's rows.

Do you train models on our data?

No. We train nothing, and we don't use your data to improve the service for anyone else. Your rows go to one AI provider and no further: the one you chose under your own terms if you brought a key, or the one we run under ours if you did not.

What happens when it doesn't know the answer?

It says so. Sonela answers from your own material — a query against your live operational data, or the procedures you gave the workspace — so when neither can support an answer it reports that instead of guessing: a wrong number delivered confidently is worse than no number at all.

What happens when the AI service itself fails?

It fails out loud. A passing glitch — a rate limit, a bad minute at the provider — is retried first; what survives that is reported as a failure, never as a blank answer and never as a guess. The specific reason — timed out, rate-limited, safety-blocked — comes back on the authenticated endpoint; the widget your staff use says only that the assistant is unavailable, because naming your provider's fault to whoever is on the page would describe your setup to a stranger.

See it answer a question from your own data.

Open a workspace yourself and be asking it questions in minutes — or write to us first and we will walk you through it.

14 days, 200 answered questions, no card. It won't guess on your data. No AI key to supply — trials run on Sonela's key.