Software has always treated the user as the inference engine. The interesting question is not whether that assumption is optional. It is what happens when the software acts on its own answer, and whether you can trust it when it does.

One of the defining trends of the last two years has been the attempt to make software autonomous. The first wave of agentic AI took a language model, gave it tools, and asked it to act on a business by itself. It was the right first move for language, and it exposed something worth asking about: an agent built out of generation alone is a strange kind of colleague.

Picture the most capable intern you have ever hired. They have read every book on earth, they write beautifully, and they will answer any question with total confidence. They also have no memory of what your company did last week, no feel for which of your customers is about to churn, and no sense of what a wrong move actually costs. Set that intern loose on your accounts payable and they will produce a fluent, well-argued, wrong decision, and they will not hesitate while doing it.

This is not a knock on language models. It is a statement about what generation is good for. Generation reasons: it reads a messy request, infers intent, and handles the case nobody wrote a rule for. What it lacks is intuition, the grounded, calibrated sense of what usually happens here, learned from the data the business already holds. An application that can act on your behalf needs both, and it needs them as peers. That claim is the whole argument, and the rest of this post is about why it is true, what architecture it forces, and how we built a system to run it.

I will make the case in three parts. First the paradigm: why intelligent software is generative and predictive together, and how much value is sitting in that combination. Second the pattern: the architecture any team must build to make an acting agent safe, and the specific pains of assembling it from the parts available today. Third the platform: how Aito's predictive database runs that pattern in one system, with real queries you can read.

Part 1: The paradigm

Intelligence is reasoning plus intuition

Every application ever shipped rests on one quiet assumption: the data lives in the software, and the decisions live in the user. The system stores and presents. The person reads, judges, and types the answer back. Every routing choice, every category, every approval, every filled field is a small act of inference a human performs, on data the system already holds.

Step back and the scale of it is hard to unsee. Hundreds of millions of professionals spend most of their working hours on decisions that are repetitive, pattern-following, and in most cases already implied by the records in front of them. It is a civilization-scale allocation of human attention to work the system could do itself, and it persisted only because there was no affordable alternative.

The shift now underway is an inversion. The endpoint is software that performs the task itself, with the person supervising rather than executing. You stop operating the application, and the application operates on your behalf.

Two abilities have only recently become practical in the same system, and both are needed for that inversion to be safe:

1. Reasoning, from generation. Large language models give an agent language and open-world judgment. It can read a free-text request, infer what the user meant, handle an exception, and explain in words what it did.
2. Intuition, from prediction. A predictive model over the business's own data gives grounded, calibrated, auditable decisions on the structured and recurring work: the likely category, the right account, the probable owner, each with a number attached.

An agent that only reasons is fluent and unmoored, confident well past its evidence. An agent that only predicts cannot handle the open world. Put the two together and the software can act, and act safely.

Reasoning handles the exception. Intuition handles the rule. The calibrated number tells the agent which case it is in.

What the value looks like when it is real

An idea like this only matters if it produces value you can measure, so it is worth starting from running systems rather than assertions.

In the predictive application I described three open reference apps built on this pattern: an ERP running fourteen use cases at about 72% automation, an accounting system that acts on calibrated probability, and an e-commerce store with sixteen views on one dataset. Those are the intuition side made concrete. They are open, and worth opening.

The agentic side is now live too. At agent.aito.ai the same intuition layer sits under real agents, and the effect it has on them is measurable rather than rhetorical:

• A support agent that shortlists the relevant tools and context before the language model runs cuts the prompt from 3,842 tokens to 237, roughly a 16-fold reduction, and it holds as the catalog grows.
• Retrieving the right customer for a query lands the correct record 65% of the time against 14% for plain vector search, because relational structure carries signal that raw embeddings throw away.
• A predictive shortlist resolves in about 0.15 seconds where a chain of sequential language-model calls takes 22, close to a 10-fold latency difference.

