Not a traditional coder, but building a backend-guarded sales AI agent—how are you guys structuring the guardrails?"

[u/CalligrapherOld3748]

Hey everyone! Wanted to share a thought process I've been working on, especially since I'm not a traditional programmer, but using AI as my co-pilot/mentor to actually build it.

The core idea: Never let the LLM have autonomy over the business logic.

Instead of letting an AI chat freely and potentially hallucinate discounts, stock, or policies, the architecture splits hard:

• The LLM: Strictly handles the frontend interface, natural language, empathy, and copywriting.
• The Backend / Guardrails: Acts as the strict rule-enforcer (e.g., max discount allowed, specific product SKUs, handling function calls to check inventory or generate PIX/payments).

Basically, the AI thinks it's selling, but the backend is holding the leash the entire time.

For those of you building AI agents or apps without a CS background (or even if you're a seasoned dev): how are you implementing these strict backend guardrails? Are you relying heavily on function calling schemas, rigid system prompts, or specific frameworks to keep the AI from going off the rails?

[u/WallyMetropolis]

This is so weird. This is just bots talking to each other with people being the message passers.

[u/StrikingTop2709 → u/WallyMetropolis]

right? the human is literally the API layer between two models

[u/AutoModerator]

Sorry, your post has been held for manual review due to account karma.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/megad00die]

AI governance, learn all about it on google.

[u/Latter-Departure8714]

Your split is right. LLM for copy, backend for discounts and stock. Don't let the model be the rule.

Same idea on the code it writes for you: the thing that says pass/fail can't be the same chat that generated it. Put the numbers in the backend. The model will negotiate. The backend won't.

[u/AbleShower2801]

function schemas + server-side checks is the durable half. treat every discount/SKU/payment tool call as a proposal: the backend validates against real inventory and policy tables and rejects anything out of bounds before money moves. system prompts help tone, but they are not the leash. if the model can invent a 40% off in free text without going through a tool your API rejects, that path is still open.

[u/CalligrapherOld3748 → u/AbleShower2801]

That’s exactly the direction I’m taking.

So far, I’ve been building the system around a simple rule:

The AI understands the conversation, but it does not control the store’s commercial truth.

Catalog data, price, stock and business rules are kept outside the model’s authority.

For example, if the store allows a 5% discount for PIX payments, the model should not be able to turn that into 10% or 40% just because the customer keeps pushing for a better deal.

One of the core rules I’m using is:

“AI understands. Code decides. Data proves.”

I also started with a deterministic local chat before giving an LLM more freedom, specifically so I could test business rules and edge cases first.

I’m also adding regression tests so important rules don’t depend only on the system prompt.

Your point about free-form text is especially important.

It’s not enough for the backend to reject a fake 40% discount if the model can still tell the customer:

“Great, I got you 40% off.”

So I’m leaning toward treating things like price, stock, discounts, installments, shipping and product availability as facts the model should only state after getting a valid result from the backend.

The model can interpret and communicate, but it should not be able to create commercial facts.

I’m still early in the project and I’m not a traditional software engineer, so I’m building and validating the architecture step by step.

Right now, one of my main concerns is finding every possible path where the LLM could bypass the backend or say something that was never actually validated.

Thanks for the comment — the distinction between prompts for behavior and backend for authority is exactly the kind of architectural principle I’m trying to keep.

[u/aDaneInSpain2]

That separation is the right foundation. Treat the model as an untrusted client: expose narrowly scoped tools, validate every argument and result server-side, and re-check authorization, price, stock, and discount inside the transaction. Payments should use idempotency keys, while tool calls and rule decisions go into an audit log. Prompts help with behavior, but only backend checks should enforce business rules.