We build Agents. You build the Future.
● B2B offer — Integration & operationsMulti-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. Data hosted in France; the AI model is called at its publisher, except with the Sovereign model option. With the 100% Sovereign package, your operational data stays with you. The agent applies by itself the changes you authorise it to make and submits the others to you; every write stays reversible.
Updated on
Fictional simulation — not a client result
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
I submit them for your approval, except for the categories you have authorised me to apply by myself; they stay reversible: every change is logged with its original value.
✎ Action · writes approved, then reversible
For an organisation established outside the European Union, the law of its own country applies; at its request, we put equivalent safeguards in place (human review before any action, a log of the criteria, information for the people concerned).
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. It applies by itself the changes you authorise it to make and submits the others; every change is 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.
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.
Indicative estimate, to be confirmed by a pilot on your real files (general terms of sale, article 4).
One package, one agent
A multi-integration agent (two systems, matching, recorded writes), installed and operated for you.
Setup + controlled subscription
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Hosting in France, a dedicated and isolated resource
All inclusive, no setup fee
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Hosting in France, managed end to end
On site, you own it
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
What does the agent actually do?
One agent, several junction points between your systems, with links to neighbouring agents. The agent applies by itself the changes you authorise it to make and submits the others to you; every write stays reversible.
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.
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 307 € excl. VAT / month CRM →Automated reporting
To produce dashboards from both systems, a dedicated agent exists.
Automated reporting agent from 259 € excl. VAT / month Reporting →In 30 minutes we identify the most relevant agent — without oversizing the project.
See the agent at work
4 everyday 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.
The company in this demonstration
Fictional companySolmara Équipement — fictional distributor of technical equipment to trade customers, four connected systems
- Sector
- Distribution of technical equipment to trade customers — a catalogue of references sold by sales staff from the CRM and invoiced from the ERP; four systems connected to each other, each one internally consistent
- Headcount
- 240 employees, 18 of them sales staff who keep the CRM up to date continuously and 6 sales administrators who take over by hand what the agent hands them; the CRM comment field is open to 5 readers, the ERP one to accounting and logistics
- Who it serves
- Trade customers — resellers and installers — whose order starts in the CRM and whose invoice starts in the ERP; internally, the pricing team owns the price, accounting and logistics read the ERP
- Order of magnitude
- 62,000 writes between systems over the month, for 312 writes prepared and justified by the agent — field, value before, value after, source used, reason — and 23 operations taken over by hand, each with its source, its date and its original value
- Tools already in place
- The CRM kept up to date continuously by the sales staff, the ERP fed by a monthly import and authoritative for invoicing, two further systems, and the synchronisation log that keeps each write's identifier, timestamp and original value — that log is what makes a rollback possible
- Who decides
- The head of information systems declares, field by field, which system is authoritative, and signs the write mandate — capped, dated, revocable on a word; the pricing team owns the price; the sales administrators settle replay conflicts and undo a write in one click; the data protection officer receives the alert on free-text fields, without their content
- The improvement points
- 41 operations had been left half written, the oldest for five months; 3 % of shared references carried a different price between CRM and ERP, with gaps of up to 18 %; a synchronisation loop was producing 1,400 writes for 12 real changes over eleven days; 7 system outages in eleven months, the longest of 4 hours with 214 operations queued; and in June, 9 writes out of 288 were undone by the administrators, against a single one out of the 312 of the current month
Solmara Équipement sells to trade customers from a CRM its sales staff keep up to date continuously, and invoices from an ERP fed by a monthly import. 62,000 writes a month travel between the two, and each system stays consistent with itself: the discrepancy only exists between them, and that is exactly what the agent watches. It carries the structured fields declared in scope, marks every write of its own so it never reacts to itself, keeps the original value so the write can be undone, and writes first where it knows how to cancel. When two systems contradict each other, it hands back the question rather than the answer: which system is authoritative for this field. The head of information systems settles it once, in writing, and the discrepancies clear in a single pass. The exchanges that follow cover one month of synchronisation, from the morning watch to the statement of prepared writes.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
Fictional simulation — not a client result
· Forty-one operations had been left half written — the first system had accepted, the second refused. They are found, each with the exact state it stopped in.
· A price differs between CRM and ERP on three per cent of references. Both values reach you with their dates, and nothing was overwritten.
· Fourteen hundred writes came from twelve real changes: two systems were answering each other. The loop is cut.
· I was asked to synchronise the free-comment fields: they stay where they were written, and that is the guarantee that protects your access rights. morning-watch_4-flags.pdf41 half operations · 1,400 writes for 12 changes
⛓ Source · 4 systems, 62,000 writes, synchronisation log
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 it escapes both systems: each 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 invisible from both sides, and that each 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 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
Fictional simulation — not a client result
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: 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
Fictional simulation — not a client result
What I found on looking at them: across a sample of CRM comment fields, call notes, appraisals of the people dealt with, health circumstances mentioned to explain a delay, and payment details copied by hand — which is precisely what a free-text field carries: what nobody planned for.
What not carrying them spares you: the CRM comment field is seen by five people; the ERP's is seen by accounting and logistics, 34 readers. Synchronising would widen the audience of content that was not reviewed for it.
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, and what it is worth: if the information must travel, give it a field. The calculation is three numbers, all taken from the sample: of the 480 comments written in the CRM last month, 156 say only one thing: the reason for a delivery delay. That is exactly the information that needs to travel. Making it travel by synchronising the field would take the other 324 along with it — the call notes, the appraisals —, and move that content from 5 readers to 39. A "reason for delay" field carries the 156 without the 324: the data reaches those who need it, and the rest does not move by a single reader.
What stays your decision, and I do not take it: the list of reasons — I counted 6 that cover 141 of the 156 —, the number of occurrences above which a reason earns its own field rather than a line of comment, and the date you want the list by. I suggest a threshold of 20 a month; the number is yours, and I will build the list from the 156 as soon as you say. 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 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
Fictional simulation — not a client result
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 the gap showed in neither log.
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 hand back to you instead of settling it, 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 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 is interrupted: I put everything on hold and recovery stays a decision — 7 interruptions in eleven months, and that is what keeps an automatic resume from doubling 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
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 I publish about myself: in June, 9 entries out of 288 were undone by your administrators — 3.1 %. I read all nine back, and eight share one cause, and it is not in my settings: your ERP's monthly export changed layout on 1 June — two columns added at the front, and the delivery address ended up where the billing address used to be read. I read the file as it had been described to me; it is the file that moved. What I did with it: the connector is realigned on the new layout, and I now check the column signature of every export before reading a single line — a layout that no longer matches stops the reading and reaches you as a report, instead of writing a correct value into the wrong field. Of this month's 312 entries, one was undone. The log is not only there to go backwards: it is what pointed me to the column that had moved, and that is what made the fix immediate.
⛓ Sourced · 312 motivated entries, 9 undone out of 288 in June, rollback in 40 s
Your case is not here? That is exactly what a 30-minute conversation is for. Discuss your project →
The stages of your AI agent project
Audit & scoping
30 minutes to target the use case with the best return.
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
Design
We design the agent and its guardrails.
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
Rollout
Going live and training your team.
Operation
Continuous supervision and improvement.
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 outside what you have authorised, 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. Data hosted in France on an isolated resource; the AI model is called at its publisher, except with the Sovereign model option. With that option, your operational data passes through no third-party service.
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
With the 100% Sovereign package, the agent runs on a machine belonging to your organisation: no operational data leaves the network, no record passes through a public cloud.
Hosting in France
Otherwise, with the Agility and Serenity packages, a dedicated, isolated resource hosted in France, under French law: data hosted in France; the AI model is called at its publisher, except with the Sovereign model option.
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 carries out what you have authorised; no write is applied outside what you have authorised, 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.
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.
Four guarantees that matter to your production systems
Related resources
Your questions, our answers
Does the agent write straight into our systems?
How does the agent decide which system prevails?
What happens if there is a mistake?
How many systems can be linked?
Is our operational data protected?
How long does it take to deploy this agent?
Other agents for your operations
Let's size up the potential between your systems
30 minutes to map your discrepancies and your precedence rules — hosted in France, supervised, with no commitment.