None of these numbers come from the language model getting better. They come from giving it intuition: a system that already knows the shape of your data and can narrow the world before the expensive, open-ended reasoning step runs. Generation is what acts and speaks. Prediction is what keeps it fast, grounded, and honest. That is the value, and it is large and general. Which raises the obvious question: if the combination is this good, why is almost no software built this way?

Part 2: The pattern

The blueprint every acting agent has to implement

Grant the paradigm and a specific architecture falls out. Any agent you would trust to act on a real business has to run some version of the same loop. A new event arrives. The intuition layer computes a calibrated probability for the decision. And the agent's behavior is gated on that number:

Call these three moves act, assist, abstain. They are not use cases, they are decision boundaries: the same decision handled differently depending on how much confidence the evidence supports, trading leverage against quality at the moment the choice is made. Where the probability is high, the software acts. Where it is middling, it assists: it drafts the answer and asks a person to confirm. Where it is low, it abstains, hands the evidence back, and lets a human decide. That gradient, driven by a number that means what it says, is what letting software act looks like when it is safe enough to ship in finance.

The loop has a fourth move that is easy to miss and does most of the long-term work. The outcome of every decision, the human's correction included, goes back into the data, so the next prediction is sharper. Act, assist, abstain, then learn, over live data, with no retraining step in the middle. It is the same loop whether a person supervises every step or only the exceptions.

That is the blueprint. The trouble starts when you try to build it.

Why building it hurts: the Frankenstein stack

The reason almost no software works this way is not that teams lack imagination. It is that the blueprint asks for capabilities that live in separate systems today, and the seams between them are where an acting agent falls apart. Underneath the surface cost sit three hard problems that have to be solved together, and are almost always solved apart.

Acting needs the known and the unknown, priced, explained, and safe to run. All of the value in an application is in the decisions it takes, because a decision is where money is earned or lost. Taking one well needs the likely outcome (the unknown), a calibrated sense of how sure that outcome is (so the agent knows whether it may act or must escalate), and a way to weigh it against the objective the action moves. Business intelligence shows you the known past in a dashboard that takes no action. A trained model gives you one prediction with a score you cannot safely threshold and no link to the objective. Neither lets you ask what happens if.

Real business data resists the clean model it is supposed to fit. The textbook model wants a flat, single-language table of features. Real business data is the opposite: many tables joined by relationships, free text in several languages, categorical codes nested in deep hierarchies, timestamps, increasingly vectors, with density that swings from millions of rows to fields seen three times. Force that into a flat matrix and you need a bespoke pipeline for every dataset, and you throw away the structure and the rare signals in the process, which are often exactly the signals a hard decision turns on. Solve this and a new capability is a new query. Fail it and every new capability is a new project.

The capabilities live in separate systems, and the seams show. This is the one an agent feels most directly. Facts sit in a transactional database, full-text search in a search engine, semantics in a vector database, relationships in a graph database, and prediction in a model server. Building one real capability means wiring four or five systems together and keeping them agreeing with each other. The result is a Frankenstein stack: search that lags the writes, results that disagree between systems, latency stacked across every hop, and a standing pile of glue whose only job is to paper over the gaps.

An acting agent makes this worse in a specific way. It composes its requests at runtime, against a schema it was not written against, so it needs one uniform, self-describing place to ask, not five services to orchestrate through glue it cannot see. And interactive action needs the opposite of the assembled stack: current data, low latency, and reads that scale across many concurrent users and agents. The seams are where an agent's freshness, latency, and budget go to die.

The three problems are one problem

The reason these are hard is that they are coupled, and the coupling is what points at the answer. Acting needs calibrated inference, so the first problem needs the second solved. Calibrated inference over real data needs structure, semantics, language, and relationships available to the same computation, so the second problem needs the third's unification. And unification is precisely what removes the friction, keeps the data fresh, and delivers the speed interactive action demands, so the third problem serves the first. Solve them in separate systems and the seams reintroduce the very problems you thought you had solved.

