● B2B offer — Support & expertise
Level 2 support: the context gathered, the lines opened
A level 2 incident is rarely unresolved for want of expertise: it is resolved slowly because reconstructing the context takes time. Version, configuration, history of exchanges, similar incidents already handled — your agent gathers all of it and proposes lines of diagnosis, each tied to what justifies it. Hosted in France: your customers' configurations stay with you. The engineer runs the diagnosis; the agent saves them starting from scratch.
Hosted in France
Customer configurations protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Level 2 support · hosted in France
This case has come up from level 1 — give me the position.
Context gathered: version installed, configuration declared, steps already tried at level 1 and the history of exchanges with this customer.
Three similar incidents found in your base, with how they were resolved and the factor they had in common.
Two lines of diagnosis, each tied to the element behind it.
🔗 Sourced · lines tied to past incidents
Three similar incidents found in your base, with how they were resolved and the factor they had in common.
Two lines of diagnosis, each tied to the element behind it.
🔗 Sourced · lines tied to past incidents
The first line — are you sure?
It rests on two comparable incidents, but one element differs here: the intermediate version is not the same.
I flag it rather than presenting the line as established — that is the kind of gap that costs half a day if it goes unnoticed.
✎ Support · the gap is flagged, not hidden
I flag it rather than presenting the line as established — that is the kind of gap that costs half a day if it goes unnoticed.
✎ Support · the gap is flagged, not hidden
Local inference · no data outside the EU
History 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 support engineer decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent level 2 support agent gathers the full context of an incident — version, configuration, steps already tried, customer history — finds the similar incidents already resolved in your base and proposes lines of diagnosis tied to what justifies them. Where a line rests on an imperfectly comparable case, it says so. It runs on local inference or is hosted in France: your customers' configurations stay 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
diagnosis 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 volume of level 2 incidents is confirmed by a pilot.
The context
What does an AI agent bring to your level 2 support?
Your engineers' expertise is not the limiting factor: reconstructing the context is. Gathering it automatically gives them back time to diagnose.
! The issue
A level 2 incident calls on scarce expertise, and most of the delay goes into reconstructing the context: which version, which configuration, what has already been tried, have we seen this before? The agent gathers those elements, finds the comparable incidents in your base and opens documented lines — the engineer starts where they used to start after an hour of searching.
✓ Our answer
The lines proposed are tied to what justifies them, and the gaps with past cases are flagged rather than passed over in silence — that is precisely the kind of detail that costs half a day. Local inference or an isolated resource hosted in France: your customers' configurations, often revealing of their infrastructure, do not leave your premises.
The decisive point
Your customers' configurations and their incident history: sovereignty & compliance
Your customers' configurations and their incident history describe their infrastructure. Here is how the architecture of our agents protects them.
Local inference
The agent can run on a machine belonging to your organisation: no customer configuration and no incident history leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your incident history and your technical base: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your customers' configurations and their incident history, 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 incident base.
Lines tied to their justification
Every line refers back to the incidents or the elements behind it, gaps included; encryption, role-based access and logging of every diagnosis prepared.
AI Act: governed deployment
The agent is strictly in support; no line is presented as established and no intervention is applied; 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 incidents touching critical infrastructure or customers subject to an approval regime, 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.
Level 2 support · hosted in France
Four flags this morning, and they concern my own conclusions.
· Forty-one cases were closed as "external cause". I had ten reread: nine were, one was not.
· Twenty-two per cent of cases are closed "not reproducible". Seven of them were the same defect.
· Eleven customers were told "it is fixed" for a version they have not installed.
· Three requests concerned data I have no access to. I asked for it, I did not take it. morning-watch_4-flags.pdf41 "external cause" · 7 not reproducible, one defect
⛓ Source · 1,840 second-line cases, closure log
· Forty-one cases were closed as "external cause". I had ten reread: nine were, one was not.
· Twenty-two per cent of cases are closed "not reproducible". Seven of them were the same defect.
· Eleven customers were told "it is fixed" for a version they have not installed.
· Three requests concerned data I have no access to. I asked for it, I did not take it. morning-watch_4-flags.pdf41 "external cause" · 7 not reproducible, one defect
⛓ Source · 1,840 second-line cases, closure log
Why reread cases closed as external cause?
Because it is the one conclusion nobody ever checks: it takes the case out of scope, and therefore out of control.
What I record: 41 cases closed as "external cause" — the customer's network, third-party hardware, a misconfiguration at their end. None was reread, and none has any reason to be: once the cause is declared external, the case no longer counts among product defects.
Why that is structurally dangerous: it is the conclusion that suits everybody. It closes the case, it leaves the indicator, and it is often true — which makes it credible even when it is not.
What the rereading showed: of 10 drawn at random, 9 were indeed external. One was not — a behaviour of our product under an unusual but legitimate network configuration. One in ten is four cases out of the 41.
What I now do: a sample of the "external cause" closures is reread every month, and the rate appears in the summary. A case closed as external is not shut: it is set aside with its date.
What I prepare for every external cause, and what gets signed: the whole file — the configuration observed, what was reproduced at our end and what was not, the third-party element involved, and the message to the customer already drafted. The announcement itself is signed by a human: "the problem is at your end" is support's costliest sentence when it is wrong — and it is wrong one time in ten, four cases out of the 41. Validation takes two minutes per case, and that is the price of the one sentence a customer does not forgive. 41-cases_1-in-10-requalified.pdfThe conclusion that suits everybody
⛓ Source · 41 cases, 10 reread, 1 requalified
What I record: 41 cases closed as "external cause" — the customer's network, third-party hardware, a misconfiguration at their end. None was reread, and none has any reason to be: once the cause is declared external, the case no longer counts among product defects.
Why that is structurally dangerous: it is the conclusion that suits everybody. It closes the case, it leaves the indicator, and it is often true — which makes it credible even when it is not.
What the rereading showed: of 10 drawn at random, 9 were indeed external. One was not — a behaviour of our product under an unusual but legitimate network configuration. One in ten is four cases out of the 41.
What I now do: a sample of the "external cause" closures is reread every month, and the rate appears in the summary. A case closed as external is not shut: it is set aside with its date.
What I prepare for every external cause, and what gets signed: the whole file — the configuration observed, what was reproduced at our end and what was not, the third-party element involved, and the message to the customer already drafted. The announcement itself is signed by a human: "the problem is at your end" is support's costliest sentence when it is wrong — and it is wrong one time in ten, four cases out of the 41. Validation takes two minutes per case, and that is the price of the one sentence a customer does not forgive. 41-cases_1-in-10-requalified.pdfThe conclusion that suits everybody
⛓ Source · 41 cases, 10 reread, 1 requalified
How do you work, and where do you hand over?
I diagnose with what I am given, and I never conclude by elimination.
What each case carries: what was reproduced and under what conditions, what was ruled out and on what basis, the exact version at the customer's, and what I could not verify.
Routing follows who can act: a reproduced defect goes to development, with the minimal case; an unreproduced case is kept and matched against the others, never deleted; a probable external cause goes to a human before anything is said to the customer; an existing undeployed fix goes to the customer, with the version carrying it.
With a monthly summary: cases by cause, requalification rate of external causes, unreproducible cases matched, available fixes not deployed.
Three operating rules, and what they give you. Access to customer data is asked for, never taken: I name the exact window I need, I say why, and I stick to what is sent — which is what makes the case file showable to the customer themselves. A failure to reproduce concludes nothing: the case is kept with all its conditions and matched against the others, and that is how seven isolated cases became one reproduced defect, fixed in three days. The fix date is signed by development, the only ones it commits: I hand them the minimal case, the version, the volume and the sequence — everything, in other words, that separates an estimate from a date that holds.
✎ Framework · no data access · no date promised
What each case carries: what was reproduced and under what conditions, what was ruled out and on what basis, the exact version at the customer's, and what I could not verify.
Routing follows who can act: a reproduced defect goes to development, with the minimal case; an unreproduced case is kept and matched against the others, never deleted; a probable external cause goes to a human before anything is said to the customer; an existing undeployed fix goes to the customer, with the version carrying it.
With a monthly summary: cases by cause, requalification rate of external causes, unreproducible cases matched, available fixes not deployed.
Three operating rules, and what they give you. Access to customer data is asked for, never taken: I name the exact window I need, I say why, and I stick to what is sent — which is what makes the case file showable to the customer themselves. A failure to reproduce concludes nothing: the case is kept with all its conditions and matched against the others, and that is how seven isolated cases became one reproduced defect, fixed in three days. The fix date is signed by development, the only ones it commits: I hand them the minimal case, the version, the volume and the sequence — everything, in other words, that separates an estimate from a date that holds.
✎ Framework · no data access · no date promised
Twenty-two per cent not reproducible — is that normal?
It is common, and it is above all the fate reserved for the hardest defects.
What I record: 22% of cases are closed "not reproducible". In most tools that closure removes the case from defect statistics — it proved nothing.
What it actually discards: precisely the defects that depend on a rare combination — a version, a data volume, a sequence of actions, a time of day. They are the hardest to find, and they are the only ones this closure eliminates.
What I do: I keep every unreproduced case with all its conditions, and I match them against each other. One case alone proves nothing; seven cases sharing three conditions out of five is a defect.
What that gave: 7 cases closed as not reproducible over five months, at five different customers, shared the same version and the same sequence. Reproduced on the seventh match, fixed in three days.
What I write to the customer, and it is exactly what happened: "I could not reproduce it", with the conditions I tried and the ones I am missing — the case stays open and matched against the others. "There is no defect" is a conclusion, and it is not drawn from a failure: both sentences are delivered the same way in most cases, and it is the second one that loses customers. 7-cases_5-customers.pdfOne case proves nothing, seven sharing three conditions are a defect
⛓ Source · 22% closed not reproducible, 7 cases matched, 5 customers
What I record: 22% of cases are closed "not reproducible". In most tools that closure removes the case from defect statistics — it proved nothing.
What it actually discards: precisely the defects that depend on a rare combination — a version, a data volume, a sequence of actions, a time of day. They are the hardest to find, and they are the only ones this closure eliminates.
What I do: I keep every unreproduced case with all its conditions, and I match them against each other. One case alone proves nothing; seven cases sharing three conditions out of five is a defect.
What that gave: 7 cases closed as not reproducible over five months, at five different customers, shared the same version and the same sequence. Reproduced on the seventh match, fixed in three days.
What I write to the customer, and it is exactly what happened: "I could not reproduce it", with the conditions I tried and the ones I am missing — the case stays open and matched against the others. "There is no defect" is a conclusion, and it is not drawn from a failure: both sentences are delivered the same way in most cases, and it is the second one that loses customers. 7-cases_5-customers.pdfOne case proves nothing, seven sharing three conditions are a defect
⛓ Source · 22% closed not reproducible, 7 cases matched, 5 customers
And the eleven customers told "it is fixed"?
The fix exists, and it is not at their end. The two statements have nothing to do with each other.
What I record: 11 cases closed with "fixed in version 4.2". Of the 11, 9 customers were on 4.0 or 4.1, and nothing in the message said so.
What they understood: that their problem was solved. Which was true at our end and false at theirs. Six reopened the case within three weeks — and reopening cost them a second full account of it.
What I do: I never close a case on a fix's existence. I close on its installation, or I leave the case open marked "fixed in 4.2, you are on 4.0" and what the upgrade involves.
What I add, because it is the real question: what the update requires at their end — downtime, dependencies, configuration rework. An unreachable fix is not a fix.
What I flag to the product team: fixes available for more than three months and the number of customers who do not have them. This quarter, a security fix was in that position at 34 customers. 11-cases_34-customers-without-the-fix.pdfAn unreachable fix is not a fix
⛓ Source · 11 cases, 9 customers on an earlier version, 6 reopenings
What I record: 11 cases closed with "fixed in version 4.2". Of the 11, 9 customers were on 4.0 or 4.1, and nothing in the message said so.
What they understood: that their problem was solved. Which was true at our end and false at theirs. Six reopened the case within three weeks — and reopening cost them a second full account of it.
What I do: I never close a case on a fix's existence. I close on its installation, or I leave the case open marked "fixed in 4.2, you are on 4.0" and what the upgrade involves.
What I add, because it is the real question: what the update requires at their end — downtime, dependencies, configuration rework. An unreachable fix is not a fix.
What I flag to the product team: fixes available for more than three months and the number of customers who do not have them. This quarter, a security fix was in that position at 34 customers. 11-cases_34-customers-without-the-fix.pdfAn unreachable fix is not a fix
⛓ Source · 11 cases, 9 customers on an earlier version, 6 reopenings
When a level 2 ticket comes in, what do you do before an engineer opens it?
I rebuild the context, and it is done before the ticket even appears.
What I gather in 40 seconds: the version installed at the customer and its update date, the effective configuration — the 23 settings that differ from the default, not the other 180 —, the steps already tried by the customer and by level 1, and the customer's history: their 14 earlier tickets, 3 of them on the same module.
What rebuilding that context used to cost: 34 minutes per ticket for your engineers, spent re-reading message threads and asking the customer again for what they had already written. Across 2,100 level 2 tickets a year, more than 1,100 hours — more than thirty-one 35-hour weeks, rounded down. The context now arrives with the ticket, on one page.
Comparable incidents, and how I find them: I match the new ticket against your 9,400 closed incidents across five versions, on five conditions — version, module, sequence of actions, data volume, time of day. For this one, 6 comparable incidents come up, all on version 4.1 with the same sequence, and four were resolved by the same action: clearing the index cache after import. The common factor is named, not guessed: it rests on the five shared conditions, and I give you the four ticket numbers.
The figure that does not flatter me: of my first 200 matches, 31 listed comparable incidents that were not comparable — 15.5 %. All shared the module and not the version, and the module alone proves nothing: it was the gap between 4.0 and 4.1 that carried the defect. I made the version mandatory among the shared conditions; over the next 600 matches, the rate fell to 4 %, and your engineers stopped opening a list only to close it.
⛓ Sourced · 34 min of context rebuilding per ticket, 9,400 incidents compared, 6 matched
What I gather in 40 seconds: the version installed at the customer and its update date, the effective configuration — the 23 settings that differ from the default, not the other 180 —, the steps already tried by the customer and by level 1, and the customer's history: their 14 earlier tickets, 3 of them on the same module.
What rebuilding that context used to cost: 34 minutes per ticket for your engineers, spent re-reading message threads and asking the customer again for what they had already written. Across 2,100 level 2 tickets a year, more than 1,100 hours — more than thirty-one 35-hour weeks, rounded down. The context now arrives with the ticket, on one page.
Comparable incidents, and how I find them: I match the new ticket against your 9,400 closed incidents across five versions, on five conditions — version, module, sequence of actions, data volume, time of day. For this one, 6 comparable incidents come up, all on version 4.1 with the same sequence, and four were resolved by the same action: clearing the index cache after import. The common factor is named, not guessed: it rests on the five shared conditions, and I give you the four ticket numbers.
The figure that does not flatter me: of my first 200 matches, 31 listed comparable incidents that were not comparable — 15.5 %. All shared the module and not the version, and the module alone proves nothing: it was the gap between 4.0 and 4.1 that carried the defect. I made the version mandatory among the shared conditions; over the next 600 matches, the rate fell to 4 %, and your engineers stopped opening a list only to close it.
⛓ Sourced · 34 min of context rebuilding per ticket, 9,400 incidents compared, 6 matched
Can't you just go and look at the customer's end?
No. Diagnosing does not confer a right of entry.
What I am often offered: permanent access to the customer's systems, "to save time on diagnostics". It would save time, that is true.
Why I refuse: an access opened for diagnosis stays open between diagnoses. It never closes by itself, nobody revokes it, and it ends up used for something else — out of convenience, never out of malice.
What I do: I ask for exactly what I need, saying what it is for: "the module X log between 2 and 3 pm on the 12th", not "your logs". The customer sends, and they know what they are sending.
What I do with what arrives anyway: sendings often contain more than was asked. I use only the part requested, and I say so: "received 400 MB of logs, used the 2–3 pm window". The rest is deleted when the case closes.
What I keep from a case when it closes, and it is what actually serves the next one: the symptom, the version, the configuration and the cause found — without a single line of customer data. Across 1,100 cases, that base of causes turned up a comparable case in 62 % of diagnoses, while the log extracts are deleted at closure. An extract kept "because it might serve" never serves and ends up in a customer database no contract provides for — a cause, by contrast, is reusable indefinitely. what-is-asked_and-what-is-deleted.pdfAn access opened for diagnosis stays open between diagnoses
✎ Framework · no permanent access · only the requested part is used
What I am often offered: permanent access to the customer's systems, "to save time on diagnostics". It would save time, that is true.
Why I refuse: an access opened for diagnosis stays open between diagnoses. It never closes by itself, nobody revokes it, and it ends up used for something else — out of convenience, never out of malice.
What I do: I ask for exactly what I need, saying what it is for: "the module X log between 2 and 3 pm on the 12th", not "your logs". The customer sends, and they know what they are sending.
What I do with what arrives anyway: sendings often contain more than was asked. I use only the part requested, and I say so: "received 400 MB of logs, used the 2–3 pm window". The rest is deleted when the case closes.
What I keep from a case when it closes, and it is what actually serves the next one: the symptom, the version, the configuration and the cause found — without a single line of customer data. Across 1,100 cases, that base of causes turned up a comparable case in 62 % of diagnoses, while the log extracts are deleted at closure. An extract kept "because it might serve" never serves and ends up in a customer database no contract provides for — a cause, by contrast, is reusable indefinitely. what-is-asked_and-what-is-deleted.pdfAn access opened for diagnosis stays open between diagnoses
✎ Framework · no permanent access · only the requested part is used
And if the customer sends sensitive data unknowingly?
It happens, and it is the most delicate case in this trade.
What I record: across the sendings received, 17 contained personal data about their own customers — a database export to illustrate a display problem, logs containing full addresses.
Why the customer does not see it: they send what reproduces their problem, not what it contains. An export that reproduces a display bug contains the displayed data, and there is no reason to think about it while trying to get help.
What I do: I flag it immediately to my contact at the customer, I ask whether an anonymised extract would do, and I delete the sending if so. Of the 17, 12 were replaced by a reduced extract.
What I do meanwhile, and what I leave to be decided: the case moves on without the sending — I resume the diagnosis on the non-identifying part, and I write out for the customer the reduced extract that would do: the fields to keep, the ones to strip, the expected volume. What identifies their own customers is theirs to decide and to sign — anonymising means having read it, and that is not settled on their behalf. It is that precise request which made the twelve replacements possible in under twenty-four hours.
What I keep of the remaining 5: nothing beyond the case. They are deleted at closure, and the deletion is logged. 17-sendings_12-replaced.pdfThey send what reproduces their problem, not what it contains
⛓ Source · 17 sendings containing personal data, 12 replaced
What I record: across the sendings received, 17 contained personal data about their own customers — a database export to illustrate a display problem, logs containing full addresses.
Why the customer does not see it: they send what reproduces their problem, not what it contains. An export that reproduces a display bug contains the displayed data, and there is no reason to think about it while trying to get help.
What I do: I flag it immediately to my contact at the customer, I ask whether an anonymised extract would do, and I delete the sending if so. Of the 17, 12 were replaced by a reduced extract.
What I do meanwhile, and what I leave to be decided: the case moves on without the sending — I resume the diagnosis on the non-identifying part, and I write out for the customer the reduced extract that would do: the fields to keep, the ones to strip, the expected volume. What identifies their own customers is theirs to decide and to sign — anonymising means having read it, and that is not settled on their behalf. It is that precise request which made the twelve replacements possible in under twenty-four hours.
What I keep of the remaining 5: nothing beyond the case. They are deleted at closure, and the deletion is logged. 17-sendings_12-replaced.pdfThey send what reproduces their problem, not what it contains
⛓ Source · 17 sendings containing personal data, 12 replaced
Can you tell the customer when it will be fixed?
I tell them everything already decided — and if you open the link to the development tracker, I give them the date development itself published.
What I announce without hesitation: that the defect is reproduced, under what conditions, that it is recorded under such a reference, on what date, and the workaround where one exists. That is what a customer most often lacks, long before a date.
What I open if you wire it up: the fix date as development recorded it, with its last update. The date comes from them, I carry it — I manufacture none.
The only date I announce is a decided date, and I say who decided it: "development recorded 14 March, updated on 2 February". A date announced by support commits development, which did not set it, and the customer holds it as a commitment. What I supply when development has recorded nothing yet: the workaround, the defect reference, its recording date, and where the case sits in development's queue — across 240 cases those four elements were enough, in 78 % of them, for the customer to stop pressing on the date.
The sentence I stopped letting through: "it is fixed in version 4.2". 11 files were closed that way while the fix was not deployed at the customer's site. "The fix exists" and "the fix is with you" are two unrelated sentences — I now say the second, or nothing. what-is-announced_what-is-not.pdfWhat opens · the date coming from development · the abandoned sentence
⛓ Source · 11 files closed on a fix not deployed at the customer
What I announce without hesitation: that the defect is reproduced, under what conditions, that it is recorded under such a reference, on what date, and the workaround where one exists. That is what a customer most often lacks, long before a date.
What I open if you wire it up: the fix date as development recorded it, with its last update. The date comes from them, I carry it — I manufacture none.
The only date I announce is a decided date, and I say who decided it: "development recorded 14 March, updated on 2 February". A date announced by support commits development, which did not set it, and the customer holds it as a commitment. What I supply when development has recorded nothing yet: the workaround, the defect reference, its recording date, and where the case sits in development's queue — across 240 cases those four elements were enough, in 78 % of them, for the customer to stop pressing on the date.
The sentence I stopped letting through: "it is fixed in version 4.2". 11 files were closed that way while the fix was not deployed at the customer's site. "The fix exists" and "the fix is with you" are two unrelated sentences — I now say the second, or nothing. what-is-announced_what-is-not.pdfWhat opens · the date coming from development · the abandoned sentence
⛓ Source · 11 files closed on a fix not deployed at the customer
What do you keep?
What describes the defects — and none of the data used to find them.
What is kept: the reproduction conditions and the minimal case, what was ruled out and how, the closed files with their conclusion and its re-reading, the fixes and their real deployment date at each customer, and the submissions received with their purge date.
Why customer data does not stay: I ask for a dataset to reproduce, and I purge it once the minimal case is established. Of the submissions received, 17 contained personal data belonging to my customer's own customers — sent unintentionally, in a full export. Permanent access to the customer's systems, often offered "to save time", would turn that accident into a permanent state.
What systematic re-reading showed: 41 files closed as "external cause". Ten re-read: several were not. It is the one conclusion nobody ever checks — it takes the file out of scope, therefore out of control. It is now re-read as a matter of principle.
And on "not reproducible": 22 % of files. Seven of them described the same defect — it is the fate reserved for the hardest defects, not a neutral category. what-you-keep_level2.pdf5 items kept · customer data purged once the minimal case is set
⛓ Source · 41 external-cause closures re-read, 17 submissions with personal data purged
What is kept: the reproduction conditions and the minimal case, what was ruled out and how, the closed files with their conclusion and its re-reading, the fixes and their real deployment date at each customer, and the submissions received with their purge date.
Why customer data does not stay: I ask for a dataset to reproduce, and I purge it once the minimal case is established. Of the submissions received, 17 contained personal data belonging to my customer's own customers — sent unintentionally, in a full export. Permanent access to the customer's systems, often offered "to save time", would turn that accident into a permanent state.
What systematic re-reading showed: 41 files closed as "external cause". Ten re-read: several were not. It is the one conclusion nobody ever checks — it takes the file out of scope, therefore out of control. It is now re-read as a matter of principle.
And on "not reproducible": 22 % of files. Seven of them described the same defect — it is the fate reserved for the hardest defects, not a neutral category. what-you-keep_level2.pdf5 items kept · customer data purged once the minimal case is set
⛓ Source · 41 external-cause closures re-read, 17 submissions with personal data purged
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 stages of the diagnosis. 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 574 € excl. VAT / month
Reconstructing the context
Gathers version, configuration, steps already tried and the customer's history.
Comparable incidents
Finds in your base the similar cases already resolved and their common factor.
Flagging variances
States how a past case differs from the present one, rather than concluding too quickly.
Controls and safeguards
These 5 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
Status, safe closure and audit trail
Sources, access rights and handling of questions with no answer
Resolve common requests through to a verifiable closure
Escalate quickly to a human, with the reason and the history
What the agent must be connected to
This connection is required for the agent to work. It concerns your information system and is scoped during the audit.
Carry the full context across channels and into the ticket/CRM
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 much diagnosis time can a team recover?
By gathering the context and the comparable cases, the searching that precedes the diagnosis proper disappears. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Reconstructing the context
Searching for similar incidents
Framing the first lines
Indicative figures, not contractual, to be confirmed by a pilot on your volume of level 2 incidents. The lines are documented hypotheses, not conclusions: the diagnosis and the intervention belong to the support engineer.
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 level 2 diagnosis agent (context, comparable cases, documented lines), installed and operated for you.
Agility
Setup + controlled subscription
5,065 € excl. VAT setup
then 574 € 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
859 € 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
8,400 € excl. VAT setup
then 771 € 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 clients
Your customers' configurations stay with youLocal inference or an isolated resource hosted in France; no configuration and no incident history entrusted to a third party, no data used to train a model.
Data in France, under French lawYour customers' configurations and their incident history: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The support engineer keeps the decisionThe agent produces documented diagnoses, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of level 2 incidents: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Are the lines proposed reliable?
They are documented hypotheses: each refers back to the incidents or elements behind it, and the agent flags how a past case differs from the present one. The diagnosis remains the engineer's.
Does the agent act on the customer's systems?
No. It gathers and proposes; any intervention is carried out by the support engineer. It is they who commit the company's responsibility towards the customer.
How does the agent find similar incidents?
In your base of resolved incidents, against the criteria you define — symptom, version, configuration. The better filled in your history is, the more useful the matches.
Is our clients' 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 customers' configurations are not used to train a third-party model.
Which tools can our customers use to talk to the agent?
The ones they already use: WhatsApp Business, your website chat and email. Your customers have no account to create and no app to install. Your own teams reach the same agent from Microsoft Teams, Slack or their email. These connections rest on open standards, including the MCP protocol, and are included in every plan, at no extra cost, within the number of connections your level includes; the catalogue grows without a surcharge. Only the fees charged by third-party platforms — WhatsApp Business bills per conversation — are passed on to you at cost, without margin, outside the subscription. You keep oversight from a web dashboard.
Does it connect to our support tool?
Yes, to the common ticketing tools and knowledge bases. The integration is defined at the design stage, with no migration.
How long does it take to deploy this agent?
A few weeks as a rule, depending on how rich your incident history is and the integrations chosen, after a free audit then a phase of design, integration and testing.
Related use cases
Other agents for support
Let's talk
Let's size up the potential on your complex incidents
15 minutes to assess your history and your integrations — hosted in France, supervised, with no commitment.