Product
Why AI agents need deterministic rules to call
AI agents are good at understanding requests. They should not be deciding your credit limits. Why agents need explainable, deterministic rules to call.
The Condexa team · · 6 min read
AI agents are arriving in business software fast. They read emails, draft replies, fill in forms and move work along. For a lot of tasks, that is a real step forward.
But there is a class of task where you do not want an agent to be creative: the decisions your business must make the same way every time. Can this customer have credit? Who must approve this order? Is this claim eligible? For those, an agent needs something firm to call.
The problem with letting a model decide
Large language models are probabilistic. Ask the same question twice and you may get two slightly different answers. That is fine for drafting an email. It is not fine for:
- Applying an approval limit
- Deciding whether a customer is on credit hold
- Checking a country against a restricted list
- Working out which discount band applies
These decisions have a right answer, defined by your policy. They need to be deterministic: the same inputs always give the same output.
They also need to be explainable. When a customer, a regulator or your own auditor asks why a decision was made, "the model thought so" is not an answer.
What goes wrong in practice
Teams that put policy inside a prompt tend to meet the same issues:
- Drift. The prompt says "orders over 10,000 need finance approval", but the model occasionally rounds, misreads or ignores it.
- Hidden policy. The rules live in a prompt only the AI team can see. Finance cannot review or change them.
- No history. There is no reliable record of which rule was applied, with which values.
- Copies everywhere. The same policy ends up in the prompt, the ERP and a spreadsheet, and they disagree.
A better split: agents understand, rules decide
The pattern that works is simple:
- The agent handles the messy, human part. It reads the email, works out what is being asked and gathers the facts.
- The agent calls a decision service with those facts, as structured data.
- The decision service applies your policy and returns the answer, with the reason.
- The agent acts on the answer and explains it to the person in plain language.
The agent is still useful. It just is not the one setting policy.
What a good decision service looks like for agents
If an agent is going to call your rules, those rules need a few properties.
Callable over a simple API
The agent sends inputs and gets outputs back as JSON. No screen scraping, no guessing.
Fast
Agents often chain several calls. A decision that answers in milliseconds keeps the whole interaction quick.
Owned by the business
The people who own the policy should be able to read and change it without going through the AI team or a developer.
Versioned
You need to know which version of a rule was live when a decision was made, and to be able to roll forward or back safely.
Recorded
Every call should be kept with its inputs, outputs and a trace of how the answer was reached. That is your audit trail, whether the caller was a person, a system or an agent.
How Condexa fits
Condexa was built for systems to call, and an agent is simply another system. Each decision is a visual workflow the policy owner can read, with limits and lists held in lookup tables they maintain. You test it with real examples and read the trace before publishing.
An agent calls the Active version over the REST API using an API key issued to a named application, so you always know which caller asked. The answer comes back as JSON in milliseconds. Every call is recorded in run history with its inputs, outputs and trace, so if an agent's action is ever questioned, you can show exactly what it was told and why.
Because the rule is deterministic, the same facts always produce the same answer, whichever agent, app or person asks.
Questions to ask before you connect an agent to a decision
- Which decisions in this process have a right answer defined by policy?
- Who owns that policy today, and can they read it?
- If the agent gets it wrong, how would we find out?
- Can we show an auditor what the agent was told, and why?
If the answers are uncomfortable, the decision needs a firmer home before the agent goes live.
Next steps
Read about unexplained decisions, see how the REST API works, or learn what decision automation is. Then see your own decision running in 30 minutes and ask how an agent would call it.