What is Deterministic AI?
When we talk about AI behavior in production systems, predictability matters. Deterministic AI is a term for systems that produce the exact same output every time they receive the same input. There is no randomness involved. The logic follows a fixed, defined path, so the result is always consistent and reproducible. Think of rule-based systems, decision trees, or traditional search algorithms. Given identical conditions, they behave identically. That consistency makes them easier to test, audit, and trust, especially in business-critical workflows.
What Actually Happens Between Your Question and an AI’s Answer
Most people who build AI applications for the first time run into the same obstacle. They hand the AI a problem and expect it to produce the same answer every time. It won’t.
At Soliant Consulting, we built a local AI assistant for a large community college district, working alongside Apple. The system lets staff ask questions about device inventory, total cost of ownership, and HR policy in plain English. The biggest lesson from building it had nothing to do with picking the right model. It was about figuring out how little work to give the model. This lesson also surfaced in building a harness for FileMaker Agentic AI coding.
The Problem with Handing Everything to the AI
Language models do not follow formulas. They generate responses based on probabilistics, which means the same question can produce a different answer every time.
Here is the example that captures it. The college district wanted to calculate total cost of ownership across thousands of devices. Before this system, crunching those numbers took weeks. Their question: can AI help?
Yes. But without a defined formula, a model will use a different methodology each time you ask. Today it might factor in replacement cost and labor. Tomorrow, depreciation. The week after, something else entirely.
For a casual chatbot, variability is acceptable. For a procurement decision affecting millions of dollars in hardware, it creates a real problem. School districts and community colleges operate under union contracts, compliance requirements, and procurement rules. Getting a different answer every time is not just inconvenient. It creates liability.
Soliant Consulting’s approach on this project started with a direct question to the client: how do you define total cost of ownership? Show us the formula. We did not assume. We asked.
Let Code Do the Work. Let AI Do the Talking.
The core design principle for this project is simple: AI decides what to say. Deterministic code does the actual work.
In practice, that meant Soliant Consulting coded the total cost of ownership calculator from scratch. The client defined the formula. We built it into a rules engine. The model does not touch the calculation. Its job is to take the result and format it into a readable response.
This matters beyond consistency. When someone questions a cost calculation or a compliance result, they need to be able to point to exactly where the number came from. Code-driven operations are auditable in a way that AI-generated answers are not.
Soliant Consulting applied that principle to every high-stakes operation:
- Salary lookups run against a verified pay schedule using a defined formula
- Compliance checks evaluate rules-based logic in code, producing pass or fail results
- Device queries execute pre-verified SQL against a known database schema
- Chart generation runs deterministic code, not model inference
The model touches none of these directly. It understands the question, routes it to the right tool, and presents what comes back.
Shepherding the AI Toward Reliable Results
Teams building a system like this need to decide, before writing any code, which operations AI should handle and which code should handle. The word I keep coming back to is “shepherd.” You herd the application toward the right answer rather than letting the model wander.
One of the most practical shepherding tools Soliant Consulting built was slash commands. Users type /tco to invoke the total cost of ownership calculator, /cost for a fully loaded salary lookup, /chart to visualize a result. A slash command is an explicit statement of intent. The user tells the system exactly which path to run. Nothing is left to the model’s interpretation.
Before the AI pipeline runs at all, the system checks whether the question matches a known query template. We worked with the client to identify the most common questions their staff would ask, then wrote and verified a SQL query for each one. When a user’s question matches a template with at least 85% confidence, the system skips AI planning entirely and runs the pre-verified query. Writing the query is never the model’s job.
For questions that don’t match a slash command or a template, the full AI pipeline kicks in. Even there, my team and I kept each model’s role narrow. We use three separate models: a small, fast one classifies intent in about one second; a larger coder model generates SQL in about two seconds; a small model formats the final response. That approach keeps total response time at two to four seconds. One large model handling all three jobs would be slower and, for most steps, unnecessary.
The Lesson That Catches People Off Guard
Bigger models are not better for production AI applications. They are slower, often wasteful. And, as we learned firsthand on this project, they still cannot reliably generate financial calculations.
My early instinct was to grab the biggest available open-source model and let it handle everything. I defaulted to a 120 billion parameter model. It worked. It was also slow, and most of that compute was wasted on jobs that a much smaller model handles just as well.
More importantly, no model, regardless of size, should generate your financial calculations. That is a design decision that needs to be made before writing a single prompt.
Users of this system type a question and get an answer in two to four seconds. What happens between those two moments is a carefully designed pipeline where code and AI each handle the part they are actually good at. The whole stack runs on Mac Studio hardware with no cloud dependency. No OpenAI, no Anthropic, no external API calls.
The teams that struggle with AI reliability are usually the ones that handed too much to the model. The ones that build something dependable treated AI as one tool in a larger system, not the whole system. That is what a production-grade AI application looks like. Without that discipline, you have something that works sometimes.
Building Your Production AI Application
Building a production deterministic AI application is not a one-time project. The models improve, you discover new use cases, and the balance between what AI handles and what code handles shifts as you learn how your users actually ask questions. Soliant Consulting approaches this as a long-term partnership. We build AI applications that are auditable, maintainable, and designed to get better over time.
Schedule a free 30-minute consultation with Soliant Consulting’s AI development team. We will walk through your specific use case, identify where AI adds genuine value, and be direct about what code should handle instead.
