Skip to main content

AI agents in the enterprise

A human reading a wrong number usually catches it. An agent acts on it.

That single difference is why the data question changed when agents arrived. When a person consumes an answer, bad data produces a bad report that somebody eventually queries. When an agent consumes it, bad data produces a bad action — a wrong quote, a wrong credit decision, a wrong thing said to a customer, at machine speed and without a pause for someone to think "that looks off".

Tolerance for a wrong answer goes to zero, and the properties of your data foundation stop being a matter of hygiene and become the gating condition on what you are willing to let an agent do.

Why enterprise agents are stuck on low-value work​

Most enterprise agents today summarise, draft and retrieve. Very few quote a price, confirm availability, tell a customer their balance or trigger a decision that costs money.

That is not a limitation of the models. It is that nobody will sign off on an agent acting from data nobody can vouch for. The blocker is not capability — it is warranty.

Which means the useful question is not "can an agent do this?" but "what would have to be true about our data before we would let it?"

Four things that have to be true​

Each of these is a way an agent fails in production, and each has a structural answer in CryspIQ® rather than a procedural one.

It must not act on wrong data​

Records that fail data quality checks are rejected at entry and returned to the source system to be corrected. They do not enter CryspIQ® and are not stored pending review. An agent reading the fact tables is reading records that passed, because nothing else was admitted.

This is a different guarantee from cleaning data downstream. Downstream cleaning means the bad records are present and something is expected to filter them; a filter that is forgotten, or applied by one consumer and not another, produces exactly the inconsistency it was meant to prevent.

It must know when the picture is incomplete​

Facts that arrive before their business master data exists are held in the parking lot until the master data appears — valid records, waiting for something to attach to. They are not lost and they are not counted yet.

That matters more for an agent than for a person. A correct calculation over an incomplete set is not the right answer; it is a right sum over the wrong denominator. Because the platform knows what is pending, an answer can say what it covers — which is a stronger statement than a bare number, and one a data lake cannot make, because there a pending record and a bad record are both just rows.

It must not mistake one customer for three​

Dimensions are keyed on a business key, so there is one row per real-world party however many source systems supplied it. An agent counting customers gets a count, not an estimate, and does not have to attempt name matching to get there.

Fuzzy matching is where agents quietly go wrong. It usually works, which is worse than never working, because the failures are invisible until somebody notices the same customer contacted twice.

It must not disclose what it should not​

Security classification is carried on the fact type — on the data itself, alongside the business definition — rather than applied by whichever tool happens to be reading. An agent inherits the classification wherever it reads from, instead of depending on a permission model configured per consumer and re-implemented for each new one.

Two properties specific to agents​

A hallucinated field cannot reach the database. Lumen does not write SQL. It emits a plan of identifiers that must already exist in the schema, and a deterministic engine generates the query from it. An invented column fails validation rather than returning a plausible, wrong result.

The schema does not grow as you connect more systems. CryspIQ® holds the same structure whether three sources are mapped or three hundred, so the context an agent reasons over stays constant. On a source-shaped estate it grows with every system connected — and past roughly twenty sources the full schema no longer fits in a model's context window at all, which removes the fallback when retrieval picks the wrong tables.

What this does and does not claim​

It does not claim a revenue number. Anyone who offers you one for AI agents is guessing.

The claim is narrower and testable: the constraint on agent deployment is data warranty rather than model capability, and warranty is an architectural property. An organisation that can state what its data covers, what it excludes, who a party is and who may see it can trust an agent with work that touches customers and money. An organisation that cannot will keep its agents on internal summarisation, where being wrong is cheap.

That is where the commercial value sits — not in the agent being cleverer, but in the set of processes you are willing to point it at.