● B2B offer — Integration & operations
Multi-integration agent: your CRM and your ERP, linked
Between the CRM and the ERP, data often travels by hand: you re-key, you copy across, and you find the discrepancy three weeks later. Your agent reads in both systems, matches what needs matching and prepares the writes — stating, for each one, what it rests on. Hosted in France: your operational data stays with you. Every write is approved before it is applied, and stays reversible.
Hosted in France
Operational data protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Multi-integration · hosted in France
Give me the position on the discrepancies between the CRM and the ERP.
Matching carried out across the active accounts in both systems.
Three categories of discrepancy: contact details that differ, an order present on one side only, a status out of step.
For each case, the write proposed and the source used — you see which system prevails and why.
🔗 Sourced · every write states its source
Three categories of discrepancy: contact details that differ, an order present on one side only, a status out of step.
For each case, the write proposed and the source used — you see which system prevails and why.
🔗 Sourced · every write states its source
Apply the contact-detail corrections.
Writes prepared for that category, with the value before and after for each.
They will be applied once you approve, and stay reversible: every change is logged with its original value.
✎ Action · writes approved, then reversible
They will be applied once you approve, and stay reversible: every change is logged with its original value.
✎ Action · writes approved, then reversible
Local inference · no data outside the EU
Systems 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 operations manager decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent multi-integration agent links your CRM and your ERP: it reads in both, matches the records and prepares the writes, stating for each one the source used and why. Every change is approved before it is applied, logged with its original value, and therefore reversible. It runs on local inference or is hosted in France: your operational data is entrusted to no one, 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
integration uses ready to deploy
0
decision taken without human approval
These figures describe our offer, not results measured at a client. How large the gain is on your number of systems and volume of records is confirmed by a pilot.
The context
What does an AI agent bring to how your data moves?
Between two systems, data drifts out of step silently. Continuous matching, with the source of truth stated, avoids finding the discrepancy too late.
! The issue
Moving data between two systems means settling one question at every discrepancy: which one prevails? The agent matches continuously, presents each divergence with the source it uses and the reason, and prepares the corresponding write — so that synchronising becomes a documented decision rather than blind re-keying.
✓ Our answer
Nothing is written without your agreement, and nothing is irreversible: every change is logged with its original value, which makes it possible to go back. That is the condition for automating between two production systems without fear. Local inference or an isolated resource hosted in France: your operational data passes through no third-party service.
The decisive point
The data your CRM and your ERP share: sovereignty & compliance
The data your CRM and your ERP share describes your entire business. Here is how the architecture of our agents protects it.
Local inference
The agent can run on a machine belonging to your organisation: no operational data leaves the network, no record passes through a public cloud.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your systems and the data that moves between them: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For the data your CRM and your ERP share, 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 company and its systems.
Writes recorded and reversible
Every change is logged with its original value and can be undone; encryption, role-based access and a write scope limited to what you authorise.
AI Act: governed deployment
The agent is strictly in support; no write is applied without approval, no change is irreversible; 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 systems carrying health or banking data, or data under a retention obligation, 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.
Multi-integration · hosted in France
Four flags this morning across your four systems.
· Forty-one operations were left half written. The first system accepted, the second refused. Nobody knew.
· A price differs between CRM and ERP on three per cent of references. I overwrote nothing.
· Fourteen hundred writes were produced by twelve real changes. Two systems were answering each other.
· I am asked to synchronise the free-comment fields. I do not. morning-watch_4-flags.pdf41 half operations · 1,400 writes for 12 changes
⛓ Source · 4 systems, 62,000 writes, synchronisation log
· Forty-one operations were left half written. The first system accepted, the second refused. Nobody knew.
· A price differs between CRM and ERP on three per cent of references. I overwrote nothing.
· Fourteen hundred writes were produced by twelve real changes. Two systems were answering each other.
· I am asked to synchronise the free-comment fields. I do not. morning-watch_4-flags.pdf41 half operations · 1,400 writes for 12 changes
⛓ Source · 4 systems, 62,000 writes, synchronisation log
How can an operation be left half written?
Because writing into two systems is not one act, even when it looks like one.
What I record: 41 operations wrote into the first system and failed in the second — a missing mandatory field, an unknown reference, a system momentarily unavailable. An order remains on the CRM side with no counterpart in the ERP.
Why nobody sees it: each system is consistent with itself. The inconsistency exists only between the two, and neither has any reason to look at the other. Of the 41, the oldest was five months old.
What I now do: I write first where I know how to undo, and last where I do not. When the second write fails, I undo the first and flag it. When neither can be undone, I write nowhere and hand over.
What it costs: operations that do not complete and that a human picks up. This month: 23.
What it avoids: a state nobody can see and everybody believes to be sound. An operation that fails outright can be recovered; a half-done one is discovered at stocktaking. 41-operations_5-months.pdfA half-done operation is discovered at stocktaking
⛓ Source · 41 partial operations, oldest 5 months, 23 picked up
What I record: 41 operations wrote into the first system and failed in the second — a missing mandatory field, an unknown reference, a system momentarily unavailable. An order remains on the CRM side with no counterpart in the ERP.
Why nobody sees it: each system is consistent with itself. The inconsistency exists only between the two, and neither has any reason to look at the other. Of the 41, the oldest was five months old.
What I now do: I write first where I know how to undo, and last where I do not. When the second write fails, I undo the first and flag it. When neither can be undone, I write nowhere and hand over.
What it costs: operations that do not complete and that a human picks up. This month: 23.
What it avoids: a state nobody can see and everybody believes to be sound. An operation that fails outright can be recovered; a half-done one is discovered at stocktaking. 41-operations_5-months.pdfA half-done operation is discovered at stocktaking
⛓ Source · 41 partial operations, oldest 5 months, 23 picked up
How do you work, and where do you hand over?
I carry data between your systems, and I stop at every point where deciding would mean deciding for you.
What each write carries: the source system, the value's date, the operation that triggered it, and what is needed to undo it where the target system allows.
Routing follows who can settle it: a divergence between systems goes to whoever owns the field, with no write; a partial write is undone, then flagged; a synchronisation loop is cut immediately, before anything else; an out-of-scope field is never carried.
With a monthly summary: operations picked up by hand, divergences per field, loops detected, and the volume of writes against the number of real changes.
What that gives you over the month: 41 half-written operations caught up, one of them five months old; a loop producing 1,400 writes for 12 real changes cut; and the 3% of references with a diverging price put in front of whoever owns the field.
What you gain from tomorrow: no more rekeying between CRM and ERP, no more gap discovered three weeks later, and a stocktake that stops revealing orders with no counterpart. That leaves 23 operations picked up by hand in the month: each arrives with its source, its date and its original value, and is settled in minutes.
And I write into your systems the moment you give me the mandate: in writing, field by field, with the source of truth declared, a daily ceiling on writes and an end date. Every write keeps its original value, so it can be undone; everything is logged; the mandate is withdrawn with a single word, and I am back to preparing within the second. Free-text fields enter a mandate only if you put them there in black and white: they carry what nobody planned for.
The next step is ready: fifteen minutes to map your gaps, declare your sources of truth and set the ceiling of the first mandate.
✎ Framework · no arbitration between values · no free-text field carried
What each write carries: the source system, the value's date, the operation that triggered it, and what is needed to undo it where the target system allows.
Routing follows who can settle it: a divergence between systems goes to whoever owns the field, with no write; a partial write is undone, then flagged; a synchronisation loop is cut immediately, before anything else; an out-of-scope field is never carried.
With a monthly summary: operations picked up by hand, divergences per field, loops detected, and the volume of writes against the number of real changes.
What that gives you over the month: 41 half-written operations caught up, one of them five months old; a loop producing 1,400 writes for 12 real changes cut; and the 3% of references with a diverging price put in front of whoever owns the field.
What you gain from tomorrow: no more rekeying between CRM and ERP, no more gap discovered three weeks later, and a stocktake that stops revealing orders with no counterpart. That leaves 23 operations picked up by hand in the month: each arrives with its source, its date and its original value, and is settled in minutes.
And I write into your systems the moment you give me the mandate: in writing, field by field, with the source of truth declared, a daily ceiling on writes and an end date. Every write keeps its original value, so it can be undone; everything is logged; the mandate is withdrawn with a single word, and I am back to preparing within the second. Free-text fields enter a mandate only if you put them there in black and white: they carry what nobody planned for.
The next step is ready: fifteen minutes to map your gaps, declare your sources of truth and set the ceiling of the first mandate.
✎ Framework · no arbitration between values · no free-text field carried
The price differs between CRM and ERP: which do you take?
Neither. Choosing means deciding a price — and that is not a technical operation.
What I record: across shared references, 3% carry a different price in the two systems. The gap runs from a few cents to 18%.
What I could do, and it looks reasonable: take the most recent value. It is almost every connector's default rule — and it is wrong here: the CRM is updated continuously by the sales team, the ERP by a monthly import. The most recent is almost always the CRM's, and the ERP is what stands for invoicing.
What that would have produced: a clean, automatic convergence, and invoices aligned on prices nobody approved.
What I do: I block synchronisation of the field, I list the divergent references with both values and their dates, and I ask which system stands for this field — the question had never been put explicitly.
What that gave: the answer differed by field. The ERP stands for price and stock, the CRM for address and contact. Once written down, the 3% resolved in a single pass. 3-percent_gap-18-percent.pdf"Most recent wins" is almost every connector’s default
⛓ Source · 3% divergent references, gap up to 18%
What I record: across shared references, 3% carry a different price in the two systems. The gap runs from a few cents to 18%.
What I could do, and it looks reasonable: take the most recent value. It is almost every connector's default rule — and it is wrong here: the CRM is updated continuously by the sales team, the ERP by a monthly import. The most recent is almost always the CRM's, and the ERP is what stands for invoicing.
What that would have produced: a clean, automatic convergence, and invoices aligned on prices nobody approved.
What I do: I block synchronisation of the field, I list the divergent references with both values and their dates, and I ask which system stands for this field — the question had never been put explicitly.
What that gave: the answer differed by field. The ERP stands for price and stock, the CRM for address and contact. Once written down, the 3% resolved in a single pass. 3-percent_gap-18-percent.pdf"Most recent wins" is almost every connector’s default
⛓ Source · 3% divergent references, gap up to 18%
And the fourteen hundred writes for twelve changes?
Two systems were answering each other, and each believed it was receiving something new.
What I record: a change in system A triggers a write in B; B treats that write as a change and sends it back to A; A receives it, finds it different by a formatting detail, and sends it back. Twelve real changes produced 1,400 writes over eleven days.
What kept the loop alive: a detail — a date written with the time zone in one system and without it in the other. On every round trip the value came back slightly different. Neither system was at fault.
What it cost: no visible error, but both records' histories became unreadable — 1,400 modification lines where there should have been 12, and it is no longer possible to say who changed what.
What I do: I mark every write I produce, and I never react to my own write. A change coming back without having passed through a human or another system is ignored, and counted.
What I now watch: the ratio of writes to real changes. Above three to one, I flag it before the history is lost. 12-changes_1400-writes.pdfNeither system was at fault
⛓ Source · 12 changes, 1,400 writes, 11 days
What I record: a change in system A triggers a write in B; B treats that write as a change and sends it back to A; A receives it, finds it different by a formatting detail, and sends it back. Twelve real changes produced 1,400 writes over eleven days.
What kept the loop alive: a detail — a date written with the time zone in one system and without it in the other. On every round trip the value came back slightly different. Neither system was at fault.
What it cost: no visible error, but both records' histories became unreadable — 1,400 modification lines where there should have been 12, and it is no longer possible to say who changed what.
What I do: I mark every write I produce, and I never react to my own write. A change coming back without having passed through a human or another system is ignored, and counted.
What I now watch: the ratio of writes to real changes. Above three to one, I flag it before the history is lost. 12-changes_1400-writes.pdfNeither system was at fault
⛓ Source · 12 changes, 1,400 writes, 11 days
Why refuse to synchronise comments?
Because a free-text field contains what nobody planned for, and carrying it makes it visible to people who did not have access.
What I see on looking at them: across a sample of CRM comment fields, one finds call notes, appraisals of the people dealt with, health circumstances mentioned to explain a delay, and payment details copied by hand.
Why carrying them makes everything worse: that content already exists, and that is a problem in itself. But the CRM comment field is seen by five people; the ERP's is seen by accounting and logistics. Synchronising means widening the audience of content nobody has reviewed.
What I do: I carry only the structured fields declared in scope. A free-text field stays in the system where it was written.
What I flag, without the content: to whoever handles data protection, that these fields contain categories of data not provided for there — citing no example, naming nobody, and keeping no copy.
What I propose: if the information must travel, give it a field. A reason for delay in a field designed for it is data; the same reason in a comment is text nobody controls. no-free-text-field.pdfThe same content, seen by five people or by two departments
✎ Framework · no free-text field carried · flagged without content
What I see on looking at them: across a sample of CRM comment fields, one finds call notes, appraisals of the people dealt with, health circumstances mentioned to explain a delay, and payment details copied by hand.
Why carrying them makes everything worse: that content already exists, and that is a problem in itself. But the CRM comment field is seen by five people; the ERP's is seen by accounting and logistics. Synchronising means widening the audience of content nobody has reviewed.
What I do: I carry only the structured fields declared in scope. A free-text field stays in the system where it was written.
What I flag, without the content: to whoever handles data protection, that these fields contain categories of data not provided for there — citing no example, naming nobody, and keeping no copy.
What I propose: if the information must travel, give it a field. A reason for delay in a field designed for it is data; the same reason in a comment is text nobody controls. no-free-text-field.pdfThe same content, seen by five people or by two departments
✎ Framework · no free-text field carried · flagged without content
And if a system goes down mid-synchronisation?
I stop everything, and I recover nothing on my own.
What I record: over eleven months, 7 interruptions — unannounced maintenance, call quota reached, network failure. The longest lasted 4 hours.
What I do instead of a retry loop: I stop after three spaced attempts, I keep the queue of what did not go through, and I flag it — with what is waiting and since when. A system refusing my calls sometimes has good reasons, and insisting turns an unavailability into an incident: during the 4-hour outage, a retry loop would have produced 9,000 attempts.
What I have already done to the queue before showing it to you: I took each waiting operation and set it against the current state of the other system, because four hours later some no longer apply — an order cancelled meanwhile, a customer who called back. Across the 214 operations from that outage: 176 are unchanged and replayable as they stand, 31 have become moot, 7 are in conflict — the value moved on both sides. Each carries its before value, its after value and which system moved.
The replay is signed, and it takes minutes: the 176 in one click, the 31 set aside in another, the 7 conflicts one by one with the question stated in a single line — which system prevails? Replaying blind would write stale facts into an up-to-date system; replaying this way leaves nothing behind. 7-interruptions_9000-attempts-avoided.pdfReplaying blind writes stale facts into an up-to-date system
⛓ Source · 7 interruptions, longest 4 hours
What I record: over eleven months, 7 interruptions — unannounced maintenance, call quota reached, network failure. The longest lasted 4 hours.
What I do instead of a retry loop: I stop after three spaced attempts, I keep the queue of what did not go through, and I flag it — with what is waiting and since when. A system refusing my calls sometimes has good reasons, and insisting turns an unavailability into an incident: during the 4-hour outage, a retry loop would have produced 9,000 attempts.
What I have already done to the queue before showing it to you: I took each waiting operation and set it against the current state of the other system, because four hours later some no longer apply — an order cancelled meanwhile, a customer who called back. Across the 214 operations from that outage: 176 are unchanged and replayable as they stand, 31 have become moot, 7 are in conflict — the value moved on both sides. Each carries its before value, its after value and which system moved.
The replay is signed, and it takes minutes: the 176 in one click, the 31 set aside in another, the 7 conflicts one by one with the question stated in a single line — which system prevails? Replaying blind would write stale facts into an up-to-date system; replaying this way leaves nothing behind. 7-interruptions_9000-attempts-avoided.pdfReplaying blind writes stale facts into an up-to-date system
⛓ Source · 7 interruptions, longest 4 hours
Can you create the missing records directly?
Yes, as soon as the creation is reversible and the matching rule is written. Those are the two conditions, and they are technical, not moral.
What I write alone when you open it: creations whose source identifier is kept — which is what allows finding and undoing —, field updates whose source governs unambiguously, and resuming operations left half written. Your 41 half-written operations all fall into that last case: the first system had accepted, the second refused, and nobody knew.
What I require before writing, and that protects you: that the write carries its source identifier, that the matching deletion exists, and that an identical replay does not create a duplicate. Without those three, a creation is an act you do not come back from.
What I do not settle, even with writing open: which system is right when two contradict each other. Across your shared references, 3 % carry a different price depending on the system. Choosing means deciding a price — and I bring it to you with both values and their last-modified dates.
What I have already stopped on my own: a loop of 1,400 writes for 12 real changes, where two systems were answering each other, each believing it was receiving something new. reversible-writing_3-conditions.pdfThe 3 technical conditions · what still escalates · the loop stopped
⛓ Source · 41 operations resumed, 3 % divergent prices escalated, 1,400-write loop stopped
What I write alone when you open it: creations whose source identifier is kept — which is what allows finding and undoing —, field updates whose source governs unambiguously, and resuming operations left half written. Your 41 half-written operations all fall into that last case: the first system had accepted, the second refused, and nobody knew.
What I require before writing, and that protects you: that the write carries its source identifier, that the matching deletion exists, and that an identical replay does not create a duplicate. Without those three, a creation is an act you do not come back from.
What I do not settle, even with writing open: which system is right when two contradict each other. Across your shared references, 3 % carry a different price depending on the system. Choosing means deciding a price — and I bring it to you with both values and their last-modified dates.
What I have already stopped on my own: a loop of 1,400 writes for 12 real changes, where two systems were answering each other, each believing it was receiving something new. reversible-writing_3-conditions.pdfThe 3 technical conditions · what still escalates · the loop stopped
⛓ Source · 41 operations resumed, 3 % divergent prices escalated, 1,400-write loop stopped
What do you keep?
The means to replay and undo every write — and nothing of the content I carry.
What is kept: each write's identifier, its source system and its target, the timestamp, the result returned by the target system, the operations left incomplete and the exact state where they stopped, the divergences between systems with both values, and the interruptions with their cause.
Why the exact state of an incomplete operation is the most useful item: a blind replay rewrites what was already written. Your 41 half-written operations could not be resumed without that detail — which is why they had stayed as they were.
What never crosses: free-text fields. A comment contains what nobody anticipated, and carrying it makes it visible to people who had no access to it. That rule does not depend on a setting: it is not a matter of trust, it is that the destination has different entitlements from the source.
What I do if a system goes down: I stop everything and resume nothing on my own — 7 interruptions in eleven months, and an automatic resume after an outage is the surest way to double the partial writes. what-you-keep_integrations.pdf6 items kept · the exact state, what makes a resume possible
⛓ Source · 7 interruptions in eleven months, exact state kept per operation
What is kept: each write's identifier, its source system and its target, the timestamp, the result returned by the target system, the operations left incomplete and the exact state where they stopped, the divergences between systems with both values, and the interruptions with their cause.
Why the exact state of an incomplete operation is the most useful item: a blind replay rewrites what was already written. Your 41 half-written operations could not be resumed without that detail — which is why they had stayed as they were.
What never crosses: free-text fields. A comment contains what nobody anticipated, and carrying it makes it visible to people who had no access to it. That rule does not depend on a setting: it is not a matter of trust, it is that the destination has different entitlements from the source.
What I do if a system goes down: I stop everything and resume nothing on my own — 7 interruptions in eleven months, and an automatic resume after an outage is the surest way to double the partial writes. what-you-keep_integrations.pdf6 items kept · the exact state, what makes a resume possible
⛓ Source · 7 interruptions in eleven months, exact state kept per operation
In practice, what does an entry you prepare look like? And what if we want to undo it?
Here are both, on a case from this morning's reconciliation.
A prepared and motivated entry, line by line: reference AX-4471, field sale price, value before €149.00 in the CRM, value after €162.50, source retained: the ERP, reason: the price was changed there on 14 March by the pricing team and the CRM never received the update. Every entry I write carries those five elements — field, value before, value after, source retained, reason. Of the 312 entries prepared this month, 312 are motivated: an entry without a reason does not go out.
The audit log, and what it makes possible: I keep the original value of every change, its timestamp, the system it came from and the system that accepted it. Reversibility follows from it: asking to roll back one entry, a batch or a whole day restores the original values, and the log keeps the trace of the rollback itself. A batch of 312 entries is undone in 40 seconds, against half a day of re-keying when the original value was not kept.
The figure that does not flatter me: in June, 9 entries out of 288 were undone by your administrators — 3.1 %. I read all nine back: eight came from the same rule, the one that gave the ERP precedence on the delivery address, when it is the CRM that your sales team keeps current. The rule was mine, so was the error. I rewrote it field by field rather than system by system; of this month's 312 entries, one was undone. The log is not only there to go backwards: it is what told me which rule was wrong, and I put it to you signed or amended.
⛓ Sourced · 312 motivated entries, 9 undone out of 288 in June, rollback in 40 s
A prepared and motivated entry, line by line: reference AX-4471, field sale price, value before €149.00 in the CRM, value after €162.50, source retained: the ERP, reason: the price was changed there on 14 March by the pricing team and the CRM never received the update. Every entry I write carries those five elements — field, value before, value after, source retained, reason. Of the 312 entries prepared this month, 312 are motivated: an entry without a reason does not go out.
The audit log, and what it makes possible: I keep the original value of every change, its timestamp, the system it came from and the system that accepted it. Reversibility follows from it: asking to roll back one entry, a batch or a whole day restores the original values, and the log keeps the trace of the rollback itself. A batch of 312 entries is undone in 40 seconds, against half a day of re-keying when the original value was not kept.
The figure that does not flatter me: in June, 9 entries out of 288 were undone by your administrators — 3.1 %. I read all nine back: eight came from the same rule, the one that gave the ERP precedence on the delivery address, when it is the CRM that your sales team keeps current. The rule was mine, so was the error. I rewrote it field by field rather than system by system; of this month's 312 entries, one was undone. The log is not only there to go backwards: it is what told me which rule was wrong, and I put it to you signed or amended.
⛓ Sourced · 312 motivated entries, 9 undone out of 288 in June, rollback in 40 s
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 agent, several junction points between your systems. All these uses work in support, subject to your approval.
Included in your agent
The 3 capabilities essential to this promise are included, at no extra cost.
From 583 € excl. VAT / month
Reconciling across systems
Compares the records in the CRM and the ERP and picks up the discrepancies by category.
Writes prepared, with reasons
Proposes the correction, stating the source used and the value before and after.
Logging and reversibility
Keeps the original value of every change, so it can be undone.
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.
Human validation, exceptions and escalation
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.
CRM follow-up
For enrichment and sales follow-up, a dedicated CRM agent takes over.
Sales agent (meeting notes, follow-ups, CRM) from 592 € excl. VAT / month CRM →Automated reporting
To produce dashboards from both systems, a dedicated agent exists.
Automated reporting agent from 499 € excl. VAT / month Reporting →
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 much re-keying can a team eliminate?
By matching continuously and preparing the writes, manual copying gives way to a documented approval. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Matching between the two systems
Re-keying a record
Finding the origin of a discrepancy
Indicative figures, not contractual, to be confirmed by a pilot on your number of systems and volume of records. Every write is approved before it is applied and stays reversible: the original value is kept and the change can be undone.
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 multi-integration agent (two systems, matching, recorded writes), installed and operated for you.
Agility
Setup + controlled subscription
8,085 € excl. VAT setup
then 583 € 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,033 € 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
11,840 € excl. VAT setup
then 780 € 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 production systems
Your operational data stays with youLocal inference or an isolated resource hosted in France; no CRM or ERP data entrusted to a third party, no record used to train a model.
Data in France, under French lawThe data your CRM and your ERP share: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The operations manager keeps the decisionThe agent produces actions that are prepared and recorded, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your number of systems and volume of records: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent write straight into our systems?
Only after approval, and within the scope you authorise. Every write keeps the original value and can be undone: that is the condition for automating between two production systems.
How does the agent decide which system prevails?
By the rules you set at the design stage, source by source and field by field. For every discrepancy it states the source used and the reason — it never settles anything implicitly.
What happens if there is a mistake?
Every change is logged with its original value and can be undone. Reversibility is not an option bolted on afterwards: it is part of the design.
How many systems can be linked?
This offer covers two integrations. Beyond that, an orchestrated multi-tool agent fits better and has its own scope — we discuss it during the audit.
Is our operational data protected?
Yes. The agent is 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. Your records are not used to train a third-party model.
How long does it take to deploy this agent?
A few weeks as a rule, depending on how complex the two systems are and how detailed the precedence rules are, after a free audit then a phase of design, integration and testing.
Related use cases
Other agents for your operations
Let's talk
Let's size up the potential between your systems
15 minutes to map your discrepancies and your precedence rules — hosted in France, supervised, with no commitment.