Deterministic AI agents: what they are and when a business needs one

The four outcomes are the test for a deterministic agent

An agent passes when each output lands in exactly one of these outcomes and carries its record:

• Fulfilled with proof. The answer goes out with its proof: the facts, the rules, the rule versions, and the dates behind it. Each fact points to its evidence, the exact place in a source where it was found.
• Refused by a rule. The agent stops and names the rule the answer would have broken.
• A named gap. The agent states which fact is missing.
• Reserved for a human. The call belongs to a person, so the agent routes it to them.

Each of these outcomes, with its record attached, is decision-grade, whichever model sits behind the agent.

How do symbolic constraints affect what an agent can send?

Symbolic constraints hold an agent to those four outcomes. A deterministic agent pairs a language model, which reads the sources and writes the answer, with constraints that decide what ships. Hard rules pass or fail outright, so an answer that breaks one stops before it is finished. Soft preferences apply by default, and every override is recorded.

What makes a decision too high-stakes for a summary-only assistant?

Any decision where a confident wrong answer costs you money, a customer, or a regulator's attention needs more than an assistant. A wrong answer reads exactly like a right one, so nobody catches it in passing.

Prompted agents and assistants give those answers when they work from outdated facts, like last year's rate or a superseded policy beside the current one. They also drop rules, because a rule written into a prompt is an instruction the model can apply or skip, and nothing checks which it did. So someone on your team still checks every output by hand.

A decision needs a deterministic agent when it has four properties:

• It recurs. The same decision runs hundreds or thousands of times, so getting it right compounds.
• It is high-stakes. A wrong answer carries the costs above.
• It is scattered. The answer sits across systems and folders, and the connections between them live in people's heads.
• It is strict. Policy, precedent, and regulation bind the outcome, and all of them change over time.

Loan product matching at a mortgage broker and the quarterly portfolio company review at a private equity firm have all four.

How does a deterministic agent relate to retrieval and RAG?

Retrieval finds the passages relevant to a question, and retrieval-augmented generation (RAG) hands those passages to a model to write from. A deterministic agent uses retrieval as one input and adds the step after it, where each claim is checked against your business's rules before the answer goes out. Saphenia works at the checking step and governs what an agent is allowed to send.

For a question whose answer sits in one current document, where someone checks the output before anyone acts on it, retrieval is enough. A drafted policy summary is that kind of work, and a RAG pipeline handles it well.

Scattered and strict are the two properties that take a decision past retrieval. In practice they show up in three ways:

• The answer needs several hops across systems that were never built to be read together.
• Rules have to be enforced on every run.
• Facts change over time, so the agent must use the version that held for the period in question.

Some agent outputs drive an action: a credit decision, a client report, or a figure in an investment committee pack. For those, a context-management product has to enforce the rules as well as supply the context. Retrieval stops once the agent has the facts, so each claim in those outputs still needs a check against the rule that applies.

What belongs in an agent's decision workflow beyond retrieved context?

On top of the retrieved facts, an agent making a decision needs the company's decision logic. That logic covers:

• What the company's terms mean and which formula computes each one.
• Which source outranks which when two disagree.
• The thresholds and exceptions that shape the call.
• The precedent behind the last decision of the same kind.
• The decisions that always go to a person.

Around that logic sit the checks on every claim, the proof each answer carries, and a record of every run.

How is decision logic different from a semantic layer?

Decision logic starts from the definitions a semantic layer agrees on and adds what your business does with them in one decision. A semantic layer maps database structures to business terms so dashboards and queries agree on what a metric means, wherever that definition already exists. Decision logic sets which source wins, which threshold triggers an escalation, and which calls a person makes. It is enforced on every output the agent produces.

Decision logic also reaches into the contracts, filings, and policy documents where many of a financial decision's rules are written. A loan product match depends on lender criteria sheets, and a portfolio review depends on board packs and management accounts that arrive in different formats. A semantic layer leaves those documents, and the rules inside them, untouched.

What are the limits of a context graph for a recurring financial decision?

