Prompting is a useful interface, but it is a poor place to hide the rules that keep a business correct. A prompt can explain a policy; it cannot reliably become the policy. When an AI feature touches pricing, permissions, inventory, customer data, or an external API, the system needs more than persuasive instructions. It needs business logic embedded in the application’s core.

This does not make language models less valuable. It gives them a safer and more useful job: interpreting language, proposing actions, and assisting users inside boundaries the backend can enforce.

Prompts describe intent; software enforces it

A prompt might say, “Never offer a discount greater than 15%, and only for eligible customers.” That sounds clear until a customer asks for an exception, the model misreads account context, or a later prompt edit changes the wording. The business rule is now scattered through natural language and difficult to test with confidence.

Instead, make the AI request a well-defined operation and let ordinary application code decide whether it is allowed. The model can identify that a customer is asking for a discount. It should not be the final authority on discount eligibility.

final class DiscountPolicy
{
    public function maximumFor(Customer $customer): int
    {
        if (! $customer->isEligibleForDiscount()) {
            return 0;
        }

        return $customer->isPremium() ? 15 : 5;
    }

    public function allows(Customer $customer, int $percentage): bool
    {
        return $percentage >= 0
            && $percentage <= $this->maximumFor($customer);
    }
}

The model can produce a proposed percentage. Your API validates it, loads the customer from the database, calls the policy, records the decision, and only then changes an order. This separation is not ceremonial architecture. It is what makes the rule inspectable, testable, and consistent across a chat assistant, an admin panel, a scheduled job, and a mobile app.

Give the model capabilities, not database access

A common shortcut is to let an AI integration compose SQL, call broad internal endpoints, or operate with a service account that can do everything. It makes demos feel fast and production incidents feel inevitable.

Design narrow tools around business actions. A support assistant may need findOrder, getShipmentStatus, and requestRefundReview. It probably does not need a general-purpose query endpoint or permission to mark any payment as refunded.

Each capability should have a contract that is boringly explicit:

• Inputs have types, required fields, and constrained values.
• The backend derives sensitive context, such as the authenticated user and tenant, rather than trusting model-provided identifiers.
• Authorization happens in the tool implementation, not in prompt text.
• Side effects are deliberate, idempotent where appropriate, and auditable.
• Responses expose only the data needed for the next decision.

This approach also improves API design. If it is hard to define a small, safe tool for an operation, the underlying business workflow may already be too tangled. AI integrations have a habit of exposing unclear boundaries that traditional screens managed to conceal.

Keep truth in the database and rules in the domain

Language models are good at working with ambiguous text. They are not a replacement for transactional state. The current balance, available stock, subscription status, and approval history belong in systems designed to preserve truth under concurrent changes.

A reliable workflow reads authoritative state immediately before a consequential action. Do not ask the model to remember that an item was in stock earlier in the conversation. Check inventory when creating the reservation. Do not assume an account is still eligible because a previous tool response said so. Re-evaluate eligibility when submitting the request.

For operations that affect multiple records, use the transaction facilities of your database and framework. For example, a reservation might lock or otherwise safely update inventory, create a reservation record, and emit an event only after the transaction succeeds. The AI layer should receive a result, not orchestrate partially completed writes through a chain of guesses.

There is an important distinction here: the model may help decide which workflow a user intends; the domain layer decides whether that workflow can occur.

Make failures part of the product design

AI features fail in ordinary backend ways as well as model-specific ones. A tool call can contain invalid arguments. A downstream service can time out. A retry can duplicate a side effect. A model can request an action that the current user cannot perform.

Build for these paths before adding polish. Validate tool inputs at the boundary. Return structured error categories that the AI layer can turn into useful language. Use idempotency keys for externally visible write operations when a client or worker may retry. Log the request identity, tool name, authorization result, and outcome without indiscriminately logging sensitive content.

Not every error should trigger another model attempt. Retrying an unavailable read service may be reasonable within a controlled policy. Retrying a charge, refund, or account mutation without an idempotency strategy is not. Deterministic retry rules belong in application code, where timeout limits and failure behavior can be reviewed.

Use prompts for guidance, not governance

Prompts still matter. They define tone, explain available capabilities, help the model ask for missing details, and tell it how to present a successful outcome. They can also reduce unnecessary tool calls by describing the expected workflow.

But treat prompts as an adaptive layer. They will evolve as users reveal new phrasing, edge cases, and expectations. Core business logic needs a different standard: versioned code, automated tests, clear ownership, and a deployment process that can be rolled back.

A practical test is simple: if the prompt were removed or misunderstood, would the system still protect the customer and the business? If the answer is no, the rule belongs below the prompt.

A dependable AI system is mostly dependable engineering

The strongest AI products do not ask a model to become a database, a security boundary, a policy engine, and an operations team at once. They pair a flexible language interface with conventional engineering discipline: small APIs, explicit authorization, transactional data handling, observable failures, and tests around the decisions that matter.

That design may look less magical than a giant prompt connected to every internal system. It is also easier to maintain when requirements change, easier to explain during an incident, and safer to trust with real work. Let AI handle uncertainty in language. Let your core handle certainty in business.