🔴 DRAFT for week 40, RESTRUCTURE for review. Staged as the solution to the intelligent-application problem; the release-process material is kept but moved to "Why you can build on it". Every number and commitment is unchanged from the reviewed version on PR #336.

[REMAINING before publishing: final cover choice and the company-ai vector/graph screenshots (website lane). Antti and CRO to review the restructure.]

Software is now expected to be intelligent: to predict, recommend and decide, not only to store and show. Aito v2, generally available today, makes our predictive database the intelligent core of an application, and our own applications run on it.

Software is becoming intelligent

AI is changing software, and fast. In two years language models went from research demos to a line on nearly every product roadmap, and the question product teams ask has changed with it: not whether to add AI, but how. Because language models have become a commodity that can read, write and act through tools, intelligence is turning from a special project into something every application is expected to have.

What intelligent software still needs

The transformation is still ongoing, and given how fast it moves it's worth asking: what does it take to make an application holistically intelligent? So far the answer has been generative: an assistant, a chat panel, an agent with tools. Language models brought reasoning and language into software, and they are good at both.

Yet, with more in-depth examination, this transformation is far from complete. For software to be intelligent throughout, and not only in its chat panel, three problems remain:

1. Cost. Intelligence is not yet close to free, and it has to be before it can sit behind every field, list and decision. Language models run on GPUs, and they are generic rather than fitted to the application's own data, so every call pays for both. A prediction should cost milliseconds of commodity CPU time, not seconds of GPU time, and integrating one should cost about as much as writing an SQL query.
2. Calibrated grounding. Software that acts on a user's behalf needs answers grounded in its own data, with a confidence that means what it says: which account an invoice belongs to, which customer is about to churn, and how sure the software can be about each. Without that, the software can suggest but cannot safely act.
3. Versatility. Intelligence in an application takes many forms: predictions, matching, recommendations, full-text and smart search, and pattern discovery, each of which usually lives in a separate system today. On top of that, the core has to fit the ecosystem around it (SQL and the tools that speak it), serve language models and agents (vectors and relationships), and scale with the data (clustering).

Solve these, and software can be intelligent through and through, with every action and every interaction supported by prediction, whether the one acting is a person or an agent. The platform underneath such software is a predictive core that:

• answers predictions, recommendations, matching, search and pattern discovery over the application's own data, as queries;
• returns a calibrated confidence and the evidence with every answer;
• is cheap enough to sit behind every interaction, with no training step;
• speaks SQL to the existing ecosystem, and vectors and relationships to agents;
• scales out as the data grows.

If your product already has a chat assistant, none of this replaces it. The assistant is the generative half. What most products are missing is the other half: the one that fills fields, ranks options and makes decisions inside the screens your users already work in, with a confidence that tells the software when it may act on its own.

In short, the intelligent core of an application, and the predictive envelope around your generative model. That was the design goal of Aito v2. We hope you like it, and we feel we have delivered it, with one honest exception: scaling out across a cluster exists as a working proof of concept rather than a product. The work done shows it can be done, and we can deliver it on request, typically within weeks to a month. (The longer argument is in The Predictive Application and What would it take for software to act for you?.)

What v2 is: the predictive database as the intelligent core

Aito is a predictive database, and v2 makes it the intelligent core of an application. It stores facts, text, vectors and linked relationships in one place, and it does more than retrieve them: it infers from them. It answers questions about the unknown the way an ordinary database answers questions about the known: as a query, returning a calibrated probability, a predicted value and the evidence behind it, with no model training step anywhere.

v2 rebuilt that on a new architecture: one query planner doing calibrated inference with correlated-feature grouping, over a unified store of facts, text, vectors and relationships, on a memory-optimised columnar core backed by object storage.

A core is only useful if it connects to the rest of the application, and v2 is designed to connect in two directions.

Into the systems you already run. v2 speaks SQL over the Postgres wire protocol, so predict() sits inside a SELECT and there is no CREATE MODEL step, because there is no model to create. Your existing Postgres tools connect to it unchanged:

SELECT value, p FROM predict('analysis', 'churned',
  where => 'cooling = ''passive'' AND climate = ''hot''');

Into your LLMs and agents. Vectors, full text and relationships sit in the same store as the facts, so the intuition an agent calls on covers meaning and structure, not only columns. Nearest neighbours over stored vectors, with the similarity as a column you can filter and select:

{ "from": "products",
  "where": { "$nearest": {
    "near":   { "embedding": [0.12, -0.03, 0.88] },
    "where":  { "category": "shoes" },
    "having": { "$similarity": { "$gte": 0.8 } },
    "limit":  10 } },
  "select": ["id", "name", "$similarity"] }

