What Is Business Logic for AI Agents?

Business logic for AI agents is every decision you can write down as a rule: approval limits, thresholds, who may see what, what happens when a step fails. It belongs in code, not in the prompt. The agent gets the opposite kind of work: reading a filing, classifying an odd request, drafting a message. Draw that line correctly and an agent becomes ordinary, dependable software that happens to use a model for the steps that need judgement. Draw it wrong and you get a system that is fluent, confident, and impossible to audit.

We build multi-agent platforms for regulated organizations: chambers of commerce, compliance teams, professional-services firms. That means we don’t get to treat this as a philosophical question. Here is how we answer it in practice.

The line that decides everything

Ask one question about every decision in your workflow: could a competent colleague write this down as a rule that always holds?

If yes, it is business logic. A VAT rate, a credit limit, which user role may approve an invoice, the retry policy when an upload fails: none of this needs intelligence. It needs to behave identically on Tuesday and on Christmas Eve, and the only place that guarantee exists is code, where a test can prove it.

If no, because the input is messy human language, a scanned document, or a judgement call, then that is the agent’s territory. Understanding what a supplier’s email is actually asking, extracting figures from a 40-page financial statement, summarising an incident report: no rulebook covers these, and pretending otherwise is how companies end up with 4,000-line if-statements nobody dares touch.

Most failed agent projects die on exactly this line, and not on the side people expect. Teams rarely fail because the model was too weak. They fail because the rules migrated into the prompt, where they cannot be tested, cannot be meaningfully versioned, and cannot be explained to an auditor six months later.

Why rules inside prompts fail (and how we learned it)

A rule written in English inside a prompt has three fatal properties. The same input can take different paths, so no test suite can pin it down. A paragraph of prose doesn’t diff; a reviewer can’t approve “we changed the tone of the third instruction” the way they approve a code change. And when someone asks why the system made a specific call in March, there is no line of logic to point to.

We didn’t learn this from a whitepaper. Early versions of our Nexus OMAS platform carried per-client behaviour as hardcoded prompt constants. It worked, until the second client, and the third, and the moment we needed to know which version of which instruction produced which output. We rebuilt the whole layer as a database-driven system: global defaults, vertical packs, per-company overrides, with an append-only audit history. Prompts became configuration: versioned, reviewable, explainable. The rules that must never bend moved out of prompts entirely, into code that enforces them whether the model cooperates or not.

Rules engines vs AI agents: a division of labour, not a replacement

There’s a popular framing that LLM-based agents are the next step “beyond” business rules engines. We think that’s the wrong mental model. Rules engines earned their place because they are transparent, auditable, and predictable, exactly the properties a model cannot promise. What agents add is everything rules engines were always bad at: unstructured input, ambiguity, language, context.

The production answer is almost always a hybrid. Deterministic logic decides what is allowed; the model decides what is meant. The agent interprets a document and proposes; the rule layer checks the proposal against limits that never move. Replacing a working rules engine with a prompt is not modernisation. It is trading a system you can test for one you can only hope about.

How we draw the line in Nexus OMAS

Concrete beats abstract, so here is the split inside our own platform.

In BalanceIQ, the Chamber of Commerce deployment, five specialised agents read scanned Greek financial statements: messy, inconsistent, decades of formats. That is judgement work, and it’s theirs. But the nine financial ratios computed for every company? Pure arithmetic, computed in deterministic code from the extracted figures. An accountant can check them by hand and get the same number the platform got, every time. The agents never “estimate” a ratio, because a ratio is a rule.

Anything with a monetary or outbound effect sits behind an approval gate. In our finance workflows an agent reads invoices and proposes ledger entries; a person approves before anything posts. In our outreach module the agent drafts every message; a human edits and sends. This isn’t an instruction in a prompt asking the model to be careful. It is structure. The action path physically requires a human step, so the guarantee holds even on the model’s worst day.

Agents get named tools with narrow permissions, never raw access. A tool that can read one client’s documents is auditable; a connection that can run any query is not. Every tool call is logged with its inputs and outputs, because the honest test of a production system is whether you can answer “why did it do that?” months later, with evidence rather than a shrug.

Deletion is human-only. Some capabilities we simply do not give the agents, whatever the prompt says. The cheapest way to prevent a catastrophic action is for the code path not to exist.

The result is the discipline we’d describe in one sentence: you watch it think, you approve before it acts. The models are genuinely the least interesting part of the architecture, and that is a compliment to the architecture.

A working checklist

Belongs in code:

• Thresholds, limits, pricing and rates
• Permissions, roles and approval chains
• Failure and retry behaviour
• Anything a regulator might ask about
• Anything that must be identical twice

Belongs to the agent:

• Reading and classifying documents
• Interpreting requests written by humans
• Drafting content for human review
• Summarising and extracting structure from mess
• Proposing next steps for a person to accept or reject

Belongs to neither: a fully specifiable workflow with clean inputs. If every step can be written down, a plain workflow is cheaper, faster and testable, and recommending one instead of an agent is sometimes the most useful thing we tell a prospective client.

Common questions

Should an AI agent query the database directly?

No. Give it named tools scoped to exactly what it needs. The narrow version costs nothing extra on day one and is the difference between an audit trail and an incident report later.

How do you stop an agent from doing something expensive?

Structurally, not rhetorically. Ceilings, approval gates and human-only actions live in code. A prompt is guidance; a missing code path is a guarantee.

Do we need to train our own model?

Almost certainly not. In every system we’ve shipped, the value sits in the environment around the model: which data it sees, which tools it holds, who approves its output. That environment is also the part you own outright.

When is an agent the wrong answer?

When the task is fully specifiable. Agents are for the parts of your operation that need reading and judgement. For everything else, boring automation wins, and boring is a feature.

Where to go from here

If you’re weighing an agent project, start by sorting your process into the three buckets above; most of the risk disappears in that one exercise. And if you’d like to see the split running live, the fastest way is our two-week pilot: your own documents in Nexus OMAS, cited answers on real files, with every rule where it belongs. Book a call, or read how the same architecture runs compliance for a UK enterprise.