AI can now do real work, yet most software still looks much as it did a decade ago. This post asks what it would take for software to act for you, safely, and argues that the answer is reasoning and intuition working together on one foundation.

I'll make the case in three parts: the paradigm (what changes when software starts doing the work), the pattern (the architecture any team must build to let it act safely), and the platform (how Aito's predictive database runs that pattern in one system, with real queries you can read).

Part 1: The paradigm

The question every product team is asking

AI has become capable enough to change the relationship between software and its user for good. Still, most applications look much like they did before, perhaps with an assistant added on the side, and as such almost every product team I talk with is asking some version of the same question: what should software built for this age actually look like?

I'd argue the answer is already clear in outline. Until now the user has been the inference engine: the software stores and presents the data, and the person reads it, judges, and types the decision back, whether that is a routing choice, a category, or an approval. People used software to do their work. Now the software is expected to do the work with them, and increasingly for them, with the person supervising rather than executing. That is a change in the very nature of the system rather than a new feature, and a large share of knowledge work, the repetitive decisions already implied by the records on screen, sits on the other side of it.

Why it stalls: capable is not the same as trustworthy

The first serious attempt at this was the agent: take a language model, give it tools, and let it act on the business by itself. It was the right first move for language, and it quickly exposed the problem. A language model is a bit like the most capable intern you have ever hired, one who writes beautifully but has no memory of what your company did last week and no sense of what a wrong move costs, and who will make a fluent, occasionally wrong decision without hesitating.

I think this explains why so much of the effort has stalled. An MIT study of enterprise AI in 2025 found that around 95% of companies' generative AI pilots were failing to deliver measurable returns. I don't believe the main reason is a lack of capability. Nobody lets a system post an invoice, approve an order, or email a customer unless they know when it is right and, more importantly, when it is not. Generation can reason, but it has no calibrated sense of its own evidence, and without that the software can only suggest, never act.

What it takes: reasoning and intuition as peers

Letting software act safely needs two abilities that have only recently become practical in the same system:

1. Reasoning, from generation. Language models give the software language and open-world judgement: reading a free-text request, inferring what the user meant, handling the exception nobody wrote a rule for, and explaining what it did.
2. Intuition, from prediction. A predictive model over the business's own data gives grounded, calibrated, and auditable decisions on the recurring work: the likely category, the right account, the probable owner, each with a probability that means what it says.

An agent that only reasons is fluent but unmoored, while one that only predicts cannot handle the open world. Put the two together and the calibrated number tells the software which case it is in, and so when it may act, when it should ask, and when it should step back.

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

This is not only a thesis. In the predictive application I described three open reference apps built on the intuition side: 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. 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 from little data lands the correct record 65% of the time against 14% for plain vector search (measured in June on the v1 engine), because relational structure carries signal that raw embeddings throw away.
• A predictive shortlist resolves in about 0.15 seconds, measured. A six-step chain of language-model calls would take about 22 seconds at their clean per-call latency, and the two pick the right answer about equally often.

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, generally available since September 2026, 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 reference. If you want to talk, email me directly: antti@aito.ai. I am the founder. Plain email works.

Back to blog list