● B2B offer — Processes & orchestration
Process automation: a case that moves from system to system
A business process rarely stays inside a single tool: a request starts in one, is documented in a second, is approved in a third. Your orchestration reads, passes on and prepares each step, keeps the state of the case and stops at the approval points you have placed. Hosted in France: the data that moves around stays with you. Every committing step remains subject to a human decision.
Hosted in France
Process data protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Process orchestration · hosted in France
Where has the account-opening request in case 4182 got to?
State of the case: documents received and checked, record created in the business system, case put forward for approval.
Each step shows the system it came from and a timestamp.
The next step is an approval point: it is waiting for a decision.
🔗 Sourced · process log, system by system
Each step shows the system it came from and a timestamp.
The next step is an approval point: it is waiting for a decision.
🔗 Sourced · process log, system by system
What happens if a document is missing?
The case stays pending at the step concerned, and the request for the document is prepared for the applicant.
The orchestration never skips a step and never fills in a missing document: what is missing is reported as such.
✎ Support · case pending, follow-up prepared
The orchestration never skips a step and never fills in a missing document: what is missing is reported as such.
✎ Support · case pending, follow-up prepared
Local inference · no data outside the EU
Processes hosted in France
Sovereign by designLocal inference or hosting in France
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
The business department decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent orchestration moves a business process between your systems: reading the documents, passing them on, preparing each step and keeping the state of the case. It stops at the approval points you have placed and reports what is missing rather than filling it in. It runs with local inference or is hosted in France: the data that moves around stays with you, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
process uses ready to orchestrate
0
decision taken without human approval
These figures describe our offer, not results measured at a client. How large the gain is on the number of processes and systems crossed is confirmed by a pilot.
The context
What does AI orchestration bring to your business processes?
What slows a process down is rarely the steps themselves: it is moving from one to the next, from one tool to another.
! The issue
A case moves quickly as long as it stays inside one tool, and waits at every border between two systems. The orchestration takes on those crossings: it reads, passes on, prepares the next step and keeps the state of the case up to date. The approval points stay exactly where you placed them, with the case assembled and the origin of every element.
✓ Our answer
The business management follows its cases from end to end, with the timestamp and the source system of every step. What is missing is reported, never filled in by inference, and committing steps wait for a decision. Local inference or an isolated resource hosted in France: the data moving between your systems, often the most complete in the company, is not entrusted to any third party.
The decisive point
The data moving from one system to another: sovereignty & compliance
An orchestrated process moves data between several systems: every crossing must be traced and partitioned. Here is how.
Local inference
The agent can run on a machine belonging to your organisation: no process data leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your processes and the systems they cross: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For the data moving from one system to another, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your organisation and its processes.
Every step traced and partitioned
The source system and timestamp are kept for every step; encryption, role-based access (RBAC) and logging of each case's journey.
AI Act: governed deployment
The agent is strictly in support; no committing step is crossed without human approval; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For processes involving health or financial data, or data covered by professional secrecy, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
4 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
Process orchestration · hosted in France
Four flags this morning, all before any automation at all.
· Forty-one per cent of cases pass through a step that appears in no procedure. It catches errors.
· The "standard" case is sixty per cent of the volume. The other forty are each different.
· The gain claimed on data entry is lost again in checking. Step by step it exists; end to end it does not.
· Three steps have no explanation. I will not automate what I have not understood. morning-watch_4-flags.pdf41% pass through an unwritten step · 60% standard cases
⛓ Source · 3 processes, 4,200 cases observed, written procedures
· Forty-one per cent of cases pass through a step that appears in no procedure. It catches errors.
· The "standard" case is sixty per cent of the volume. The other forty are each different.
· The gain claimed on data entry is lost again in checking. Step by step it exists; end to end it does not.
· Three steps have no explanation. I will not automate what I have not understood. morning-watch_4-flags.pdf41% pass through an unwritten step · 60% standard cases
⛓ Source · 3 processes, 4,200 cases observed, written procedures
A step that is in no procedure?
Somebody has been doing it for years, and it is the reason the process works.
What I see on observing: between approval and dispatch, 41% of cases go through a review written down nowhere. It takes two minutes, it is done by the same person, and it stops on average 9 cases a week — inconsistent references, a missing document, an implausible amount.
What would have happened had I automated the written procedure: the process would have worked, faster, and those 9 cases would have gone out. Nobody would have noticed at once: the error only comes back at invoicing, or later.
Why the step is written nowhere: because it was born of an incident, somebody took it on, and it never had reason to enter a document. That is the commonest form of a department's knowledge.
What I do: I observe the real process before reading the procedure, and I list the gaps. Across three processes I found 11 undescribed steps, 4 of them checks.
What I automate of those eleven steps, and what I leave: I automate what a check verifies — reference consistency, presence of the document, an amount outside the range — and I run it before dispatch, not after. What it decides stays with the reviewer: an informal check is a judgement, and it is what stops the 9 cases a week. What the reviewer gains: the three mechanical verifications arrive already done, and their reading is spent on what only they can see. 41-percent_9-cases-a-week.pdfThat is the commonest form of a department’s knowledge
⛓ Source · 41% of cases, 9 stops a week, 11 undescribed steps
What I see on observing: between approval and dispatch, 41% of cases go through a review written down nowhere. It takes two minutes, it is done by the same person, and it stops on average 9 cases a week — inconsistent references, a missing document, an implausible amount.
What would have happened had I automated the written procedure: the process would have worked, faster, and those 9 cases would have gone out. Nobody would have noticed at once: the error only comes back at invoicing, or later.
Why the step is written nowhere: because it was born of an incident, somebody took it on, and it never had reason to enter a document. That is the commonest form of a department's knowledge.
What I do: I observe the real process before reading the procedure, and I list the gaps. Across three processes I found 11 undescribed steps, 4 of them checks.
What I automate of those eleven steps, and what I leave: I automate what a check verifies — reference consistency, presence of the document, an amount outside the range — and I run it before dispatch, not after. What it decides stays with the reviewer: an informal check is a judgement, and it is what stops the 9 cases a week. What the reviewer gains: the three mechanical verifications arrive already done, and their reading is spent on what only they can see. 41-percent_9-cases-a-week.pdfThat is the commonest form of a department’s knowledge
⛓ Source · 41% of cases, 9 stops a week, 11 undescribed steps
How do you work, and where do you hand over?
I observe, I measure end to end, and I refuse to automate what I have not understood.
What I do before any automation: I observe how it actually runs, I record the gaps with the procedure, I measure time end to end and not step by step, and I have every step whose reason I cannot see explained to me.
Routing follows who can decide: an undescribed step goes to whoever does it, so it is described before being touched; a case outside the standard is left to the manual route, not forced into the flow; a gain not found end to end is flagged before go-live; a step with no explanation is not automated, and that is all.
With a monthly summary: share of cases handled by the automated flow, share returned to manual and why, end-to-end time before and after, and steps still without a description.
Three operating rules, and they read as guarantees. A step where somebody decides is signed: I work it up in full — documents gathered, checks done, gap named — and the decision arrives ready, in seconds rather than minutes. The manual route stays open: an automated flow breaks down, and on that day somebody must still know how — the 40% of non-standard cases are routed to it at the first step, with their reason, rather than failing at the sixth. Nobody is measured, in time or in volume: a team that knows it is measured makes its informal steps disappear, and those are what stop 9 cases a week.
✎ Framework · no decision automated · the manual route stays open
What I do before any automation: I observe how it actually runs, I record the gaps with the procedure, I measure time end to end and not step by step, and I have every step whose reason I cannot see explained to me.
Routing follows who can decide: an undescribed step goes to whoever does it, so it is described before being touched; a case outside the standard is left to the manual route, not forced into the flow; a gain not found end to end is flagged before go-live; a step with no explanation is not automated, and that is all.
With a monthly summary: share of cases handled by the automated flow, share returned to manual and why, end-to-end time before and after, and steps still without a description.
Three operating rules, and they read as guarantees. A step where somebody decides is signed: I work it up in full — documents gathered, checks done, gap named — and the decision arrives ready, in seconds rather than minutes. The manual route stays open: an automated flow breaks down, and on that day somebody must still know how — the 40% of non-standard cases are routed to it at the first step, with their reason, rather than failing at the sixth. Nobody is measured, in time or in volume: a team that knows it is measured makes its informal steps disappear, and those are what stop 9 cases a week.
✎ Framework · no decision automated · the manual route stays open
Automating sixty per cent is already a lot, surely?
Yes — and it is the promise of "a hundred per cent" that makes these projects fail.
What I record: the case described as standard is 60% of the volume. The remaining 40% split into 17 variants, the most frequent weighing 6%. None is large enough to justify its own automation.
What automating everything produces: rules get written for rare cases, and each rule adds a condition nobody will be able to reread in two years. The flow becomes harder to change than the manual process it replaced.
What I propose: automate the 60%, and route the 40% explicitly to the manual channel — not let them fail inside the flow, take them out at the first step, with the reason.
Why that beats an exception handled at the end: a case that fails at step 6 has already consumed five steps, and somebody must undo what was done. A case taken out at step 1 is simply handled differently.
What I then measure: the composition of the 40%. If a variant grows it becomes a candidate; if it stays rare it stays manual. It is a figure to look at every quarter, not once. 60-percent_17-variants.pdfThe flow becomes harder to change than the process it replaced
⛓ Source · 60% standard, 17 variants, the most frequent at 6%
What I record: the case described as standard is 60% of the volume. The remaining 40% split into 17 variants, the most frequent weighing 6%. None is large enough to justify its own automation.
What automating everything produces: rules get written for rare cases, and each rule adds a condition nobody will be able to reread in two years. The flow becomes harder to change than the manual process it replaced.
What I propose: automate the 60%, and route the 40% explicitly to the manual channel — not let them fail inside the flow, take them out at the first step, with the reason.
Why that beats an exception handled at the end: a case that fails at step 6 has already consumed five steps, and somebody must undo what was done. A case taken out at step 1 is simply handled differently.
What I then measure: the composition of the 40%. If a variant grows it becomes a candidate; if it stays rare it stays manual. It is a figure to look at every quarter, not once. 60-percent_17-variants.pdfThe flow becomes harder to change than the process it replaced
⛓ Source · 60% standard, 17 variants, the most frequent at 6%
And the gain that vanishes end to end?
It does not vanish: it moves, and it was not being measured where it moved to.
What I record: the entry step falls from 6 minutes to 40 seconds. The gain is real and checkable. But the next step, checking, rises from 2 to 7 minutes — because the checker no longer trusts in the same way what they did not key in themselves.
What that gives end to end: a gain of 1 minute per case instead of the 5 announced. The per-step figure is accurate; it is simply partial.
Why checking lengthens, and it is rational: automatic entry carries no trace of the attention put into it. The checker rereads everything, because they do not know where the error might be — whereas rereading a colleague, they knew what to look at.
What I do: I supply the real error rate of automatic entry, by field type. Once established, checking becomes targeted: the time fell back to 3 minutes, and the end-to-end gain to 3.5 minutes.
The figure I do announce, and why that one: 3.5 minutes per case, measured end to end, once checking has settled — not the 5 minutes of the entry step alone. Announcing one step's gain as the process's gain is the commonest way of promising a figure that will never be found again, and it is the one that will be quoted back at you at the project review. 6-minutes-to-40-seconds_real-gain.pdfAutomatic entry carries no trace of the attention put into it
⛓ Source · entry 6 min → 40 s, checking 2 → 7 min, real gain 1 min then 3.5 min
What I record: the entry step falls from 6 minutes to 40 seconds. The gain is real and checkable. But the next step, checking, rises from 2 to 7 minutes — because the checker no longer trusts in the same way what they did not key in themselves.
What that gives end to end: a gain of 1 minute per case instead of the 5 announced. The per-step figure is accurate; it is simply partial.
Why checking lengthens, and it is rational: automatic entry carries no trace of the attention put into it. The checker rereads everything, because they do not know where the error might be — whereas rereading a colleague, they knew what to look at.
What I do: I supply the real error rate of automatic entry, by field type. Once established, checking becomes targeted: the time fell back to 3 minutes, and the end-to-end gain to 3.5 minutes.
The figure I do announce, and why that one: 3.5 minutes per case, measured end to end, once checking has settled — not the 5 minutes of the entry step alone. Announcing one step's gain as the process's gain is the commonest way of promising a figure that will never be found again, and it is the one that will be quoted back at you at the project review. 6-minutes-to-40-seconds_real-gain.pdfAutomatic entry carries no trace of the attention put into it
⛓ Source · entry 6 min → 40 s, checking 2 → 7 min, real gain 1 min then 3.5 min
What happens if the automated process breaks down?
On the first day, nothing. By the third, nobody knows how to do it by hand any more.
What I have seen elsewhere: a process automated for eighteen months. The three people who used to do it by hand had changed roles or tasks. At the breakdown it took four days to work out how to handle a case — and the written procedure was not enough, since it omitted the real steps.
What I do: I keep the manual route open, and I send a share of the cases through it, continuously. Not to test it: so that somebody keeps knowing how.
What it costs: a share of cases not automated — here, 5%, drawn at random, on ordinary cases. It is a real cost and it is insurance.
What I also do: the procedure is updated from the real process, informal steps included. A procedure describing the automated flow is of no use on the day it stops.
What I flag at every incident: what could not be handled, and what is waiting — never "the system is back up" alone. Recovery says nothing about the queue. 5-percent-manual_so-somebody-knows.pdfThe written procedure was not enough, it omitted the real steps
⛓ Source · 5% of cases kept manual, procedure aligned on the real process
What I have seen elsewhere: a process automated for eighteen months. The three people who used to do it by hand had changed roles or tasks. At the breakdown it took four days to work out how to handle a case — and the written procedure was not enough, since it omitted the real steps.
What I do: I keep the manual route open, and I send a share of the cases through it, continuously. Not to test it: so that somebody keeps knowing how.
What it costs: a share of cases not automated — here, 5%, drawn at random, on ordinary cases. It is a real cost and it is insurance.
What I also do: the procedure is updated from the real process, informal steps included. A procedure describing the automated flow is of no use on the day it stops.
What I flag at every incident: what could not be handled, and what is waiting — never "the system is back up" alone. Recovery says nothing about the queue. 5-percent-manual_so-somebody-knows.pdfThe written procedure was not enough, it omitted the real steps
⛓ Source · 5% of cases kept manual, procedure aligned on the real process
Can you automate the approvals to go faster?
I build the whole approval; the signature remains.
What that signature covers, and it alone: approving a case, crossing a commitment threshold, deciding an exception, or applying a rule whose interpretation varies by case.
Why the last is the most insidious: many rules look mechanical and are not. "Above this amount, the manager approves" is mechanical; "if the customer is a long-standing partner, we can be flexible" is not — and the second is written in the same documents as the first.
What I do: I prepare the complete case, with what is missing and what has been checked, and I put it to whoever decides. Across 4,200 cases observed, preparation is 80% of the time and the decision 20%. It is the 80% I automate.
What I do flag: approvals granted in 99% of cases without ever being discussed. There are three. Those are not decisions, they are formalities — and it is for the company to choose whether to remove them, not for me to automate them quietly. 80-percent-preparation_3-formalities.pdfMany rules look mechanical and are not
✎ Framework · no approval, no exception decided · 80% of preparation automated
What that signature covers, and it alone: approving a case, crossing a commitment threshold, deciding an exception, or applying a rule whose interpretation varies by case.
Why the last is the most insidious: many rules look mechanical and are not. "Above this amount, the manager approves" is mechanical; "if the customer is a long-standing partner, we can be flexible" is not — and the second is written in the same documents as the first.
What I do: I prepare the complete case, with what is missing and what has been checked, and I put it to whoever decides. Across 4,200 cases observed, preparation is 80% of the time and the decision 20%. It is the 80% I automate.
What I do flag: approvals granted in 99% of cases without ever being discussed. There are three. Those are not decisions, they are formalities — and it is for the company to choose whether to remove them, not for me to automate them quietly. 80-percent-preparation_3-formalities.pdfMany rules look mechanical and are not
✎ Framework · no approval, no exception decided · 80% of preparation automated
Observing the process shows who is slow. Do you use that?
It does allow it, and it is your decision — but be warned: that decision determines whether observation keeps working at all.
What I deliver if you open it: the prior information notice (art. L1222-4), the works council consultation file, a proportionate scope.
What observation returned, and it depends entirely on trust: 41 % of cases go through a step that appears in no procedure. Somebody has been doing it for years, and it is the reason the process works. It was shown to me because nobody was being measured.
What happens if observation becomes an individual measure: the useful workarounds stop being shown. They do not disappear — they become invisible again, and the automation is then built on the written procedure, the one describing 60 % of cases.
What I propose: measuring by step and by case type, never by person. That is what revealed that the gain does not disappear: it moves — data entry drops from 6 minutes to 40 seconds, and the time reappears downstream, where nobody was measuring. observing-without-measuring-people.pdfWhat opens · what trust returned · the measure proposed
⛓ Source · French DPA, art. L1222-4 · 41 % of cases through an unwritten step, gain moved downstream
What I deliver if you open it: the prior information notice (art. L1222-4), the works council consultation file, a proportionate scope.
What observation returned, and it depends entirely on trust: 41 % of cases go through a step that appears in no procedure. Somebody has been doing it for years, and it is the reason the process works. It was shown to me because nobody was being measured.
What happens if observation becomes an individual measure: the useful workarounds stop being shown. They do not disappear — they become invisible again, and the automation is then built on the written procedure, the one describing 60 % of cases.
What I propose: measuring by step and by case type, never by person. That is what revealed that the gain does not disappear: it moves — data entry drops from 6 minutes to 40 seconds, and the time reappears downstream, where nobody was measuring. observing-without-measuring-people.pdfWhat opens · what trust returned · the measure proposed
⛓ Source · French DPA, art. L1222-4 · 41 % of cases through an unwritten step, gain moved downstream
What do you keep?
The description of the real process — and the means to go back, which nobody plans for.
What is kept: the real process as observed, gaps with the procedure included, times by step and case type, the exceptions and their share, the automations in place and the matching manual procedure, and the flow stoppages.
Why the manual procedure is kept current: I have observed elsewhere a process automated for eighteen months then interrupted. On day one, nothing. On day three, nobody knew how to do it by hand any more. The procedure existed — it described the state before automation.
What I still refuse to automate: anything I have not understood. The case described as standard covers 60 % of files, not a hundred. It is the promise of "one hundred per cent" that makes these projects fail — the remaining 40 % come back as exceptions handled by hand, with no procedure, by the same people.
What is left to the signature, and the log keeps the trace of it: approving a file, crossing a commitment threshold. I build the complete approval — documents checked, gaps named, rule quoted — and it is signed with one action. Across 4,200 files: 4,200 approvals built, 0 granted without a name. what-you-keep_process-automation.pdf5 items kept · the manual procedure, kept current for day three
⛓ Source · 60 % standard cases, manual procedure kept current, gain measured end to end
What is kept: the real process as observed, gaps with the procedure included, times by step and case type, the exceptions and their share, the automations in place and the matching manual procedure, and the flow stoppages.
Why the manual procedure is kept current: I have observed elsewhere a process automated for eighteen months then interrupted. On day one, nothing. On day three, nobody knew how to do it by hand any more. The procedure existed — it described the state before automation.
What I still refuse to automate: anything I have not understood. The case described as standard covers 60 % of files, not a hundred. It is the promise of "one hundred per cent" that makes these projects fail — the remaining 40 % come back as exceptions handled by hand, with no procedure, by the same people.
What is left to the signature, and the log keeps the trace of it: approving a file, crossing a commitment threshold. I build the complete approval — documents checked, gaps named, rule quoted — and it is signed with one action. Across 4,200 files: 4,200 approvals built, 0 granted without a name. what-you-keep_process-automation.pdf5 items kept · the manual procedure, kept current for day three
⛓ Source · 60 % standard cases, manual procedure kept current, gain measured end to end
And once it really runs: how does the data move from one tool to the next, and where does it go?
Two answers: the flow between systems is visible, and the base stays with you.
Flow between systems as it stands today: a case crosses four systems — the request starts in the portal, is documented in the document management system, is approved in the budget tool, is closed in the ERP. I followed 1,260 cases over three months: 3 of the 4 hand-offs are done manually, by screenshot and re-keying, and that circulation costs 21 minutes per case. I read in the upstream system, pass to the next and prepare the step with its documents and its recipient; what remains are your approval points, and I stop at them.
The case status follows the flow: at any moment, each case carries the system it sits in, the date it entered that step and what it is waiting for. The 41 % of cases that go through the off-procedure step appear there as such instead of vanishing into it.
The base is sovereign AI, and that is verifiable: inference runs on your machine; no case content leaves your network; access to each of the four systems is granted by role, traced, withdrawable in one minute; the model can be replaced without your data moving. Sovereign orchestration is recognised by this: cutting the link to the outside does not stop it. We tested it on the 12th of last month — link cut for 3 hours, 214 cases processed anyway.
The figure that does not flatter me: across the 1,260 cases, the flow stopped 34 times — 2.7 % — of which 29 times on the same hand-off, the one into the budget tool, which refuses an amount without a budget code. I was reading a missing code as an empty field; it is a refusal. I now prepare the code from the original commitment, and where it is genuinely missing I stop before sending rather than after: the case stays readable in the upstream system instead of being stuck between two. Over the next 400 cases, 3 stops, all handed back in the right place.
⛓ Sourced · 1,260 cases followed, 21 min of circulation per case, 3 h with no outside link
Flow between systems as it stands today: a case crosses four systems — the request starts in the portal, is documented in the document management system, is approved in the budget tool, is closed in the ERP. I followed 1,260 cases over three months: 3 of the 4 hand-offs are done manually, by screenshot and re-keying, and that circulation costs 21 minutes per case. I read in the upstream system, pass to the next and prepare the step with its documents and its recipient; what remains are your approval points, and I stop at them.
The case status follows the flow: at any moment, each case carries the system it sits in, the date it entered that step and what it is waiting for. The 41 % of cases that go through the off-procedure step appear there as such instead of vanishing into it.
The base is sovereign AI, and that is verifiable: inference runs on your machine; no case content leaves your network; access to each of the four systems is granted by role, traced, withdrawable in one minute; the model can be replaced without your data moving. Sovereign orchestration is recognised by this: cutting the link to the outside does not stop it. We tested it on the 12th of last month — link cut for 3 hours, 214 cases processed anyway.
The figure that does not flatter me: across the 1,260 cases, the flow stopped 34 times — 2.7 % — of which 29 times on the same hand-off, the one into the budget tool, which refuses an amount without a budget code. I was reading a missing code as an empty field; it is a refusal. I now prepare the code from the original commitment, and where it is genuinely missing I stop before sending rather than after: the case stays readable in the upstream system instead of being stuck between two. Over the next 400 cases, 3 stops, all handed back in the right place.
⛓ Sourced · 1,260 cases followed, 21 min of circulation per case, 3 h with no outside link
Local inference · no data outside the EU
Your case is not here? That is exactly what a 15-minute conversation is for. Book the free audit →
Use cases
What does the agent actually do?
One orchestration, several processes. All these uses work in support, subject to your approval.
Included in your agent
The 4 capabilities essential to this promise are included, at no extra cost.
From 766 € excl. VAT / month
Moving between systems
Reads, passes on and prepares each step from one system to the next.
State of the case kept up to date
Keeps track of progress with the source system and timestamp of every step.
Approval points
Stops where you decided it should, with the case assembled and its sources to hand.
Sovereign AI
The hosting and confidentiality foundation the orchestration rests on.
Controls and safeguards
These 2 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Status, safe closure and audit trail
Explain alerts, scenarios and operational trade-offs
What the agent must be connected to
These 2 connections are required for the agent to work. They concern your information system and are scoped during the audit.
Connect ERP/WMS/MES/IoT without creating double entry
Honour constraints, statuses, approvals and error recovery
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How long does a case spend waiting between two steps?
By taking on the crossings between systems, the effort shifts towards the decisions that really move the case forward. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Moving from one system to another
Keeping the state of the case
Assembling the approval file
Indicative figures, not contractual, to be confirmed by a pilot on the number of processes and systems crossed. Committing steps stop at the approval points you have placed: the orchestration prepares, your organisation decides.
How it works
The stages of your AI agent project
1
Audit & scoping
15 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
Pricing
One package, one agent
A process orchestration (movement, state, approval points), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the gains to settle in for good.
Agility
Setup + controlled subscription
10,775 € excl. VAT setup
then 766 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Sovereign hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
1,366 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
14,825 € excl. VAT setup
then 967 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your processes
The data that moves around stays with youLocal inference or an isolated resource hosted in France; no process data entrusted to a third party, no data used to train a model.
Data in France, under French lawThe data moving from one system to another: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The business department keeps the decisionThe agent produces processes orchestrated from end to end, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn the number of processes and systems crossed: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Can the orchestration decide on its own?
Not at committing steps: it assembles the case and stops at the approval points you have placed. Purely technical crossings, on the other hand, follow one another without intervention.
What does it do with a missing document?
It leaves the case pending at the step concerned and prepares the request for the document. A missing document is never filled in by inference.
How is a case tracked?
Every step keeps its source system and its timestamp, which makes it possible to reconstruct a case's full journey at any time.
Which systems can it cross?
The common tools on the market and your business applications, according to the integrations designed with your teams during the design phase.
Where is the data hosted?
In France, on local inference or an isolated resource, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
How long does it take to deploy an orchestration?
Several months as a rule, depending on the number of processes and systems crossed, after a free audit then phases of design, integration and testing.
Related use cases
Going further
Let's talk
Let's size up the potential across your processes
15 minutes to frame your processes and your systems — hosted in France, supervised, with no commitment.