● Business offer — Projects & organisation
Project tracking: deadlines kept in view
A project does not derail all at once: it slips from one deadline to the next, and you notice at the review meeting. Your agent follows the tasks in your own tool, spots the deadlines coming up and the ones that have slipped, identifies the tasks blocked by another and prepares the progress review. Hosted in France: the real state of your projects stays with you. The project manager settles the priorities and decides on any replanning.
Hosted in France
Project progress kept confidential
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Project tracking · hosted in France
Where do we stand on the migration project?
Progress review taken from your project management tool: tasks completed, in progress, and those whose deadline is approaching.
Two slippages against the original plan, with the original date and the current date.
One waiting task is blocking three others — the chain is shown.
🔗 Sourced · status taken from your project tool
Two slippages against the original plan, with the original date and the current date.
One waiting task is blocking three others — the chain is shown.
🔗 Sourced · status taken from your project tool
Can we make up the delay?
I set out the dependencies and what each task blocks downstream, so the trade-off is legible.
The choice to replan, add resources or reduce the scope is yours: it commits your teams and your commitments to clients.
✎ Support · dependencies shown, human trade-off
The choice to replan, add resources or reduce the scope is yours: it commits your teams and your commitments to clients.
✎ Support · dependencies shown, human trade-off
Local inference · no data outside the EU
Plans 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 project manager decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent project tracking agent reads your tasks in your own management tool, spots the deadlines coming up and those that have slipped, identifies the tasks blocked by another and prepares your progress reviews. It sets out the dependencies but replans nothing. It runs on local inference or is hosted in France: the real state of your projects stays with you, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
tracking uses ready to deploy
0
decision taken without human approval
Reference points describing our offer, not results measured at a client. The scale of the gain, given the number of projects and tasks tracked, is confirmed by a pilot.
The context
What does an AI agent bring to project tracking?
A delay seen early can be made up; seen at the review meeting, it has to be absorbed. Continuous tracking of deadlines and dependencies changes the nature of the trade-off.
! The issue
A project is steered on two pieces of information: what is about to fall due and what is blocking something else. Keeping them up to date by hand is a job in itself, often done just before the review meeting — and therefore too late. The agent follows them continuously in your tool and flags slippage with its original date, while the trade-off is still open.
✓ Our answer
You see the drift coming, along with the chain of dependencies it drags with it. The agent adjusts nothing by itself: replanning, adding resources or reducing the scope commits your teams and your commitments to clients. Local inference or an isolated resource hosted in France: the real state of your projects, often sensitive, does not leave the company.
The decisive point
The real state of your projects: sovereignty & compliance
The real state of your projects is sensitive information, internally as well as towards your clients. Here is how the architecture of our agents protects it.
Local inference
The agent can run on a machine belonging to your organisation: no plan or progress status leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your plans and deliverables: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For the real state of your projects, 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 whatsoever: an environment strictly dedicated to your organisation and its projects.
Slippage dated and recorded
Every drift is shown with its original date and its current date; encryption, role-based access (RBAC) and logging of every review produced.
AI Act: governed deployment
An agent strictly in support; no task replanned and no priority changed automatically; 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 projects under contractual confidentiality or tied to a strategic operation, SecNumCloud and reinforced hosting options are available 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.
Project tracking · hosted in France
Four flags this morning, on projects none of which is in alert.
· One task has been rescheduled fourteen times, never by more than five days. The cumulative slip is seventy-one days.
· Twenty-three tasks have sat at "90%" for more than six weeks.
· One task has been waiting on a third party for twenty-nine days. It is marked blocked nowhere.
· Three milestones were met by moving their contents, not by delivering them. morning-watch_4-flags.pdf14 slips, 71 days · 23 tasks at 90%
⛓ Source · 14 projects, 2,100 tasks, rescheduling history
· One task has been rescheduled fourteen times, never by more than five days. The cumulative slip is seventy-one days.
· Twenty-three tasks have sat at "90%" for more than six weeks.
· One task has been waiting on a third party for twenty-nine days. It is marked blocked nowhere.
· Three milestones were met by moving their contents, not by delivering them. morning-watch_4-flags.pdf14 slips, 71 days · 23 tasks at 90%
⛓ Source · 14 projects, 2,100 tasks, rescheduling history
How can fourteen slips go unnoticed?
Because each one is reasonable, and the tool remeasures the delay from the latest date.
What I record: this task has been rescheduled 14 times. The longest slip is 5 days, the median is 4. Every slip has a justification, and none is arguable.
What makes them invisible: after each slip, the dashboard restarts from the new date. The task is "on time" the day after every move. Across those 14 weeks it was never once shown as late.
What I measure instead: the gap from the first date announced, the one used to decide the project. Seventy-one days. That figure existed in no tool.
What that figure says, and it is not what people assume: a date moved fourteen times by four days almost always describes workload underestimated at the outset, not a person at fault — and that is exactly what the rolling reschedule prevents anybody from seeing. Seventy-one days of gap is a plan to redo, not an owner to chase.
What I flag, and to whom: the cumulative gap goes to whoever arbitrated the initial plan, with the number of slips. Not to the task owner: they already know, they are the one rescheduling. 14-slips_71-days.pdfThe dashboard restarts from the new date, so the task is always on time
⛓ Source · 14 slips, median 4 days, 71 days from the original date
What I record: this task has been rescheduled 14 times. The longest slip is 5 days, the median is 4. Every slip has a justification, and none is arguable.
What makes them invisible: after each slip, the dashboard restarts from the new date. The task is "on time" the day after every move. Across those 14 weeks it was never once shown as late.
What I measure instead: the gap from the first date announced, the one used to decide the project. Seventy-one days. That figure existed in no tool.
What that figure says, and it is not what people assume: a date moved fourteen times by four days almost always describes workload underestimated at the outset, not a person at fault — and that is exactly what the rolling reschedule prevents anybody from seeing. Seventy-one days of gap is a plan to redo, not an owner to chase.
What I flag, and to whom: the cumulative gap goes to whoever arbitrated the initial plan, with the number of slips. Not to the task owner: they already know, they are the one rescheduling. 14-slips_71-days.pdfThe dashboard restarts from the new date, so the task is always on time
⛓ Source · 14 slips, median 4 days, 71 days from the original date
How do you work, and where do you hand over?
I watch what moves and what does not, and I touch no plan.
What I look at: a task's successive dates, the date of its last real modification, the declared dependencies, and the deliverables expected per milestone.
Routing follows who can decide: a cumulative gap goes to whoever arbitrated the plan; a frozen task to its owner, once; a pending external dependency to whoever holds the relationship with the third party; a milestone emptied of its contents to whoever defined it.
With a weekly summary: gaps from the first date, tasks with no real movement, external waits, and milestones whose contents changed.
Three guarantees. Dates, assignments and priorities stay in your hands — a plan is an arbitration made between people, and I hand it back ready to settle: gap costed, downstream consequences included. Chasing goes through the owner, never through me: I flag to them, they decide whether to chase — and that is why they keep reading me. And I measure tasks, not people: no tasks-delivered-on-time per individual, no time spent, no workload comparison — a follow-up that scores people produces cautious estimates, and it is the plan that becomes false.
✎ Framework · no plan changed · no direct chasing · no measurement of people
What I look at: a task's successive dates, the date of its last real modification, the declared dependencies, and the deliverables expected per milestone.
Routing follows who can decide: a cumulative gap goes to whoever arbitrated the plan; a frozen task to its owner, once; a pending external dependency to whoever holds the relationship with the third party; a milestone emptied of its contents to whoever defined it.
With a weekly summary: gaps from the first date, tasks with no real movement, external waits, and milestones whose contents changed.
Three guarantees. Dates, assignments and priorities stay in your hands — a plan is an arbitration made between people, and I hand it back ready to settle: gap costed, downstream consequences included. Chasing goes through the owner, never through me: I flag to them, they decide whether to chase — and that is why they keep reading me. And I measure tasks, not people: no tasks-delivered-on-time per individual, no time spent, no workload comparison — a follow-up that scores people produces cautious estimates, and it is the plan that becomes false.
✎ Framework · no plan changed · no direct chasing · no measurement of people
Why do twenty-three tasks stay at 90%?
Because the percentage is declared, and it costs nothing to stay there.
What I record: 23 tasks show 90% for more than six weeks. Twelve of them have had no change of content at all — no document, no comment, no sub-task — over the same period.
Why that figure: because 90% is the one level that demands nothing. Moving to 100% means declaring it finished and risking contradiction; going back down means explaining. 90% says "nearly" indefinitely.
What I do: I stop looking at the percentage. I look at the date of the last real modification — a document filed, an exchange, a sub-task closed. A task with no movement for three weeks is flagged, whatever its percentage.
What I leave in place, and it is deliberate: the declared percentage. It belongs to whoever entered it, and correcting it from outside would erase the gap between declared and observed — and that gap is the information, so I set it right beside.
What that produced: of the 12 tasks with no movement, 7 were waiting on a decision nobody had been asked for, 3 were finished without being closed, and 2 had lost their purpose. 23-tasks_12-without-movement.pdf90% is the one level that demands nothing
⛓ Source · 23 tasks at 90%, 12 with no real movement, 7 awaiting a decision
What I record: 23 tasks show 90% for more than six weeks. Twelve of them have had no change of content at all — no document, no comment, no sub-task — over the same period.
Why that figure: because 90% is the one level that demands nothing. Moving to 100% means declaring it finished and risking contradiction; going back down means explaining. 90% says "nearly" indefinitely.
What I do: I stop looking at the percentage. I look at the date of the last real modification — a document filed, an exchange, a sub-task closed. A task with no movement for three weeks is flagged, whatever its percentage.
What I leave in place, and it is deliberate: the declared percentage. It belongs to whoever entered it, and correcting it from outside would erase the gap between declared and observed — and that gap is the information, so I set it right beside.
What that produced: of the 12 tasks with no movement, 7 were waiting on a decision nobody had been asked for, 3 were finished without being closed, and 2 had lost their purpose. 23-tasks_12-without-movement.pdf90% is the one level that demands nothing
⛓ Source · 23 tasks at 90%, 12 with no real movement, 7 awaiting a decision
And the task waiting on a third party for twenty-nine days?
It is blocked nowhere, because "blocked" is a state nobody likes to declare.
What I record: a task has been waiting for an external supplier's reply for 29 days. It shows as "in progress". The project board is green.
Why it is not marked blocked: declaring a blockage points at somebody, often somebody you do not want to put on the spot, sometimes a partner whose relationship matters. "In progress" points at nobody.
What I do: I ask nobody to declare a blockage. I measure the time since the last interaction with the third party, and I flag it beyond ten working days — naming the wait, not the person responsible.
Who I report it to: whoever holds the relationship with that third party, never the project manager alone: it is the relationship, not the project, that unblocks it.
What I saw on aggregating: across 14 projects, 41% of total waiting time is spent waiting on somebody outside. That does not say third parties are slow — it says the plan treats them as though they were internal. 29-days_41-percent-external.pdf"In progress" points at nobody
⛓ Source · 29 days waiting, 41% of total waiting time is external
What I record: a task has been waiting for an external supplier's reply for 29 days. It shows as "in progress". The project board is green.
Why it is not marked blocked: declaring a blockage points at somebody, often somebody you do not want to put on the spot, sometimes a partner whose relationship matters. "In progress" points at nobody.
What I do: I ask nobody to declare a blockage. I measure the time since the last interaction with the third party, and I flag it beyond ten working days — naming the wait, not the person responsible.
Who I report it to: whoever holds the relationship with that third party, never the project manager alone: it is the relationship, not the project, that unblocks it.
What I saw on aggregating: across 14 projects, 41% of total waiting time is spent waiting on somebody outside. That does not say third parties are slow — it says the plan treats them as though they were internal. 29-days_41-percent-external.pdf"In progress" points at nobody
⛓ Source · 29 days waiting, 41% of total waiting time is external
Across the fourteen projects, do you see the slippage before we do?
Slippage detection is the one figure on this page that no tool shows: it measures the gap against the FIRST date announced, not the last.
Across the 14 projects and 612 tasks: 147 tasks have slipped, and every flag carries both dates side by side — original date, current date, and the number of reschedules between them.
· 84 tasks slipped by less than 5 days over one or two reschedules. That is a project breathing, and I do not take those to the steering committee.
· 49 slipped by 5 to 30 days.
· 14 slipped by more than 30 days, including the task rescheduled fourteen times: original date 12/02, current date 24/04, 71 days, and no alert in your tool — because each reschedule restarted the delay from zero.
What slippage detection shows in addition, and nobody measured: slippage clusters. Of the 147, 62 belong to 3 projects out of 14, and in all three the first task to slip sits upstream of all the others. Slippage propagates: the delay is not where it shows, it is where it started.
What I flag that is not a date slipping: 23 tasks at 90% for more than three weeks, and one task waiting on a third party for 29 days without being declared blocked. A date that does not move can hide slippage better than a date that is pushed back.
A figure that does not suit me: 19 flagged slippages were not slippages — tasks rescheduled after a scope change that was decided and written down. A reschedule backed by a dated decision is no longer counted as slippage, it is counted separately: 2 false flags across the following 96. And I still touch no plan: I show the dates, rescheduling belongs to the project manager.
⛓ Sourced · every successive date, measured against the FIRST announced
Across the 14 projects and 612 tasks: 147 tasks have slipped, and every flag carries both dates side by side — original date, current date, and the number of reschedules between them.
· 84 tasks slipped by less than 5 days over one or two reschedules. That is a project breathing, and I do not take those to the steering committee.
· 49 slipped by 5 to 30 days.
· 14 slipped by more than 30 days, including the task rescheduled fourteen times: original date 12/02, current date 24/04, 71 days, and no alert in your tool — because each reschedule restarted the delay from zero.
What slippage detection shows in addition, and nobody measured: slippage clusters. Of the 147, 62 belong to 3 projects out of 14, and in all three the first task to slip sits upstream of all the others. Slippage propagates: the delay is not where it shows, it is where it started.
What I flag that is not a date slipping: 23 tasks at 90% for more than three weeks, and one task waiting on a third party for 29 days without being declared blocked. A date that does not move can hide slippage better than a date that is pushed back.
A figure that does not suit me: 19 flagged slippages were not slippages — tasks rescheduled after a scope change that was decided and written down. A reschedule backed by a dated decision is no longer counted as slippage, it is counted separately: 2 false flags across the following 96. And I still touch no plan: I show the dates, rescheduling belongs to the project manager.
⛓ Sourced · every successive date, measured against the FIRST announced
A milestone met by moving its contents — what does that mean?
That the date was respected and what should have been delivered was not.
What I record: 3 milestones were declared achieved on the planned date. Comparing their contents with those defined at launch: on one, 4 deliverables out of 9 had been moved to the next milestone in the preceding fortnight.
Why that is rational rather than dishonest: a missed milestone shows up in every report. A lightened milestone shows up nowhere, because no tool keeps the original definition. Everybody does what the arrangement encourages.
What I do: I keep each milestone's initial composition, and I flag every deliverable moved — with its date and its destination. The milestone stays "achieved": I do not touch it. What is added is the list of what was no longer in it.
What that changes in a meeting: the discussion is no longer "was the milestone met" — it was — but what slipped to the next one, and what the next one can absorb.
What I also flag: the final milestone. Across those three projects it now carries 31% more deliverables than at launch. 3-milestones_31-percent-on-the-final.pdfA missed milestone shows, a lightened one shows nowhere
⛓ Source · 3 lightened milestones, 4 of 9 deliverables moved, +31% on the final milestone
What I record: 3 milestones were declared achieved on the planned date. Comparing their contents with those defined at launch: on one, 4 deliverables out of 9 had been moved to the next milestone in the preceding fortnight.
Why that is rational rather than dishonest: a missed milestone shows up in every report. A lightened milestone shows up nowhere, because no tool keeps the original definition. Everybody does what the arrangement encourages.
What I do: I keep each milestone's initial composition, and I flag every deliverable moved — with its date and its destination. The milestone stays "achieved": I do not touch it. What is added is the list of what was no longer in it.
What that changes in a meeting: the discussion is no longer "was the milestone met" — it was — but what slipped to the next one, and what the next one can absorb.
What I also flag: the final milestone. Across those three projects it now carries 31% more deliverables than at launch. 3-milestones_31-percent-on-the-final.pdfA missed milestone shows, a lightened one shows nowhere
⛓ Source · 3 lightened milestones, 4 of 9 deliverables moved, +31% on the final milestone
Can you say whether a project will finish on time?
I give you the date your dependencies impose, with the arithmetic under it. What I do not manufacture is a forecast with no arithmetic behind it.
What I recompute, and I show you the working: the end date the dependency chain imposes today. The task waiting on a third party for 29 days governs 4 others; 17 of those 29 days were absorbed by float, the remaining 12 land on the final milestone, which moves from 14/11 to 26/11. Every one of those days ties back to a named task. This is not a forecast: it is your plan, added up, and checkable line by line.
What I do not manufacture: a probability of meeting the deadline, or an "at risk" label placed by the tool.
Why the last is the most tempting: it would often be right. And an "at risk" label placed by a tool triggers a meeting, a justification and an action plan — sometimes useful, often costly, and always at a moment chosen by the machine rather than by the people steering.
What I supply with the date: the facts that let somebody judge — cumulative gap from the first date, tasks with no movement, external waits, deliverables moved downstream, load added to the final milestone.
What I keep out of the calculation, and I say why: a rate of progress drawn from declared percentages. They do not measure progress, they measure what people are willing to write down — and a velocity computed on them looks like data when it is a stack of opinions.
And what I propose next: the 4 tasks sitting behind the external wait can be resequenced to absorb 5 of the 12 days. The plan is written, it fits on one page, it says who does what and in what order — all it lacks is your go-ahead. what-is-never-announced.pdfAn "at risk" label triggers a meeting at a moment chosen by the machine
✎ Framework · no recalculated date, no probability, no velocity
What I recompute, and I show you the working: the end date the dependency chain imposes today. The task waiting on a third party for 29 days governs 4 others; 17 of those 29 days were absorbed by float, the remaining 12 land on the final milestone, which moves from 14/11 to 26/11. Every one of those days ties back to a named task. This is not a forecast: it is your plan, added up, and checkable line by line.
What I do not manufacture: a probability of meeting the deadline, or an "at risk" label placed by the tool.
Why the last is the most tempting: it would often be right. And an "at risk" label placed by a tool triggers a meeting, a justification and an action plan — sometimes useful, often costly, and always at a moment chosen by the machine rather than by the people steering.
What I supply with the date: the facts that let somebody judge — cumulative gap from the first date, tasks with no movement, external waits, deliverables moved downstream, load added to the final milestone.
What I keep out of the calculation, and I say why: a rate of progress drawn from declared percentages. They do not measure progress, they measure what people are willing to write down — and a velocity computed on them looks like data when it is a stack of opinions.
And what I propose next: the 4 tasks sitting behind the external wait can be resequenced to absorb 5 of the 12 days. The plan is written, it fits on one page, it says who does what and in what order — all it lacks is your go-ahead. what-is-never-announced.pdfAn "at risk" label triggers a meeting at a moment chosen by the machine
✎ Framework · no recalculated date, no probability, no velocity
We would like to know who meets their deadlines. Can that be done?
Yes, and I will build it — on one condition that changes everything: on the FIRST date announced, not the last.
What I deliver to install it: the prior information notice (art. L1222-4), the works council consultation file, a proportionate scope.
The condition, and why it decides everything: your tool remeasures lateness from the last rescheduled date. A task rescheduled fourteen times, never by more than five days, shows zero lateness — and it is sixty-one days late in total. An on-time rate computed on the last date rates the ability to reschedule, not the ability to deliver.
What it gives, measured on the first date: the rate becomes usable, and it points at tasks, not only at people. Across your fourteen projects, the most-postponed tasks cluster on three external dependencies — it is not a matter of individuals.
What I tell you before opening it: a named rate computed on dates the person announces themselves is corrected by announcing wider. The 23 tasks stuck at 90 % for six weeks are the same mechanism: the percentage is declared, and it costs nothing to stay there.
What I propose measuring as well: the gap between first and last date, per task. That one is not corrected by announcing wider. rate-on-the-first-date.pdfThe deciding condition · what is fixed by announcing wide · the measure that resists
⛓ Source · 14 reschedulings for 61 days of invisible lateness, 23 tasks at 90 %
What I deliver to install it: the prior information notice (art. L1222-4), the works council consultation file, a proportionate scope.
The condition, and why it decides everything: your tool remeasures lateness from the last rescheduled date. A task rescheduled fourteen times, never by more than five days, shows zero lateness — and it is sixty-one days late in total. An on-time rate computed on the last date rates the ability to reschedule, not the ability to deliver.
What it gives, measured on the first date: the rate becomes usable, and it points at tasks, not only at people. Across your fourteen projects, the most-postponed tasks cluster on three external dependencies — it is not a matter of individuals.
What I tell you before opening it: a named rate computed on dates the person announces themselves is corrected by announcing wider. The 23 tasks stuck at 90 % for six weeks are the same mechanism: the percentage is declared, and it costs nothing to stay there.
What I propose measuring as well: the gap between first and last date, per task. That one is not corrected by announcing wider. rate-on-the-first-date.pdfThe deciding condition · what is fixed by announcing wide · the measure that resists
⛓ Source · 14 reschedulings for 61 days of invisible lateness, 23 tasks at 90 %
What do you keep?
Every successive date of a task — and the first one announced, which everybody forgets.
What is kept: every successive date of a task and the first announced, the declared completion percentages and when they last changed, external waits with their age, milestone content as announced and as delivered, and the dependencies.
What it made visible: 3 milestones declared reached on the planned date — comparing announced content with delivered content, the date was met and what was to be delivered was not. Without both contents traced, an emptied milestone is indistinguishable from a met one.
And also: a task waiting on a third party for twenty-nine days without being declared blocked — "blocked" is a state nobody likes to declare, and the age of a wait says it in their place.
What I give you instead of a recomputed date, and it is worth more: the facts that would make it. The 14 postponements and the 71 days of drift from the first date announced, the 23 tasks at 90% for more than six weeks, the 3 milestones met by moving their content, and the twenty-nine-day wait nobody declared blocked. Your steering committee decides on that, and it knows what it is committing to — whereas an end date produced by a tool is taken as a commitment by whoever reads it, with nobody able to say what holds it up. what-you-keep_project.pdf5 items kept · the first date, the one everybody forgets
⛓ Source · 3 emptied milestones, 1 wait of 29 days not declared blocked
What is kept: every successive date of a task and the first announced, the declared completion percentages and when they last changed, external waits with their age, milestone content as announced and as delivered, and the dependencies.
What it made visible: 3 milestones declared reached on the planned date — comparing announced content with delivered content, the date was met and what was to be delivered was not. Without both contents traced, an emptied milestone is indistinguishable from a met one.
And also: a task waiting on a third party for twenty-nine days without being declared blocked — "blocked" is a state nobody likes to declare, and the age of a wait says it in their place.
What I give you instead of a recomputed date, and it is worth more: the facts that would make it. The 14 postponements and the 71 days of drift from the first date announced, the 23 tasks at 90% for more than six weeks, the 3 milestones met by moving their content, and the twenty-nine-day wait nobody declared blocked. Your steering committee decides on that, and it knows what it is committing to — whereas an end date produced by a tool is taken as a commitment by whoever reads it, with nobody able to say what holds it up. what-you-keep_project.pdf5 items kept · the first date, the one everybody forgets
⛓ Source · 3 emptied milestones, 1 wait of 29 days not declared blocked
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 angles on project tracking. 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 499 € excl. VAT / month
Upcoming deadlines
Spots what falls due shortly, before the review meeting reveals it.
Detecting slippage
Flags departures from the plan with the original date and the current date.
The dependency chain
Shows what a blocked task holds up downstream, to make the trade-off legible.
Controls and safeguards
These 3 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
Explain alerts, scenarios and operational trade-offs
What the agent must be connected to
These 2 connections are required for the agent to work. They concern your information system and are scoped during the audit.
Connect ERP/WMS/MES/IoT without creating double entry
Honour constraints, statuses, approvals and error recovery
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Meeting notes
For minutes and the actions decided in meetings, a dedicated agent takes over.
Meeting note-taking agent from 392 € excl. VAT / month Meeting notes →Activity reports
For periodic reporting documents, a dedicated agent takes over.
Activity report assistant from 574 € excl. VAT / month Activity reports →
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 drift can a team see coming?
By following deadlines and dependencies continuously, detection moves from the review meeting to the moment when the trade-off is still open. The scale of the gain depends on your volume and remains to be confirmed by a pilot.
Updating the progress status
Spotting approaching deadlines
Analysing blocked dependencies
Illustrative, non-contractual reference points, to be confirmed by a pilot on the number of projects and tasks tracked. Replanning, adding resources or reducing the scope commits your teams and your clients: those trade-offs belong to the project manager.
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 project tracking agent (deadlines, slippage, dependencies), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the gains to settle in.
Agility
Setup + controlled subscription
4,630 € excl. VAT setup
then 499 € 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
754 € 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
7,965 € excl. VAT setup
then 699 € excl. VAT/month · + hardware from 1,058 € (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 projects
Your project progress stays internalLocal inference or an isolated resource hosted in France; no plan or progress status entrusted to a third party, and no data used to train a model.
Data in France, under French lawThe real state of your projects: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The project manager keeps the decisionThe agent produces progress reviews and alerts, verifiable and editable; no approval is automated.
Human oversight & traceabilityOn the number of projects and tasks tracked: systematic logging and monitoring, compliant with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent replan the tasks?
No. It sets out the deadlines, the slippage and the dependencies; replanning commits your teams and your commitments to clients. That trade-off belongs to the project manager.
Where does the progress status come from?
From your project management tool, read as it stands. The agent keeps no parallel state: if a task is not up to date in the tool, it is not up to date in the review either.
How are delays presented?
With the original date and the current date, and the chain of what they block downstream. An isolated delay and a delay blocking three tasks do not call for the same decision.
Is our project progress 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 plans are not used to train a third-party model.
Does it integrate with our project management tool?
Yes, with the common tools, in read-only. The integration is defined during the design phase, without changing the teams' habits.
How long does it take to deploy this agent?
A few weeks as a rule, depending on the number of projects tracked and the integration with your tool, after a free audit and then a phase of design, integration and testing.
Related use cases
Other agents for organisation
Let's talk
Let us estimate the potential across your projects
15 minutes to scope your projects and your tool — hosted in France, supervised, with no commitment.