One system where facts, text, vectors, and relationships live together; where inference runs over all of them at query time and returns calibrated, explainable answers about the unknown alongside the known; which stays fresh, scales for interactive use, and speaks the query language everyone already knows.

That single shape is the target architecture. It is also, not by coincidence, what we have spent years building.

Part 3: The platform

One system that runs the whole blueprint

Aito is a predictive database. It holds structured facts, full text, vectors, and linked relationships in one store, and it answers queries about the unknown the same way an ordinary database answers queries about the known. The v2 engine is the predictive half of the blueprint made concrete: the calibrated, explainable, always-current substrate an agent's reasoning runs on top of. The generation stays where it belongs, in the language model above it. Rather than describe the substrate, let me build the case the way an application uses it, in four moves. It sees the whole picture, it can be trusted to act on that picture, it keeps the picture yours and current, and it pays for itself at scale. The first three are queries you can read for yourself.

First, the intelligence sees the whole business, not a flat row. Facts, text, vectors, and the relationships between records all live in one store, and a prediction can walk those relationships by name, several hops out, in the same query that makes it. The move a fraud check or an approval routing needs, looking at the neighborhood of a record to judge whether it is anomalous, is a _relate over the same data, with no separate graph database to keep in sync:

POST /api/v2/_relate
{
  "from": "invoices",
  "where": { "flagged": true },
  "relate": ["vendor", "amount_bucket"],
  "limit": 5
}

Those dotted paths you meet in a query, like context.user or product.tags, are links: relational edges the query walks by name, so a prediction leans on the vendor, the vendor's own history, and the approver of a record without leaving the store or precomputing a feature. That connected shape can be named: a view joins or stacks collections into one relation you predict against exactly like a table, without copying the data, so the whole picture is defined once and queried everywhere. And the same instance answers every kind of question over that one connected picture. Ranking against an objective, the priced part of the first hard problem, is a goal on a recommend:

POST /api/v2/_recommend
{
  "from": "impressions",
  "where": { "context.user": "veronica" },
  "recommend": "product",
  "goal": { "purchase": true },
  "limit": 3
}

In a Frankenstein stack that connected view lives in glue code strung between five systems, so the intelligence only ever sees the slice in front of it. Here the connections are first-class, and the reasoning has the whole context a good human decision would have.

Second, every decision comes calibrated, explained, and safe to threshold. A standard model server hands you a score you cannot safely act on. Aito's inference runs over the live rows at query time and returns a calibrated $p, the predicted $value, and $why it got there, in one call:

POST /api/v2/_predict
{
  "from":  "invoices",
  "where": { "vendor": "VENDOR-1676", "description": { "$match": "Packaging design" } },
  "predict": "gl_account",
  "select": ["$p", "$value", "$why"]
}

That $p is the number the act / assist / abstain gate runs on. Above your automation threshold the agent posts the entry. In the middle it drafts and routes to a person. Below it abstains, leaves the field empty, and shows $why as evidence. The decision policy from Part 2 is not machinery bolted on top, it is a threshold on a value the query already returns. And the calibration holds on real business data for a concrete reason: when several fields say the same thing, a vendor's name and its code and its bank account all pointing at one entity, the engine groups that correlated evidence instead of counting it five times, which is what keeps the probability honest rather than merely high.

Third, learning is a write, and the data stays yours and current. A model server needs a batch retraining job to absorb a correction. A predictive database behaves like a database: you write the row, and the next prediction is already smarter.

POST /api/v2/data/_modify
{ "into": "invoices",
  "insert": { "vendor": "VENDOR-1676", "description": "Packaging design",
              "gl_account": "6820", "approved_by": "maria" } }

There is no deploy step, no retraining schedule, no on-call rotation for drift. The write-back loop that closes the blueprint is one ordinary insert, and because the v2 engine ingests far faster than the one before it, that loop stays practical when a live business writes thousands of corrections a day. The intuition is grounded in your own data, and it is current by the second rather than by the last training run.