And a relationship read backwards, from the entity an edge points at, used directly as evidence for a prediction:

{ "from": "users",
  "where": { "$refs.orders.buyer.product": { "$has": "gold" } },
  "predict": "segment" }

The graph side comes with an asterisk. v2 treats relationships as links you can follow forward as deep as your schema goes, read backwards, and use as evidence, including predicting a missing edge or classifying a node from its neighbours. It is not a graph database: searching for paths of unknown length, such as reachability or shortest paths, and graph algorithms are not there yet.

The operations themselves, _predict, _recommend, _relate, _match and _search, are small enough to hand to an agent as tools, and each answer comes back with the probability and the evidence that tell the agent whether to act, ask, or step back.

The receipts

Claims like these are cheap, so here is what they look like when measured.

Under real agents. At agent.aito.ai the same predictive core sits under live agents. A support agent that shortlists the relevant tools before the language model runs cuts the prompt from 3,842 tokens to 237. Finding the right customer's history for a support ticket, plain vector search picks the wrong customer 86% of the time on little data, and is still wrong about 47% of the time at scale, because symptom text matches across customers. Conditioning on structure recovers the right one about 65% of the time from the same little data, because relational structure carries signal that raw embeddings throw away. And where a six-step resolution chain of language-model calls, at about 3.6 seconds a call, comes to roughly 22 seconds, the predictive shortlist resolves in about 0.15 seconds (the measured median over 800 tickets), and the two pick the right answer about equally often.

Against a tuned AutoML pipeline. On invoice routing, scored on a 2,000-row hold-out against FLAML: predicting the invoice acceptor, v2 reaches 61.3% where FLAML reaches 56.2%, and v2's 95% interval, about two points either side on a single 2,000-row run, stays clear of FLAML's figure. FLAML trained for 418 seconds to get there. Nor was it a blind baseline: the tree models (Random Forest, LightGBM and FLAML) receive the linked employee and GL-code columns as input features, so they see the same evidence Aito's queries name. The acceptor is the interesting one, because the answer is not on the invoice at all. It lives in another table and has to be reached across a link, which is the shape ordinary tabular models handle badly and the shape a predictive database exists for. Aito reached it with no training step, no model artifact and no feature engineering. The other two routing targets lead by smaller margins: GL code across 32 classes is 68.7% against FLAML's 65.7%, and the high-cardinality processor target is 23.8% against 19.4%. v2's interval excludes FLAML's figure on both, narrowly on the GL code.

Matching and search. Two more of the jobs an intelligent application needs, both measured on generated datasets with a known answer key. Ranking the products a shopper was shown, recommend with the products' attributes as evidence reaches an nDCG@10 of 0.534 against 0.468 for BM25 given the same purchase history, a paired difference of +0.066 (95% interval +0.041 to +0.092) that wins 106 searches to 53, mostly on wordings the catalogue does not contain. Matching an invoice line to its catalogue SKU across a link, one _predict query with no training finds the right product 83.6% of the time against 64.4% for a lexical index over the catalogue, which is what most matching systems ship. A lexical index can be brought roughly level by also indexing every past billing wording against its SKU, but that is a pipeline someone has to build, maintain and rebuild as the catalogue and the history change. In Aito the history is simply the database, and the match is a query.

Against its own predecessor. On a 10 million row linked-invoice database, v2 stores the same data in 3,258 MB against v1's 7,617 MB, 2.3 times smaller, which is one measurement at one scale on one development machine, as the footprint page says. On flat expense categorisation v1 and v2 are level, 80.0% against 79.8%, both ahead of LightGBM's 76.1%, and v2 is better calibrated there, with an ECE of 0.046 against v1's 0.058.

The benchmark pages generate every one of these numbers from the committed results, so they cannot drift from what was measured. The full table carries the limits attached to each.

Where it fits, and where it does not

Elastic finds, MongoDB stores and Neo4j connects: each is defined by a shape of data and a way of retrieving it. Aito is defined by what it does with the data. It infers, and it was built from the ground up around inference, not with inference added to a store designed for something else: search, text, vectors and relationships are inputs to one calculation in one query, and every answer carries its calibrated probability and its evidence. It is not a lakehouse, a Spark cluster or a replacement for your search engine, and it is honest about the jobs other systems do better:

