When to Use Deterministic Steps in Agentic Workflows

TL;DR

• The ask: A multi-site orthopedic practice wanted their support agents to book patients' appointments at the nearest clinic.
• What failed: The AI model alone was inconsistent; one zip code prompt would return multiple different nearest locations.
• What worked: Deterministic rules integrated into the agentic workflow to accurately and consistently determine the nearest location.

Brent Thomas is a Senior Solutions Architect at Zingtree, where he builds support automations for healthcare, insurance, and financial services teams. Most of his week goes to one question: which steps in a workflow should a model handle, and which need a real API call.

The ask, and why it was harder than it sounded

A multi-site orthopedic practice came to us with a routing problem. Patients call or chat to book, and the front desk has to work out which location is closest before it can offer an appointment. Staff were doing that dozens of times a day, and sometimes they got it wrong. 

They wanted us to take the patient's zip code and return the nearest clinic they can actually book. Sounds like simple automation. Spoiler: it is not. 

Intake and scheduling is where a lot of revenue quietly leaks out of a practice. That changes what a "good enough" LLM answer means. An address needs to be always correct. And because it sits inside a HIPAA-governed process, we had to be able to explain months later how any answer was produced.

The same zip code each time returned different clinics

The client already had a customer-facing AI build. The model was handling the conversation with the patient, so handing it one more question, which of these five clinics is closest, looked like the smallest possible ask.

We wired the ranking to OpenAI, and the answer moved between runs. Same zip code, same list of clinics, same request, three times.

• Run 1. Location A comes back closest, eight miles away.
• Run 2. Location A comes back third, fourteen miles away.
• Run 3. Location A back in second, around ten or eleven miles. 

Nothing in the request had changed. Worse, I could not tell how it was deriving proximity at all. 

As I put it to my team at the time: AI is really good at making stuff up, or at least at taking its best guess. It is not good at always saying that one plus one is two. Sometimes one plus one is two and a half, for reasons you cannot inspect.

What we tried before we took the step off the model

Our second attempt kept the model and gave it something solid to stand on.

Every ZIP code has a primary USPS office. So we told the model to treat that office as the reference location and measure from there. If the drift came from the model inventing its own reference points, supplying one should end it.

It did not end it. The output kept moving.

That failure taught us the rule I now use most often: a deterministic input does not give you a deterministic output. We had locked down what went in. We had not touched what the model was free to do with it, and that freedom is where the variance lived.

The fix was smaller than any of that

Our third attempt bypassed the model entirely for this one step. The ZIP code comes in and gets geocoded. Then the distance question goes straight to Google's Maps APIs, which return distance and duration for every origin and destination pair. 

We tested it repeatedly and got the same number every time. That is the property we had spent two attempts trying to coax out of the model, and it came free the moment we stopped asking a model for it.

What sold the customer was that they could check it themselves. Open Google Maps, type the two addresses, see 7.32 miles. Anyone at the practice can do that in fifteen seconds without knowing what an API is. That is what moved us from "sometimes it works, we are not certain, can you do more testing" to "this works, this is exactly what we need, let's go live."

How we decide which steps keep the model

One step was fixed. The rest of the workflow still had a model in it, and I had no principled way to say which parts should keep it. 

Two questions sort it now:

• What does a wrong answer at this step cost? A misread tone costs a slightly awkward sentence. A wrong clinic costs a patient an hour in the car and a missed appointment.
• Could the person on the other end check it? The practice can verify 7.32 miles in Google Maps in fifteen seconds. Nobody can verify why the model put location A third on the second run, including the people who built it.

Where the cost is high and the check is impossible, that step comes off the model. Everything else stays. 

The shape those two answers produce is a funnel: wide at the top, narrow at the bottom. 

Where AI adds the most value

The wide top of the funnel is the part worth paying for, and it is most of the conversation. 

A model handles what nobody mapped. You can design for intent one, intent two and intent three. A real customer arrives with intent four, which nobody wrote a branch for. A model still responds sensibly instead of dead-ending them. 

