Operational intelligence

01 — Represent the objective and the completion criterion

An operation needs a clear definition of what it is trying to achieve.

We represent:

• the objective;
• the entities involved;
• the initial state;
• the expected result;
• the intermediate states;
• the constraints;
• the permissions;
• the deadlines;
• the risks;
• the completion signal.

This representation makes it possible to distinguish between completing a technical task and producing the effect that matters to the organisation.

02 — Gather the operational context

The information may come from ERPs, CRMs, document managers, databases, APIs, messages, events, rules and people.

The system builds a sufficient view of the case:

• what is known;
• which source owns each datum;
• what is in force;
• what information is missing;
• which decision has already been taken;
• what authorisation exists;
• what remains pending;
• what has changed since the last transition.

Informational intelligence supplies meaning, evidence and relationships. Operational intelligence uses that context to decide which path can continue.

03 — Apply logic and policies

Business logic may include:

• validation rules;
• calculations;
• permitted states;
• authorisation policies;
• segregation of duties;
• thresholds;
• calendars;
• contractual conditions;
• priorities;
• exceptions;
• risk limits;
• escalation criteria.

Part of that logic is formalised. Another part has to be reconstructed from code, configurations, documentation, traces and expert knowledge.

DocuLogic helps make it examinable and to separate observed behaviour, inference, validation and organisational decision.

Logic that demands reproducibility and control stays in deterministic components. Models come in wherever there is interpretation, prediction, classification or contextual choice.

04 — Design how the work is distributed

Every part of the system must occupy a comprehensible responsibility.

Rules and calculations

They apply explicit conditions and transformations.

Machine learning

It contributes predictive signals, rankings, anomalies, forecasts or probability estimates.

Optimisation

It selects allocations, sequences, priorities or trade-offs within objectives and constraints.

Language models

They interpret requests, compare information, explain, summarise and compose language.

Agents

They choose among permitted tools or paths when the sequence depends on the context.

Durable workflows

They preserve states, dependencies, events, waits, retries and recovery.

People

They contribute knowledge, judgement, negotiation, authority, accountability and the capacity to change the policy.

Machines

They perceive and act in physical environments under safety and control limits.

The design distributes these functions and the orchestration holds the result together.

05 — Orchestrate agents, software and people

Orchestration decides:

• which participant receives the case;
• what context it needs;
• which tools it may use;
• what output it must produce;
• what state it leaves behind;
• which permissions apply;
• when it needs help;
• what happens when it fails;
• who holds the next responsibility.

A multi-agent system adds value when there is real specialisation, separate contexts, parallel work or independent review.

Coordination also adds cost, latency and possible failures. Every agent must justify its presence through a defined function, defined contracts and a defined stopping criterion.

06 — Keep processes durable

Work may last seconds, days or months. Time is part of the state.

The system preserves:

• expected events;
• deadlines;
• pending authorisations;
• information requested;
• dependent tasks;
• owners;
• retries;
• actions already executed;
• versions that changed;
• open questions;
• commitments made;
• criteria for resuming.

A durable workflow makes it possible to suspend the work, receive an event and continue from a checkpoint without rebuilding the history or duplicating completed actions.

07 — Design the human intervention

Human participation serves different functions and each one needs an interface of its own.

Completing context

A person supplies information the system cannot establish.

Validating an inference

A specialist confirms, corrects or bounds an interpretation.

Deciding a trade-off

The situation sets objectives, costs or risks against each other in a way that requires judgement.

Authorising

The action needs formal authority.

Resolving an exception

The case does not match the existing paths.

Correcting or stopping

The person modifies the context, rejects the proposal, stops the process or changes its direction.

Improving the policy

Repeated exceptions and decisions make it possible to review rules, thresholds and responsibilities.

A useful intervention presents:

• the objective;
• the state;
• the reason for the handover;
• the relevant evidence;
• the proposed action;
• the alternatives;
• the consequences;
• the authority being requested;
• the next step.

In this way the human in the loop becomes a function of knowledge and decision. Human intervention is designed with a defined function, a defined context and a defined authority.

08 — Execute through tools under contract

Actions are exposed through tools with an explicit interface.

Every tool declares:

• inputs;
• outputs;
• identity;
• permissions;
• effects;
• errors;
• idempotency;
• reversibility;
• observability;
• conditions of use.

Agents may choose among permitted tools, but the contracts, the policies and the deterministic software protect the effects.

MCP and FastMCP can offer a common way of exposing tools to agents. APIs, connectors and events integrate the system with the business operation.

09 — Recover the work when something fails

Failures are part of the operational design.

An application may not respond. An event may arrive twice or out of order. An authorisation may expire. A model may produce an invalid output. An action may complete technically without achieving its objective.

We design routes to:

• validate before acting;
• retry safe operations;
• avoid duplicates;
• compensate when an inverse action exists;
• preserve a consistent state;
• escalate with context;
• declare a case partial or pending;
• record what happened;
• indicate what remains to be done.

Recovery preserves the evidence of the failure and turns it into information for operating and improving.

10 — Verify the result

Every operation needs a source or signal that allows its effect to be checked.

Examples:

• the ERP shows the new state;
• a document has been validated and linked to the case;
• an external service confirms the transaction;
• the responsible person accepts the result;
• a reconciliation matches;
• the order reaches the next stage;
• a machine observes that the object is in the expected position.

Verification may need a subsequent reading, an independent signal or a physical check.

An operation ends when the expected effect can be observed or the case is placed in an explicit state. The completion criterion belongs to the design from the start: it makes it possible to build useful metrics and to distinguish activity from result.