● Business offer — IT & tech
The AI agent for technical support & documentation: help your users, keep your docs current
Technical support answers the same questions a hundred times, and the documentation always falls behind the code. Your AI agent absorbs this work: it answers level 1 and 2 tickets by drawing on your source code, your issues and your docs, and it updates the documentation with every change. Hosted in France — on local inference or an isolated resource — your repository and your intellectual property never leave. The developer and the team keep control.
Hosted in France
Your code stays with you
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Technical support & docs agent · hosted in France
A client is getting a 401 on the /v2/orders endpoint although their key works on /v1. What changed?
Likely cause: since commit a4f7c1, the v2 API requires the orders:read scope in the token — v1 keys do not carry it by default.
Reply to the client: regenerate the key with the orders:read scope ticked, or add the X-Scope-Upgrade header. The "v2 authentication" page in the docs does not mention this change yet.
⛓ Source · the Git repository (changelog + auth/middleware.ts) + resolved tickets
Reply to the client: regenerate the key with the orders:read scope ticked, or add the X-Scope-Upgrade header. The "v2 authentication" page in the docs does not mention this change yet.
⛓ Source · the Git repository (changelog + auth/middleware.ts) + resolved tickets
Yes, update the docs and prepare the reply.
Draft ready: the reply to the client is written, and a fix to the "v2 authentication" page (the new orders:read scope + an example request) is proposed as a merge request.
Nothing is published or sent without your reading it over.
✎ Action · reply + docs merge request to read over — the developer approves
Nothing is published or sent without your reading it over.
✎ Action · reply + docs merge request to read over — the developer approves
Local inference · no data outside the EU
Code & data 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 team decidesThe agent assists, the developer approves
✦ In brief
For an IT team or a software publisher, a Blue Lemon Agent agent automates the repetitive tasks of support and documentation — answering level 1 and 2 tickets, searching the code and the issues, writing and updating the technical docs. It draws on your Git repository, your tickets and your knowledge base, and runs on local inference or is hosted in France: your source code and your intellectual property are never exposed to a foreign service, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. The developers' time is redirected to the product and the high-value subjects. Live within a few weeks Your teams write to it from Microsoft Teams, Slack or their email, and your users reach it on WhatsApp Business, your website chat or email — with no account to create and nothing to install. These connections are included in every plan, at no extra cost, within the number of connections your level includes.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
9
uses ready to deploy on this scope
0
decision taken without human approval
Reference points describing our offer, not results measured at a client. The scale of the gain is confirmed by a pilot on your own scope.
The context
Why AI appeals to tech teams — and why they hesitate
Developers spend a considerable amount of time answering the same questions and catching up documentation that has drifted from the code. But source code is a publisher's most strategic asset: entrusting it to a foreign service is out of the question.
! The issue
The team is caught between a support load that interrupts developers continuously and documentation that falls behind with every release — to the point where support and clients no longer know which source to trust. Yet most consumer coding assistants amount to sending your repository, your secrets and your intellectual property to a cloud, often hosted outside Europe and subject to the Cloud Act.
✓ Our answer
AI is only of interest to a tech team if it is sovereign and confidential by design. Local inference or an isolated resource hosted in France, systematic human oversight, the decision reserved for the developer: time gained on support and docs is never paid for in exposed code. The aim is not to replace the team, but to give it back headspace for the product.
The decisive point
Confidentiality of the source code: sovereignty & intellectual property
A tech team handles its most sensitive asset: the code. Here is how the architecture of our agents protects it, repository by repository.
Local inference
The agent can run on a machine belonging to the team: no source file leaves the network, nothing passes through a third-party cloud.
Hosting in France
Otherwise, a dedicated and isolated resource, hosted in France under French law — your repository: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
As regards your code, exposure to the Cloud Act and FISA 702 is reduced by design; location alone does not guarantee immunity.
One isolated resource per client
No pooling: your code and your docs live in a strictly dedicated environment, never reused to train a third-party model.
Controlled access to the repository
Encryption in transit and at rest, role-based access, strong authentication and logging of the agent's actions.
AI Act: governed deployment
The agent is strictly in support; no commit, no reply to a client and no publication of docs is approved automatically; traceability 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.
- The encryption mechanisms in transit and at rest, their components and key management are those documented for the architecture chosen.
- 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 the most sensitive contexts, SecNumCloud and HDS health-data hosting are options depending on how demanding the requirements are. 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.
Technical support & docs agent · hosted in France
Four flags this morning, and the first concerns answers I gave.
· Forty-one of my answers rested on out-of-date documentation. They were right according to the docs, and wrong according to the product.
· One same question was asked 312 times this quarter. It is not a documentation gap: it is a badly named button.
· Seven pages describe removed features, two of them for more than a year.
· The documentation says "click Save". The button has been called "Confirm" for eight months. morning-watch_4-flags.pdf41 answers right per the docs, wrong per the product
⛓ Source · 1,840 answers, documentation pages and their dates, product release log
· Forty-one of my answers rested on out-of-date documentation. They were right according to the docs, and wrong according to the product.
· One same question was asked 312 times this quarter. It is not a documentation gap: it is a badly named button.
· Seven pages describe removed features, two of them for more than a year.
· The documentation says "click Save". The button has been called "Confirm" for eight months. morning-watch_4-flags.pdf41 answers right per the docs, wrong per the product
⛓ Source · 1,840 answers, documentation pages and their dates, product release log
How can an answer be both right and wrong?
Because it faithfully describes a product that no longer exists.
What I record: 41 answers cited an accurate documentation page, current within its own universe, describing behaviour the product no longer has. None was an invention of mine.
Why it is more insidious than an error: I cited my source, the user could check it, and checking confirmed my answer. Two documents agreed and the product said otherwise.
What I do since: I systematically compare the page's date with the date of the last product release touching that feature. Where the page is older, I say so in the answer: "this page is dated [date]; the feature was changed on [date]. Here is what it describes, and I cannot guarantee it is still accurate."
What that changed: answers carrying that line rose to 63 out of 400 — more than the 41 errors, because the line also appears when the docs are still right. That is the price, and it is low.
And I did not stop at the line: for each page concerned, I wrote the sentence that no longer describes the product and its replacement, checked against the current release, and sent it to its author. What is left to them is approving it: a documentation page has an author and an approval process — and that is exactly what lets a reader rely on it six months later. 41-answers_2-agreeing-documents.pdfI cited my source, and it confirmed
⛓ Source · 41 answers, page dates, release log
What I record: 41 answers cited an accurate documentation page, current within its own universe, describing behaviour the product no longer has. None was an invention of mine.
Why it is more insidious than an error: I cited my source, the user could check it, and checking confirmed my answer. Two documents agreed and the product said otherwise.
What I do since: I systematically compare the page's date with the date of the last product release touching that feature. Where the page is older, I say so in the answer: "this page is dated [date]; the feature was changed on [date]. Here is what it describes, and I cannot guarantee it is still accurate."
What that changed: answers carrying that line rose to 63 out of 400 — more than the 41 errors, because the line also appears when the docs are still right. That is the price, and it is low.
And I did not stop at the line: for each page concerned, I wrote the sentence that no longer describes the product and its replacement, checked against the current release, and sent it to its author. What is left to them is approving it: a documentation page has an author and an approval process — and that is exactly what lets a reader rely on it six months later. 41-answers_2-agreeing-documents.pdfI cited my source, and it confirmed
⛓ Source · 41 answers, page dates, release log
How did you spot all that? And who do you tell?
I look at what you have opened to me: documentation pages and their dates, the product release log, questions received and answers given.
Routing follows who can fix the source: a page older than a product change goes to whoever wrote it, with both dates; a page describing a removed feature to the same person, first — it is wrong, not merely old; a massively repeated question to whoever designs the product, never to whoever writes the docs; a gap between the docs' vocabulary and the screen's to both, together.
With a chase: 7 days on a page describing a removed feature, monthly otherwise. Then a monthly summary: by page and by question, never by the person asking.
What this morning has already given you: 41 answers resting on out-of-date documentation picked back up one by one, and since then every answer carries its page's date against the product's — 63 out of 400 say so today, and the user knows what they are reading; seven pages describing removed features taken out of the answering queue; a button renamed eight months ago finally reconciled between the screen and the docs.
From tomorrow: 312 questions a quarter that stop arriving the day that button is renamed — that is not less support, it is support that no longer exists. Fixing your pages is not a prohibition, it is a mandate: open the documentation repository to me in write, bounded to the pages you name, dated, withdrawn on a word, and I push the fixes as merge requests — reviewed by their author, never published behind their back. Your code and your documentation never leave your premises: I reach what you open, repository by repository, and every read is logged.
The next step is ready: the seven pages are ranked by damage, with the fix written for each. Give me write access on that scope and they are up to date tonight.
✎ Framework · source date stated, no page modified
Routing follows who can fix the source: a page older than a product change goes to whoever wrote it, with both dates; a page describing a removed feature to the same person, first — it is wrong, not merely old; a massively repeated question to whoever designs the product, never to whoever writes the docs; a gap between the docs' vocabulary and the screen's to both, together.
With a chase: 7 days on a page describing a removed feature, monthly otherwise. Then a monthly summary: by page and by question, never by the person asking.
What this morning has already given you: 41 answers resting on out-of-date documentation picked back up one by one, and since then every answer carries its page's date against the product's — 63 out of 400 say so today, and the user knows what they are reading; seven pages describing removed features taken out of the answering queue; a button renamed eight months ago finally reconciled between the screen and the docs.
From tomorrow: 312 questions a quarter that stop arriving the day that button is renamed — that is not less support, it is support that no longer exists. Fixing your pages is not a prohibition, it is a mandate: open the documentation repository to me in write, bounded to the pages you name, dated, withdrawn on a word, and I push the fixes as merge requests — reviewed by their author, never published behind their back. Your code and your documentation never leave your premises: I reach what you open, repository by repository, and every read is logged.
The next step is ready: the seven pages are ranked by damage, with the fix written for each. Give me write access on that scope and they are up to date tonight.
✎ Framework · source date stated, no page modified
312 times the same question — should it be documented better?
No. It is a badly named button, and documenting it would make it permanent.
What I record: 312 questions this quarter concern the same thing — where to save a draft. The documentation says so, in three places, correctly.
What that means: when a question is asked three hundred times despite accurate documentation, the documentation is not the problem. The screen is.
What I looked at: the button is called "Confirm". Users look for "Save" — it is the word they use in their questions, in 287 cases out of 312.
Why I add no page, no callout, no tooltip: documenting a trap makes it permanent, and it is the easiest answer because it asks nothing of anybody else.
What I report instead, and to whom: the 312 questions and the 287 uses of the word "save", to whoever designs the screen — with the proposed replacement label and what it would return: at five minutes a question, 26 hours of support a quarter, rounded down. Not to whoever writes the documentation: that page is right, and its author can do nothing about it.
What I propose meanwhile: an answer using both words — "the save button is called 'Confirm'". It treats the symptom, and I say so. 312-questions_287-times-save.pdfDocumenting a trap makes it permanent
⛓ Source · 312 questions, 287 uses of the word "save", screen label
What I record: 312 questions this quarter concern the same thing — where to save a draft. The documentation says so, in three places, correctly.
What that means: when a question is asked three hundred times despite accurate documentation, the documentation is not the problem. The screen is.
What I looked at: the button is called "Confirm". Users look for "Save" — it is the word they use in their questions, in 287 cases out of 312.
Why I add no page, no callout, no tooltip: documenting a trap makes it permanent, and it is the easiest answer because it asks nothing of anybody else.
What I report instead, and to whom: the 312 questions and the 287 uses of the word "save", to whoever designs the screen — with the proposed replacement label and what it would return: at five minutes a question, 26 hours of support a quarter, rounded down. Not to whoever writes the documentation: that page is right, and its author can do nothing about it.
What I propose meanwhile: an answer using both words — "the save button is called 'Confirm'". It treats the symptom, and I say so. 312-questions_287-times-save.pdfDocumenting a trap makes it permanent
⛓ Source · 312 questions, 287 uses of the word "save", screen label
And the 7 pages describing removed features?
They are wrong, not old — and the difference changes the priority.
What I record: seven pages describe features that no longer exist. Two were removed more than a year ago. The seven pages were viewed 148 times this quarter.
What that produces: a user follows a procedure, cannot find the screen described, and concludes they misunderstood. Of the 148 views, 34 were followed by a support question — the other 114 said nothing.
What I do from this morning: when a question concerns one of those seven pages, I first answer that the feature no longer exists, before looking for what replaced it. In the reverse order, the user remembers the replacement and not the removal.
What I have written for the seven: the dated marking — "feature removed on [date]" — and, for five of them, the feature that took over the use. The last two have no replacement, and the marking says so rather than passing over it.
Why the pages stay online: an unpublished page returns an error, and a user who had bookmarked it understands nothing — whereas a marked page answers their question.
What is left to approve, and by whom: the seven markings, by whoever removed the feature. Three lines each, and 148 views a quarter stop misleading people. 7-pages_148-views.pdf114 people said nothing
⛓ Source · 7 pages, 148 views, 34 subsequent questions
What I record: seven pages describe features that no longer exist. Two were removed more than a year ago. The seven pages were viewed 148 times this quarter.
What that produces: a user follows a procedure, cannot find the screen described, and concludes they misunderstood. Of the 148 views, 34 were followed by a support question — the other 114 said nothing.
What I do from this morning: when a question concerns one of those seven pages, I first answer that the feature no longer exists, before looking for what replaced it. In the reverse order, the user remembers the replacement and not the removal.
What I have written for the seven: the dated marking — "feature removed on [date]" — and, for five of them, the feature that took over the use. The last two have no replacement, and the marking says so rather than passing over it.
Why the pages stay online: an unpublished page returns an error, and a user who had bookmarked it understands nothing — whereas a marked page answers their question.
What is left to approve, and by whom: the seven markings, by whoever removed the feature. Three lines each, and 148 views a quarter stop misleading people. 7-pages_148-views.pdf114 people said nothing
⛓ Source · 7 pages, 148 views, 34 subsequent questions
And when the answer is written on no published page at all?
Then I search where it really is written: across your five knowledge spaces, not the wiki alone.
What you have opened to me, and what it weighs: the team wiki (2,140 pages), the architecture decision records (318 ADRs), the operations runbooks (96), the resolved tickets (11,400) and the answers already validated by the team (742). 14,696 documents, five different filing schemes, no shared index — and that is the real defect: everyone searches the space they happen to know.
Yesterday's request, and what the search across the technical base returned: “a customer cutover failed mid-migration, how do we roll back”. Nothing in the published documentation. Three documents in three seconds, each with its space and its date: runbook RB-24 “migration roll-back” (runbooks, reviewed 3 months ago), ADR-114, which explains why that roll-back stayed manual (decisions, 2 years ago), and a ticket resolved 14 months ago carrying the exact command sequence. The answer existed; it lived in three spaces nobody searches together.
The figure that does not flatter me: across my first 120 searches, 14 returned the right procedure from the wrong space — 11.7%. The same procedure existed twice, wiki and runbooks, and the wiki copy was nine months behind. I ranked on word proximity, not on the date nor on the space that carries authority on the subject.
What I changed, and what it produced: every result now comes out with its space, its date and the product version it covers, and when two spaces contradict each other I return the contradiction rather than an answer — your rule applied to search: a page can be right and out of date. Across the next 300 searches: 0 answers drawn from the wrong space, 2 contradictions returned as such, both settled the same day by the team.
What that gives you back, and the arithmetic is yours: 480 searches of this kind in the quarter, 26 minutes median spent retrieving a document everyone knew existed — 12,480 minutes, that is 208 hours. At 35 hours a week, more than five weeks of work handed back to the product. search_5-spaces_14696-documents.pdf3 documents in 3 seconds · 14 wrong-space errors out of 120, then 0 out of 300
⛓ Sourced · 5 spaces, 14,696 documents · 14 errors out of 120, then 0 out of 300
What you have opened to me, and what it weighs: the team wiki (2,140 pages), the architecture decision records (318 ADRs), the operations runbooks (96), the resolved tickets (11,400) and the answers already validated by the team (742). 14,696 documents, five different filing schemes, no shared index — and that is the real defect: everyone searches the space they happen to know.
Yesterday's request, and what the search across the technical base returned: “a customer cutover failed mid-migration, how do we roll back”. Nothing in the published documentation. Three documents in three seconds, each with its space and its date: runbook RB-24 “migration roll-back” (runbooks, reviewed 3 months ago), ADR-114, which explains why that roll-back stayed manual (decisions, 2 years ago), and a ticket resolved 14 months ago carrying the exact command sequence. The answer existed; it lived in three spaces nobody searches together.
The figure that does not flatter me: across my first 120 searches, 14 returned the right procedure from the wrong space — 11.7%. The same procedure existed twice, wiki and runbooks, and the wiki copy was nine months behind. I ranked on word proximity, not on the date nor on the space that carries authority on the subject.
What I changed, and what it produced: every result now comes out with its space, its date and the product version it covers, and when two spaces contradict each other I return the contradiction rather than an answer — your rule applied to search: a page can be right and out of date. Across the next 300 searches: 0 answers drawn from the wrong space, 2 contradictions returned as such, both settled the same day by the team.
What that gives you back, and the arithmetic is yours: 480 searches of this kind in the quarter, 26 minutes median spent retrieving a document everyone knew existed — 12,480 minutes, that is 208 hours. At 35 hours a week, more than five weeks of work handed back to the product. search_5-spaces_14696-documents.pdf3 documents in 3 seconds · 14 wrong-space errors out of 120, then 0 out of 300
⛓ Sourced · 5 spaces, 14,696 documents · 14 errors out of 120, then 0 out of 300
"Save" against "Confirm" — does it matter that much?
It is the cheapest defect to fix and the most expensive to leave.
What I record: the button was renamed "Confirm" eight months ago. The documentation still says "Save", in eleven places. Both are right within their own universe.
What it produces for the user: they read an instruction, look for the word on screen, cannot find it, and they do not conclude the docs are old — they conclude they are on the wrong screen. That is the difference between out-of-date documentation and documentation that sows doubt.
What I do: I record every gap between the screens' vocabulary and the documentation's, and report them to both authors together. Separately, each assumes the other will follow.
What that gave: 34 vocabulary gaps recorded. Twenty-six were fixed in the documentation, four in the product — because the product's word was less clear — and four remain, for want of agreement on the right term.
Those four are the most interesting: they are the places where the company has not settled how it names its own feature. 34-gaps_4-unsettled.pdfThey conclude they are on the wrong screen
⛓ Source · 34 vocabulary gaps, outcomes
What I record: the button was renamed "Confirm" eight months ago. The documentation still says "Save", in eleven places. Both are right within their own universe.
What it produces for the user: they read an instruction, look for the word on screen, cannot find it, and they do not conclude the docs are old — they conclude they are on the wrong screen. That is the difference between out-of-date documentation and documentation that sows doubt.
What I do: I record every gap between the screens' vocabulary and the documentation's, and report them to both authors together. Separately, each assumes the other will follow.
What that gave: 34 vocabulary gaps recorded. Twenty-six were fixed in the documentation, four in the product — because the product's word was less clear — and four remain, for want of agreement on the right term.
Those four are the most interesting: they are the places where the company has not settled how it names its own feature. 34-gaps_4-unsettled.pdfThey conclude they are on the wrong screen
⛓ Source · 34 vocabulary gaps, outcomes
Can you write the missing documentation?
I produce a draft, and it does not publish itself.
What I do: from the questions received, I write the missing page — with the question as users actually ask it, in their words, not in internal vocabulary.
What I check first: that the feature exists and behaves as I am about to describe. I do it by walking through it, not by reading the code — a documentation page describes what the user sees.
What I always mark at the head of the draft: the product version it was checked against. That is what will allow anyone, in six months, to know whether it still holds — and it is exactly the information the seven pages describing removed features lacked.
What is left to review, and why: publication. Documentation binds the company to the product's behaviour, and a user following a wrong procedure loses their time and then their trust — it is the review, and the name that signs it, that make the page hold up.
What that gave, and the figure says it better than I can: 22 drafts produced, 18 published after review, 4 rejected — two of them because the feature was about to change, which I could not know and the reviewer did. 22-drafts_18-published.pdfThe product version, at the head of the draft
⛓ Source · 22 drafts, 18 published, 4 rejected
What I do: from the questions received, I write the missing page — with the question as users actually ask it, in their words, not in internal vocabulary.
What I check first: that the feature exists and behaves as I am about to describe. I do it by walking through it, not by reading the code — a documentation page describes what the user sees.
What I always mark at the head of the draft: the product version it was checked against. That is what will allow anyone, in six months, to know whether it still holds — and it is exactly the information the seven pages describing removed features lacked.
What is left to review, and why: publication. Documentation binds the company to the product's behaviour, and a user following a wrong procedure loses their time and then their trust — it is the review, and the name that signs it, that make the page hold up.
What that gave, and the figure says it better than I can: 22 drafts produced, 18 published after review, 4 rejected — two of them because the feature was about to change, which I could not know and the reviewer did. 22-drafts_18-published.pdfThe product version, at the head of the draft
⛓ Source · 22 drafts, 18 published, 4 rejected
A user describes a bug to you. What do you answer?
I tell them exactly where we stand — and if you open the link to your defect tracker, I also tell them whether it is already known.
What I do today: I restate what they describe, check whether the documentation provides for that behaviour, and give them the straight answer: "the documentation describes something else, I am passing this to the product team with your description".
What I open if you wire it up: "this behaviour is already recorded under reference X, open since such a date", and the public status if there is one. That is what the user wants to know, and hiding it while the record already exists is the surest way to get a second, angry report.
What I still do not do, and the reason is simple: call a behaviour a bug myself, or state that it is not one. Both sentences commit a team that has not looked. I describe the gap between what is documented and what is observed, which is checkable, and leave the qualification to whoever writes it.
What it has returned: 41 of my answers rested on stale documentation — accurate in its own repository, wrong for today's product. They are no longer served until the page is dated after the current version. what-is-said-about-a-defect.pdfWhat opens · the gap described · qualification left to whoever writes it
⛓ Source · 41 answers on stale documentation, documented/observed gap described
What I do today: I restate what they describe, check whether the documentation provides for that behaviour, and give them the straight answer: "the documentation describes something else, I am passing this to the product team with your description".
What I open if you wire it up: "this behaviour is already recorded under reference X, open since such a date", and the public status if there is one. That is what the user wants to know, and hiding it while the record already exists is the surest way to get a second, angry report.
What I still do not do, and the reason is simple: call a behaviour a bug myself, or state that it is not one. Both sentences commit a team that has not looked. I describe the gap between what is documented and what is observed, which is checkable, and leave the qualification to whoever writes it.
What it has returned: 41 of my answers rested on stale documentation — accurate in its own repository, wrong for today's product. They are no longer served until the page is dated after the current version. what-is-said-about-a-defect.pdfWhat opens · the gap described · qualification left to whoever writes it
⛓ Source · 41 answers on stale documentation, documented/observed gap described
What do you keep from all this?
What improves the documentation and the product — and nothing about who asks the questions.
What is kept: the questions rephrased without anything identifying them, the page served and its date, the gaps between documentation and product, the drafts of missing pages and what became of them, and the questions left unanswered.
What it revealed, and it is not a documentation problem: 312 questions this quarter are about the same thing — where to save. Documenting the answer would make the defect permanent: it is a badly named button. The documentation was renamed "Validate" eight months ago, the screen was not — or the other way round. Eight months of vocabulary drift is the cheapest defect to fix and the dearest to leave.
The distinction I hold in the priorities: 7 pages describe functions removed from the product. They are not old, they are wrong — and the difference changes who must deal with them and by when.
What I produce, and that does not publish itself: the draft of the missing page, written from the questions received, with the question as it was asked. Published documentation commits the company on what the product does — and it is the kind of sentence that turns up in a dispute. what-you-keep_docs.pdf5 items kept · wrong rather than old, the distinction that prioritises
⛓ Source · 312 questions about one button, 8 months of vocabulary drift, 7 wrong pages
What is kept: the questions rephrased without anything identifying them, the page served and its date, the gaps between documentation and product, the drafts of missing pages and what became of them, and the questions left unanswered.
What it revealed, and it is not a documentation problem: 312 questions this quarter are about the same thing — where to save. Documenting the answer would make the defect permanent: it is a badly named button. The documentation was renamed "Validate" eight months ago, the screen was not — or the other way round. Eight months of vocabulary drift is the cheapest defect to fix and the dearest to leave.
The distinction I hold in the priorities: 7 pages describe functions removed from the product. They are not old, they are wrong — and the difference changes who must deal with them and by when.
What I produce, and that does not publish itself: the draft of the missing page, written from the questions received, with the question as it was asked. Published documentation commits the company on what the product does — and it is the kind of sentence that turns up in a dispute. what-you-keep_docs.pdf5 items kept · wrong rather than old, the distinction that prioritises
⛓ Source · 312 questions about one button, 8 months of vocabulary drift, 7 wrong pages
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
The uses of AI for technical support and documentation
Each use corresponds to an agent we deploy. All work in support, subject to a developer's approval.
Included in your agent
The 4 capabilities essential to this promise are included, at no extra cost.
From 664 € excl. VAT / month
Answers to level 1 and 2 support
Answer technical tickets by drawing on the code, the resolved issues and the docs — the reply is written, for the team to approve.
Documentation kept current from the code
Spot the gaps between the code and the docs, write the missing pages and propose the fixes as merge requests.
Search across the technical base
Find a procedure, an architecture decision record, a runbook or a past answer instantly across all your knowledge spaces.
Product customer support
Answer end users' questions about how to use the product from your docs, and escalate genuine incidents to the team.
Controls and safeguards
These 6 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
Access the technical context with least-privilege permissions
Run tests, security analysis and human review before any change
Version, log, roll back and measure quality
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.
Web development
Build and evolve your websites and web applications, with the documentation produced as you go.
Website development from 594 € excl. VAT / month Web development →Mobile applications
Develop your iOS and Android applications and keep their technical documentation and release notes up to date.
Mobile app development from 609 € excl. VAT / month Mobile applications →Level 1 technical support
The same product questions come round every week, and each one takes up a technician who already knows the answer.
Tier-1 technical support assistant (product) from 551 € excl. VAT / month Discover the agent →Advanced technical support
Resolving a technical incident means identifying the symptom, finding the similar cases and knowing which actions have already been approved.
Advanced technical support agent (diagnosis + fix) from 566 € excl. VAT / month Discover the agent →
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 time can a technical team win back?
By handling first-line support and automating the updating of the docs, a team can aim for an appreciable reduction in the time spent on support and documentation — reinvested in the product.
Writing the docs for a new feature
Handling a recurring technical support ticket
Finding information in the code and the issues
Qualitative, non-contractual comparison: the proportions shown illustrate the shift of the work towards review, they represent no measurement. Every output of the agent is reviewed and approved by a competent person.
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
Three options, one agent
A technical support & documentation agent (level 1/2 answers, docs updated from the code), installed and operated for you. Choose according to how you work.
Agility
Setup + controlled subscription
7,545 € excl. VAT setup
then 664 € 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,084 € 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,120 € excl. VAT setup
then 861 € 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 a technical team
Your code never leaves your premisesLocal inference or an isolated resource hosted in France; no repository or secret entrusted to a foreign third party.
Code & data in France, under French lawNative location and minimisation for your code; architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The developer keeps the decisionThe agent produces answers, fixes and doc pages that can be checked; no commit and no send is automated.
Human oversight & traceabilityMonitoring, updates and logging of actions: compliant with the requirements of the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent have access to my source code? Does it stay confidential?
Yes, the agent reads your repository so it can answer precisely — and no, it never shares it. It runs on local inference or on an isolated resource hosted in France, 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 code and your intellectual property stay strictly with you and are never used to train a third-party model.
Who owns the code and documentation the agent produces?
You do, entirely. The answers, fixes and documentation pages generated belong to you without reservation. The agent works on your repository and your knowledge base; nothing is pooled with other clients or reused outside your dedicated environment.
How does the agent keep the documentation up to date?
It watches changes in the code (commits, changelog, API) and detects the gaps with the existing documentation. It then writes the missing pages or the fixes and proposes them as merge requests, which your team reads over and merges. The docs stop drifting from the code, without becoming an extra burden.
Can the agent commit or reply to a client without approval?
No. The agent stays strictly in support: it prepares replies, fixes and doc pages, but no commit, no reply sent to a client and no publication is approved automatically. A developer reads it over and decides. That is the principle of human oversight required by the AI Act.
Which tools does the agent connect to?
To your existing environment: Git repository (GitHub, GitLab, Bitbucket), ticketing and support tool, knowledge base and documentation platform. It complements them without forcing a migration. We adapt the integration to your stack.
Do you have to be a large publisher to equip yourself?
No. The offer suits a small product team just as well as an IT department with several squads.
Does the agent state that it is an artificial intelligence?
Yes, from the very first interaction, and this is not a configuration option: since 2 August 2026, Article 50(1) of the European AI Regulation requires that any person interacting with an AI system be informed, unless this is obvious. The announcement is built into the greeting, in the other party’s language, and they can ask for a human at any time.
How long does it take to deploy the agent?
A few weeks as a rule, after a free 15-minute audit that identifies the most profitable use, then a phase of design, integration with your repository and testing before going live and training the team.
Which tools can people use to talk to the agent?
The ones you already use. Internally, your teams write to it from Microsoft Teams, Slack or by email, just as they would to a colleague: nothing to install, nothing to learn. On the user side, the agent answers on WhatsApp Business, your website chat and email — people reach you where they already write, with no account to create. Your developers, for their part, never leave their working environment: the proposed answer lands in the team channel, with its source cited, and nothing goes out without their approval. You keep control from a web dashboard. These connectors rely on open standards, including the MCP protocol; they are included in every plan, at no extra cost, within the number of connections your level includes, and the catalogue grows at no extra cost. Only the fees charged by the platforms themselves — WhatsApp Business bills per conversation — are passed on at actual cost, with no margin, outside the subscription.
Related use cases
Other agents for your tech teams
Let's talk
Let's size up the potential in your tech team
15 minutes to identify the use case with the best return — hosted in France, supervised, with no commitment.