A model reads what a person actually means. Ask whether an inbound email is angry, fishing for information, or about to escalate to a manager, and a model beats anything you would write by hand. There is no single correct answer to "how annoyed is this person", so there is nothing to be wrong about. That is the signature of a step a model should own.

A model holds the line without being rude about it. Someone can ask about your core product, about the weather, or try to take the conversation into politics. A model can say we do not discuss politics here and steer back to what it can help with.

And a model makes the person feel dealt with. They feel seen, they feel heard, and they feel like their question is making progress. That is not a soft benefit in support. It is most of what a customer is judging you on while the real work happens underneath.

Where the funnel narrows to one answer

At the bottom of the funnel exactly one answer is correct, and somebody acts on it:

• You do not want AI saying we reviewed your test results and you do not have a broken bone. You want that from a doctor. 
• You do not want AI saying we think your case will not go to trial. You want that from a lawyer. 
• You do not want AI saying you should have money in your account, I think. You want the exact figure.

The pattern underneath all three is a number, a balance, an eligibility, a distance, a medical or legal status. Those belong on a fixed call, every time.

Run the fourth pass on your vendors

Drawing the line is one thing. Proving it holds is another, and it is the same test whether you are building the workflow or buying one.

Governance is a set of boundaries you can say out loud. This agent helps people reset a password and reaches a human when it cannot. It is not a weather service, and when asked for a forecast it says so and steers back. At field level it gets specific: if a free-text box writes into a Salesforce record, strip the profanity before it lands and log that you did.

Now take that fourth pass into your next vendor demo. If two vendor demos look identical, that is because you are watching two happy paths. As a customer, I do not care what goes right in a demo. I care about what you are not showing me, and I will try to break it on the call.

Sometimes AI needs to know when AI is not the right tool for the job, and you need to see how people get looped in over the top of it.

If the answer to any of those is a punt, that is the answer. "We're working on that." "That's coming in Q2 next year." The more punting in a demo, the less confidence I have.

Bring the four passes to your next demo, ours included. If you want a second pair of eyes on your own workflow first, talk to our team, or read how a regulated insurer worked the same split in 1st Central's FCR story.

Frequently asked questions

What is an agentic workflow?

An agentic workflow is a process where an AI model decides what happens next at each step, rather than following a branch someone drew in advance. The model reads the customer's message, works out what they are trying to do, chooses which action or lookup fits, and carries the conversation forward. It also means the model is making choices at every step, so the useful design question is which of those steps it should be allowed to answer on its own and which need a deterministic call to a real system.

Which steps in an agentic workflow should be deterministic?

Any step where exactly one answer is correct and the customer acts on it: a distance, a balance, an eligibility, a coverage decision, a medical or legal status. Where the cost is high and the check is impossible, that step should run as a fixed API call rather than a model inference, so it returns the same value every time. Everything above it stays with the model, which is where most of the conversation lives and where it adds the most. This split is what separates an agentic workflow that demos well from one that holds up on resolution accuracy in production.

Is ChatGPT deterministic or non-deterministic?

Non-deterministic by default. Temperature zero and a fixed seed reduce variance, but OpenAI's own documentation states that determinism is not guaranteed even then, and backend changes can alter output for an unchanged request. The more useful question is which steps should never depend on that answer.

Which customer service decisions should never be automated with AI?

Any step producing a number, a balance, an eligibility, a distance, or a medical or legal status. The pattern is a step where one answer is correct and the customer acts on it, which covers most financial, medical and legal outputs. A model can front the conversation and route to the right lookup; the lookup belongs on a real call to a system of record. In regulated healthcare workflows you must also be able to reconstruct how the answer was produced.

What are AI guardrails, and how do you test them?

Guardrails are the boundaries constraining what an agent may do and say: the scope it works in, the topics it refuses, the fields it sanitizes, the thresholds at which it hands off. Test them in four passes: good case, bad case, neutral case, and a deliberate attempt to break them. The fourth is the only one that tells you anything, because you wrote the guardrail and the first three drive at its middle. More on how we build them here.