Fourth, it is built to run this cheaply at scale. The single connected view and the low operating cost are the same architectural fact seen from two sides: when facts, text, vectors, and relationships share one store, you stop paying for five systems, five memory footprints, and the glue that keeps them agreeing. The v2 engine adds a lighter memory footprint, query-time caching, and an object-store-backed cluster design meant to grow on cheap storage rather than a fleet of always-on machines. I will keep the honest numbers, and the places v2 is not yet ahead, in the release post rather than wave at them here. For the architecture the point is only this: the thing that gives an application the whole picture is the same thing that lets you afford to run it for everyone.

Predict, recommend, relate, match, estimate, evaluate, all over one store, all returning calibrated answers, all addressable over the wire in a form your team already reads, with Postgres wire compatibility so much of the tooling around it works unchanged. If you build on this, you delete the systems whose job was inference over your own data: the vector database, the graph store, the model server, and the glue that kept them agreeing. Aito does not race a dedicated search engine on raw full-text speed, and at very large search scale that specialization wins, but for most applications the gap is milliseconds no one notices and search is rarely the bottleneck anyway. What Aito replaces is the reasoning over your data, and that collapses into a query.

Where the two halves meet

Seen from the agent above it, this system is the layer that makes action safe. The language model proposes and phrases. The predictive database judges, calibrates, decides whether the confidence clears the bar, records why, and takes the outcome back to learn from. The generative half acts and speaks. The predictive half keeps it honest. Neither is sufficient alone, which is the whole reason the two belong on one foundation rather than in separate systems bolted together after the fact.

Why now, and why it is still hard

I want to be honest that this is difficult, and that the difficulty is the real reason software still makes you do the work. Holding structure and semantics and language in one store, running fast calibrated inference over it, and keeping it fresh at scale is genuine engineering, not a configuration setting.

But the enabling pieces have matured at once. Generation is cheap. Query-time calibrated inference is fast enough to be interactive. Object-store-scale systems make a single unified store practical. The value is large and general enough that the friction between four databases is no longer something to tolerate. It is the thing worth attacking.

It is worth being just as plain about where Aito is the wrong tool. If you need free-form generation, long-form writing, or open-world reasoning, that is the language model's job, not ours. Aito is deliberately the predictive half and does not generate. A predictive database also earns its confidence from repetition, so on a genuinely novel case with no history to lean on, it will tell you it does not know rather than guess. That is the honest behaviour, not a failure, and it is also not magic. And if raw full-text search at very large scale is the whole game, a dedicated engine is built for exactly that, while Aito ranks on what a user is likely to want rather than on raw throughput. For the structured, recurring decisions that sit on data you already hold, which is most of the work, this is the right tool. For the rest, reach for the one that fits.

Which returns to the intern we started with. The reason you would not hand your accounts payable to a brilliant, memoryless intern is the same reason generative-only agents stall short of real autonomy: reasoning without intuition acts confidently past its evidence, and an agent that acts on a confident wrong guess is worse than one that does nothing. Give the agent intuition it can trust, calibrated and explained and always current, and the inversion completes. You stop operating the software, and it starts doing the work.

A couple of thought experiments to end on. If any developer can get a calibrated, explained prediction from a database query, why would a team spend months productizing and integrating a rack of narrow models? And if the intuition an agent needs is one query away, on the same data it already trusts, why would anyone keep building autonomous software out of reasoning alone?

The pieces are here. What is left is to stop assembling them at the seams.

---

Aito.ai is a predictive database: calibrated, explainable inference over text, vectors, and linked relational data in one store, with Postgres wire compatibility and an object-store-backed cluster design. The v2 engine, now in public beta, is the predictive substrate an agent's reasoning runs on: _predict with a calibrated probability and its factor tree, plus recommendation, relations, and vector and text search, all over one store. See the live agents at agent.aito.ai, the three open reference apps in the predictive application, and the v2 API in public beta. If you want to talk, email me directly: antti@aito.ai. I am the founder. Plain email works.

Back to blog list