Rules engines don't die in the agentic era — they get promoted. An LLM agent can reason, but it cannot decide the way a regulator expects: deterministically, repeatably, with an audit trail showing exactly which policy fired. That's what ODM has done for well over a decade. The change isn't that agents replace your rules. It's that your rules finally get a caller that understands context.
The division of labor
The clean architecture splits along a line most teams already sense:
- The agent gathers context, interprets unstructured input, chooses which decision to invoke, and explains the outcome in language a human accepts.
- ODM makes the actual decision — eligibility, pricing, limits, compliance — the same way, every time, for every caller.
Autonomy at the edges, determinism at the core. Neither side does the other's job.
How it works today
This isn't a thought experiment. IBM ships a Decision MCP Server that exposes deployed ODM rulesets as tools a watsonx Orchestrate agent can call mid-conversation. Enable a ruleset for agent use, register the server against your Decision Server runtime, and your credit-decisioning logic becomes a tool in the agent's toolbox — with ODM still the single source of decision truth.
The mechanics are straightforward: create the agent in Orchestrate, add the Decision MCP Server, enable the rulesets you want callable, deploy. The interesting work is everything around those four steps.
What the tutorials don't tell you
Orchestrate currently doesn't support decision services with complex types in their signatures. Real-world rulesets are full of them — nested customer objects, collections of coverages, enumerated product structures built up over years.
In practice you need facade decision services with flattened inputs: strings, numbers, booleans. That sounds like a workaround. Treat it as an opportunity. The facade becomes your agent-facing decision API — the contract every agent, and eventually every channel, calls. Design it once, version it, govern it. Teams that rush this step end up with a different flattening per use case and no single decision interface at all.
Why this matters for governance
When the agent can show "I called CheckEligibility v4.2 with these inputs and got this result", you have something an auditor can work with. When the LLM decides eligibility itself, you don't. The same decision logic your compliance team already signed off keeps making the decisions — agents just widen who and what can ask.
The head start nobody mentions
If you run ODM today, you're closer to production-grade agents than teams starting from scratch — the hard part, governed decision logic, already exists. The work is in the interface: facades, entitlements, and the discipline to keep decisions in the engine rather than letting them leak into prompts.
We help teams design exactly that boundary — and we've been on both sides of it.