How it works

From your Dolibarr history to an informed decision.

The same journey for every situation: observe, understand, set expectations, keep only what matters, call in the right expertise, let you decide, learn.

1. Kohentra connects to your Dolibarr, read-only

Kohentra regularly reads your instance through its API and keeps a local copy of your business objects. It reads only the resources you have opened to it, and that the API makes accessible.

An inaccessible resource is not worked around: it is recorded as such, and the analyses that depend on it hold back. A resource of little use can be put to sleep by Kohentra: it stays under watch and comes back on its own. Disabling it, however, remains your decision.

2. It discovers how you work

Objects actually used, native relations, custom fields, add-on modules, observable business chains: Kohentra maps what your Dolibarr really contains, and what it can say about it.

You can suggest a relation to test. Kohentra checks it against your data and returns a verdict, without ever overstating it.

3. It learns what is normal

Recurring series and their cadence, usual lead times between two related facts, observed sequences: every reference is measured on your own history.

Each analysis declares what it needs: resources, minimum usage, sufficient coverage. If that isn't there, it doesn't run, and Kohentra tells you why. An analysis can also run in observation, measured without bothering anyone, before it goes live.

4. It works out what should happen

From a recurring series or a usual lead time, Kohentra projects the expected event, with a tolerance drawn from how regular things have been. Once that window has passed, the absence becomes an unmet expectation.

It would rather project nothing than project on a thin basis: a poorly founded expectation doesn't produce a weak signal, it produces a recurring false one.

5. It keeps only what deserves your attention

Late payments, interventions to close, tickets without follow-up, missing recurring invoices, intentions noted but never completed: every situation kept goes into the “To review” queue, with the facts behind it.

A situation you have already settled doesn't come back with every analysis: Kohentra recognises it by a fingerprint of its facts. It reopens only if those facts change, and says so.

6. It calls in the right expertise

When a situation needs precise expertise, Kohentra orchestrates the specialised agents. No agent is ever called outside this single entry point.

  1. Qualify the situationbased on what is already established about it.
  2. Pick the agentthat has something to contribute on this exact subject.
  3. Order the workone agent's conclusions become the context for the next.
  4. Skip the pointlesswork already done, in progress or no longer relevant is not started.
  5. Keep a traileach job keeps the orchestration decision that created it.
  6. Respect your judgementsa conclusion you have judged wrong no longer establishes anything.

7. You decide

For each situation: Confirm, Already handled, Not relevant or Review later. A decision records your reading in Kohentra; it never writes to Dolibarr.

For an agent's conclusions, you judge: correct, incorrect (and which conclusion was expected) or impossible to judge. That is what qualifies the agent.

8. Kohentra learns from you

Your feedback on the relevance of situations measures the quality of each analysis. When it shows a setting should change, Kohentra turns it into an adaptation proposal, measured in simulation, which you can reject or send back for re-evaluation. It never applies itself.

Your judgements on agents' conclusions expose their mistakes and drive their new versions, which in turn have to prove themselves.

Learning is continuous. Trust has to be demonstrated.

See this journey on real situations.