Doctrine IA Ormuz

Notre conviction

B2B financial processes involve two kinds of logic. Most decisions are deterministic : if the credit limit is exceeded, block; if the invoice is paid, reconcile. These rules are predictable, auditable, and fast — they do not need AI.

But some situations are genuinely ambiguous : unusual purchase behavior that may not be fraudulent, a risk score exactly on the threshold, a scanned invoice with malformed fields, a buyer profile fitting no predefined segment. This is where AI adds value: analyze, qualify, and formulate a recommendation or, when explicitly authorized by the process, exercise a bounded business action through a tool.

AI use must remain purposeful : every model call has cost, latency, and inherent uncertainty. Using AI for a decision that a simple rule solves just as well is a poor investment. Using a simple rule for a situation where only AI can handle the complexity is an operational risk.

The Console assistant

The Ormuz Console includes AI assistants in its design studios. They understand the context of the current artifact — Process, Decision, or Agent — and can explain, propose, then apply changes to the draft when you ask.

Extension-oriented question. "How do I integrate Sumsub into my onboarding process?" The assistant explains available nodes, required parameters, received events, and produced objects.

Need-oriented question. "I want to assess the risk of my B2B buyers in France." The assistant can map that need to extensions and primitives actually available in the catalog, considering their status, then explain differences in coverage and use before proposing a design.

The assistant can modify the draft, but it does not replace the artifact validation lifecycle. You remain responsible for the created revision, its publication, and the behavior ultimately executed. The assistant accelerates design; it does not turn a proposal into a production contract without the normal control steps.

Operational Agents

An Ormuz Agent is a versioned artifact distinct from a process. It groups one or more business activities, each with a typed contract, authorized tools, guardrails, and a policy for optional Agent Memory access. A process can invoke a precise activity through the node Agent task.

The following examples illustrate possible patterns when the activity receives the required data and tools. They are not a list of automatic capabilities provided by every Agent.

This list is not exhaustive. The guiding principle is always the same: an Agent is relevant when the situation involves heterogeneous data, contextual judgment, or analysis beyond the complexity of a maintainable rule. The complete model is documented in Understanding Agents.

The framework: bounded, auditable, controlled

Bounded AI — explicit authority per activity

An Agent has no general authority over the platform. Each activity has only the tools assigned to it and produces outputs conforming to its contract. One activity may therefore be purely analytical while another can exercise a precise business action through an authorized tool.

You define the conditions under which the process accepts the Agent result, routes to human review, or triggers another activity. Effectful actions remain visible in activity configuration instead of being implicit.

Auditable AI — distinguish trace from explanation

An Agent Run is traceable by design: the platform retains revision and activity identity, observable data according to classification, tool calls, outputs, warnings, and execution status.

That technical trace does not by itself create a business explanation. When your process must retain justification, confidence, evidence, or a reasoned recommendation, explicitly include those fields in the activity output contract or materialize them in the appropriate business object.

Transparent AI — make automation understandable

When an Agent interacts directly with a participant, design the experience so there is no ambiguity about the automated nature of the exchange when that information is relevant or required in your context. Transparency should be treated as a property of the journey, not a note added afterward.

For journeys requiring human escalation, make it explicit in the process: routing condition, approval action, or operator handling. Ormuz provides orchestration primitives; the required level of human control depends on the decision's impact and the framework applicable to your activity.

Controlled AI — organize human review

Approval nodes and process routes let you insert human review where policy requires it: insufficient confidence, significant amount, business exception, internal rule, or applicable regulatory constraint.

Human review is not necessarily a fallback mechanism. It can be a normal step in operational policy, decided according to risk and impact rather than applied indiscriminately to all AI uses.

What we do not delegate to AI alone

AI is powerful but imperfect. Some situations should not be resolved by an Agent without safeguards.

• Irreversible or high-stakes decisions without appropriate control. A credit rejection, account closure, or regulated operation may require a review policy, additional evidence, or specific authority. The Agent can contribute to analysis, but the process must materialize the controls actually required in your context.

• Decisions subject to regulatory or contractual constraints. Requirements vary by domain, jurisdiction, and the exact role of automation. Explicitly model required validations, responsibilities, and evidence rather than assuming an Agent can replace them.

• Very high-volume, very low-complexity decisions. If a deterministic rule solves 99% of cases in microseconds at zero cost, calling a model for the same cases is a poor economic choice. Reserve Agents for what justifies their cost.

• Situations where error is asymmetric and not observable. If the result of an Agent error cannot be detected and corrected quickly, tolerance for uncertainty must be low — and the human path systematic.