A context graph or context layer gives an agent connected facts to read, while a recurring financial decision needs rules applied to those facts on every run. In a quarterly portfolio company review, the same four situations come up every time:

• Two reports disagree. The same figure sits in two systems with different values, both dated, and a ranking rule picks the figure that stands. See reports that disagree for the method.
• A definition changed. A KPI was redefined between quarters, and each period needs the definition that held at the time. See changed KPI definitions.
• A fact is missing. The output names the gap.
• An expert corrects a figure. The correction carries into next quarter's run. See who signs off a figure for how sign-off works.

Saphenia reads the same systems of record a context product reads, then adds the rules and checks that decide what the agent can send, one workstream at a time. Every fact carries the period in which it was valid, and every rule is versioned. So any past decision can be rebuilt from the facts and rules that held when it was made. Modeling an enterprise-wide ontology takes years, while Saphenia generates right-sized decision logic, the amount one decision needs.

A worked example: matching a loan application to lender products

Take a mortgage broker and a panel of lenders, all invented for this example. The broker checks each application against every lender's criteria. Those criteria change often, and the broker has their own policy on top. One application produces all four outcomes.

• Lender A's product: fulfilled with proof. The applicant's income meets Lender A's criteria. The proof carries the income figure with its evidence (the tax return, page, and line), the criteria sheet with its version and date, and the rule that applied.
• Lender B's product: refused by a rule. Lender B's current criteria sheet caps loan-to-value at 80%, and the application sits at 85%. The refusal names the rule, the criteria sheet, and its version.
• Lender C's product: a named gap. Lender C's criteria require two years of address history, and the file covers one year. The output names the missing document and the lender rule that requires it.
• The whole application: reserved for a human. The broker's own policy sends any applicant self-employed for under two years to a credit manager. The agent routes the file there, where the credit manager can inspect the three results above and the evidence behind each.

The credit manager then approves the file and records a correction about how the broker treats one kind of contract income. Once approved, the correction becomes a rule that every later application follows. Mid-quarter, Lender B revises their loan-to-value cap. The next run applies the new version, and the earlier refusal still shows the version that held when it was made. For how to keep criteria current, see loan product matching.

What a business-line owner should ask before trusting an agent with a decision

If you are a Head of Credit, a Chief Underwriting Officer, or a COO, run these seven checks on your own documents before you hand an agent a decision:

1. Ask for all four outcomes on your own data. A pilot on clean sample data tells you little. See evaluating a pilot for the method.
2. Ask to see a refusal. The refusal should name the rule and its version.
3. Pick one figure and follow its proof to the evidence. The trail should end at a page, a cell, or a line in a named source.
4. Change a rule and rerun. The new run should apply the new version while the earlier run keeps the version it used.
5. Ask where the list of human-reserved calls lives and who maintains it. Your business owns that list.
6. Ask what happens to an expert's correction. The answer should show which later runs used the correction.
7. Ask who owns the rules and where they run. The answer should cover hosting, model choice, and what leaves with you if you switch vendors. For Saphenia, see security, hosting, and data ownership.

Where Saphenia fits among vendors of deterministic agents

Saphenia handles decisions whose data sits in separate systems and whose rules change over time, such as portfolio company reviews in private equity, loan product matching, and insurance product matching. Other vendors sell rule-following agents aimed at high-volume back-office finance processes and regulated operations work. Saphenia's buyer is a business-line owner in financial services with one recurring, high-stakes decision for an agent to make.

How Saphenia builds a deterministic agent

Saphenia delivers one workstream at a time: the decision logic, rules, and expert feedback for one recurring decision. Most of its rules already sit in your documents and systems. Saphenia extracts the terms, source rankings, and thresholds from those documents and structures them as decision logic. The rest of the rules live in your experts' heads. Your experts review the agent's work, and each correction they approve becomes a rule.

Saphenia builds the decision logic in days, and the first decision ships in weeks. Everything Saphenia builds from your data belongs to you, runs in the environment you choose, works with any model, and leaves with you. For the full picture, see what Saphenia does. If you are weighing an internal build, see the full cost of a build and how Saphenia is priced.