Architecting Domain Logic vs. Just

My LLM-powered agent was hallucinating business rules left and right because I treated the prompt as the "source of truth" for domain logic instead of using the LLM as a thin reasoning layer over a hard-coded engine. I spent three days chasing a bug where the agent would randomly apply a 10% discount to users who weren't eligible, despite the prompt explicitly stating the criteria.

The setup was a standard RAG pipeline. I had a complex set of pricing rules in a PDF, and I was feeding the relevant chunks into the context window, telling the model to "calculate the final price based on the rules provided." It worked 90% of the time, but that 10% failure rate was a nightmare for a financial tool.

The error wasn't a crash, but a consistent logic drift. I’d see logs like this:

{
  "input": "User is a Gold member from Canada. Total: $100",
  "context": "Gold members get 5% off. Canadian residents get 0% off.",
  "output": "Total price: $90 (Applied 10% Gold discount)"
}

I tried the usual prompt engineering fixes—adding "Think step-by-step," using Few-Shot examples, and even adding a "Verify your math" instruction. None of it stuck. The model was just guessing based on its training data (where "Gold" usually means 10% off) rather than adhering to the specific context I provided.

I diagnosed the issue by isolating the prompt and running a batch of 100 edge cases. The failure pattern was clear: whenever the domain logic required a strict boolean check (If X and Y, then Z), the LLM treated it as a "suggestion" rather than a constraint.

The solution was to stop asking the LLM to perform the logic and instead ask it to extract the parameters for a deterministic function. I shifted to a "Tool Use" architecture. Instead of:
"Calculate the price for this user,"
I changed it to:
"Extract the user's membership tier and country from the text and call the calculate_price function."

Here is the logic flow I implemented in Python:

def calculate_price(base_price, tier, country):
    # Hard-coded domain logic
    discounts = {"Gold": 0.05, "Silver": 0.02, "Bronze": 0}
    discount = discounts.get(tier, 0)
    return base_price * (1 - discount)

# The LLM now only outputs:
# {"tool": "calculate_price", "args": {"base_price": 100, "tier": "Gold", "country": "Canada"}}

The difference was night and day. By moving the domain logic out of the natural language prompt and into a typed function, the error rate dropped to zero.

The takeaway here is that prompts are terrible for strict business rules. If you have a logic gate that must be binary, don't trust an LLM to "reason" through it. Use the LLM to parse the unstructured input into a structured schema, then pass that schema into a traditional piece of code. Stop trying to "prompt" your way into a deterministic system; just build a deterministic system that the LLM triggers.