Industries / Commerce & growth
Your growth agent is right most of the time. That is exactly why it's dangerous.
For CTOs and VPs of engineering and product building autonomous budget, pricing and lifecycle agents on commerce and marketing data — where the failure mode isn't the agent being wrong, it's nobody finding out until the spend already happened.
The postmortem
The agent cut spend on the adset that was actually working, because it attributed a seasonal dip to creative fatigue. It sounded completely reasonable. It wrote a clean paragraph. It moved ₹40,000 a day for five days before anyone looked.
Your engineers ask the obvious question: how do we stop this happening again? With a general-purpose LLM the honest answer is that you can't, structurally — you can only add more prompt engineering on top of a component whose job was never to compute anything correctly.
Meanwhile every customer contract you sign says “AI-powered decisions” and every legal review asks what happens when the AI is wrong. You don't have a good answer. You have a good demo.
What it cost
Five days of confidently wrong spend, and nothing in the logs looked wrong.
Day 12
The agent attributes a seasonal dip to creative fatigue and cuts the adset that was working.
Day 12–17
₹40,000 a day moves. No error, no alert — a plausible paragraph and a wrong action.
Day 17
A human notices. The recovery is slower than the cut, because the cohort has to be rebuilt.
Why this is an engineering problem
You cannot prompt your way out of a component that was never designed to compute.
Silent
A misattributed root cause doesn't throw an error. It ships a plausible sentence and a wrong action, and both look identical to the correct case in your logs.
Recurring
Every new decision type is another prompt to tune, another eval set to maintain, another way for the same failure to resurface under different wording.
Unscoped
Without an explicit autonomy envelope, “the agent can act” means all decisions or none. Most teams land on none, and ship a chatbot instead of an agent.
The instinct is to fix this with a better model or a longer system prompt. Both treat a systems-design problem as a model-quality problem. Stop asking the model to compute, and it stops being able to compute wrong.
What you get to build on
An engine you integrate, not a prompt you maintain.
The model stops computing
“How do we stop the confident wrong answer?”
Root cause and attribution come from a deterministic rule tree and a fitted causal model. The LLM receives the verified output and writes a sentence about it — and is rejected if it introduces a number or a cause that wasn't in the payload.
An explicit, auditable envelope
“How do we scope autonomy per decision type?”
You define which decision types can execute unsupervised from day one — typically none. As measured outcomes accumulate per type, the envelope widens. You ship a chatbot on day one and an agent within a quarter, provably.
It escalates, then it refuses
“What happens when it's uncertain?”
A rule miss escalates to the causal model. A causal miss escalates to a constrained hypothesis generator forbidden from naming a cause. If nothing clears the bar, the system returns “insufficient context” — a defined, testable state.
Deterministic where it can be
“How do we test this like software?”
Tier 1 is a traversal in configuration — you can unit test it. Tier 2's stopping criteria are numeric thresholds you can assert on. Only Tier 3 touches a language model, and its output is schema-constrained and guard-checked.
A confidence label on every output
“What do we tell the customer contract?”
Confirmed, high, medium, or hypothesis. That label is the answer to “what happens when the AI is wrong”: the system already told you how much to trust it before you acted.
A graph and a gate set, not a fork
“How much do we rebuild per client?”
The causal graph, the traversals and the hard gates are configuration. Onboarding a new customer or decision type is an edit to a table, reviewed by the domain expert who knows the failure pattern.
Proof, not a spec
This is running production budget decisions today.
Niti AI runs its entire budget-allocation and creative-fatigue product on this engine. Every recommendation — cut this adset, raise this bid, retire this creative — passes the same three tiers and the same guard before it reaches an approval queue.
Decisions are scored, not just generated.
Every recommendation's estimated impact is checked against the measured outcome at T+7/14/30, and that accuracy is tracked per decision type.
Confounders are a maintained log, not a hope.
Sale events, platform algorithm changes and other known distortions are declared, so the confounder check has something concrete to check against.
A miss is kept, not hidden.
The decision history includes recommendations that underdelivered — that record is what recalibrates the next one.
Known fatigue pattern, matches traversal
Tier 1 only
Confirmed
Novel throughput anomaly, no rule match
Tier 1 → Tier 2
High
Anomaly overlaps an undeclared platform change
Tier 1 → 2 → 3
Refused
Row three is a real state your agent needs to handle gracefully — and with this architecture it's a state your system produces on purpose, not a failure mode you discover in production.
Integration
Sits under your product, not instead of it.
You keep your product surface, your users, your brand. Hetu is the layer that decides what your agent is allowed to say it knows.
Design partners
Bring the decision your agent currently guesses at.
We help you encode the traversal your best analyst already runs in their head, wire up the causal graph, and watch the engine refuse for the first time — usually the point a team stops worrying about the demo and starts trusting the system.