The job	What is built for it	Aito v2
Predicting a value that lives across a link (the invoice acceptor)	Tuned AutoML (FLAML), given the joined features: 56.2%	61.3%, no training step	✅ wins
Ranking products by what a shopper will buy	BM25 plus the purchase history: 0.468 nDCG@10	0.534	✅ wins
Matching invoice lines to a catalogue	A lexical index over the catalogue: 64.4%	83.6%, one query	✅ wins; an index over past billing wordings gets level, but it is a pipeline to maintain
Expense categorisation	Aito v1: 79.8% · LightGBM: 76.1%	80.0%, better calibrated	⚖️ ties v1
Intent classification with abundant labels (Banking77)	Fine-tuned transformers: low 90s	82.6%	❌ loses
Raw full-text search speed	Elasticsearch: 4 to 5 ms	6 to 8 ms	❌ loses
Brand-name text search	Plain text search	behind	❌ loses
Predictions on link targets at 10M rows	Aito v1	slower than v1	❌ loses

The v1 latency comparison is stated as a direction rather than a number, because the published latency figures were not measured in the production configuration. The general rule has not changed with v2: Aito wins where data is sparse, relational and moving, and loses where it is abundant, flat and static. Most of the business decisions we see are the former.

Why you can build on it

When we put v2 into public beta in August, we set one threshold for calling it done, and it was deliberately not a date: the beta ends when our own reference applications run on it. The accounting demo, the ERP demo, the e-commerce store and the agent demo are all served by the v2 engine now, so v2 is generally available.

That bar mattered because of what it caught. Most of what changed between the beta and here were defects that produced a confident wrong answer without saying anything was wrong. That is the lesson of this release for anyone putting AI into production: the dangerous failures are the silent ones. A few examples, each now fixed:

• The absence of a value stopped counting as evidence. On a 38,000-row demo predicting a customer segment from one nullable column, v2 scored 0.475, its base rate, where v1 scored 0.745. The model was not reading the column at all, and it reported no error. Both engines now agree at 0.745.
• An unknown field inside $and, $or or $not matched everything, so a filter meant to narrow a population silently returned the whole of it.
• A deleted row still counted towards predictions until the next optimize, so Aito could recommend a product you had deleted, and do so confidently.
• _evaluate scored against a population that still contained the answers, which is why the evaluation numbers we published during the beta were worth less than they looked.

The full list, and the two behaviour changes worth knowing about, are in the changelog: a bare value on a Text column now filters by the exact value, matching v1, and invalid $has input is now rejected instead of silently answered.

What generally available commits to:

v2 is the canonical API. /docs/api/ now describes v2, and documentation for each release from v2.10.0 onwards stays available at /docs/api/<version>/, so a pinned deployment can keep reading the docs for the build it runs. GET /version reports that build.

v1 stays supported, with no end date. Its reference moved to /docs/api/v1/. We will migrate v1 storage to the v2 engine automatically over the coming months, and v1 queries and batch writes keep working over migrated storage. Existing customers do not have to change anything on their end.

Behaviour changes are announced, not discovered. Every release has a plain-language entry in the changelog, and anything that changes the answer to an existing query is listed under "Changed", with what to send instead. Where a release starts rejecting input that was never valid, as 2.10.0 does with a multi-word $has, that is listed too.

Support is founder-led, by email, and a production licence key arrives within a working day. Aito also runs self-hosted in Docker, and the source of every reference application is public on GitHub.

Taking it into use

If you want to try this on your own problem, this is roughly what it looks like:

1. Try it with nothing to set up. The quickstart runs against a public sandbox with no signup, and sql.aito.ai shows predict() over the Postgres wire protocol.
2. Load your own data. A table or two of your history is a start, and there is no model to train before the first query. The SQL guide covers loading over the Postgres wire protocol.
3. Choose where it runs. Hosted, or self-hosted in Docker; pricing covers both.
4. Check the operational side. Security, reliability, architecture and limits are documented.

The reference applications are the best argument for all of the above. They are open, and they run on the engine this post is about:

• sql.aito.ai: predict() inside a SELECT, over the Postgres wire protocol.
• agent.aito.ai: agents calling Aito operations as tools.
• accounting.aito.ai: multi-tenant predictive accounting, the invoice coding and approver routing benchmarked above.
• erp.aito.ai: predictive ERP across three industry profiles.
• ecommerce.aito.ai: the PetNord store, predictive e-commerce with recommendations, search, demand and pricing on one dataset.
• demo.aito.ai: the grocery store, the original e-commerce reference.
• Company AI: a small company's sales assistant, with the knowledge graph and cross-lingual search shown above. You run it yourself, on its invented demo data.

Two older demos, the Hacker News browser and the equity screener, still run on v1 and are not part of this set yet.

If you want to talk about whether this fits something you are building, email me directly: antti@aito.ai. I am the founder. Plain email works.

Back to blog list