Features
An agent that improves through real use.
Vigie looks at how the agent is actually used in your application — what gets done, what blocks, what keeps coming back — and turns those findings into verified improvements. It is a continuous usage feedback loop on your own product.
What Vigie does
Every day, outside your users’ sessions, Vigie re-reads what the agent did: the requests received, the answers given, the corrections users made, the actions carried out and their effects in the application. It cross-references these signals to spot recurring difficulties and unmet needs.
Each finding comes with its evidence — the conversations involved, the actions concerned, the effects observed — and a hypothesis about the cause: an instruction misunderstood, information missing from the sources, a permission set too tight, a feature missing from the application itself.
It also shows its coverage: what was analysed, what is pending, what could not be analysed. Silence is never read as satisfaction.
What it spots
Six families of findings, each tied to specific conversations and actions.
Recurring questions
The same request phrased ten ways by different users points to information to make accessible, or a shortcut to create.
Abandoned tasks
A request started then dropped at the same point by several people marks the step where the agent loses the user.
Feasible requests refused
A refusal when the feature exists and the permission is open is a defect, not caution. Vigie tracks them as such.
Repeated corrections
When users keep fixing the same thing — a date, a wording, a preference not applied — the agent has to change, not them.
Missing or poorly used sources
An answer that fails for lack of a document, or cites the wrong one, reveals a gap in the sources or chunking to revisit.
What your application lacks
Some requests cannot be served because the feature does not exist. For a software vendor, that is a roadmap written from real usage.
What you see
Vigie is not a monthly report: its findings and improvements are visible as they happen, at three levels.
For your users
Their work in progress, what the agent has kept for them, the tasks handed over and their status.
For your organisation
Usage, results, costs and quality per team; open findings, selected improvements and their measured effect.
For operations
Analysis coverage — eligible, analysed, pending, not analysable —, incidents and versions. No green light when the denominator is unknown.
Three safeguards
Nothing changes without your approval
Improvements are decided, tested and switched on with your agreement. An authorised memory correction may be automatic; a shared behaviour change is always versioned and reversible.
We observe usage, not people
The analysis is about usage difficulties and action outcomes, never about rating users. The scope of analysed data is defined with you.
Nothing travels between customers
A finding born at one customer carries neither its content nor its data to another. What is shared is a product fix, versioned and documented.
From finding to improvement
Each step produces something observable and stays linked to the previous one: an improvement can always be traced back to the finding that motivated it, and rolled back if it regresses.
- 01
Observe
Daily analysis of authorised conversations, requests, corrections, actions and effects, at a cadence and budget you set.
- 02
Record, with evidence
Group the signals, discard the noise, open a sourced and prioritised finding. Some findings conclude that no change is desirable.
- 03
Propose a fix
Depending on the cause: an adjusted instruction, a source added or re-chunked, a permission to open, documentation completed, a tool evolution — or a feature to add to your application.
- 04
Test
The candidate fix goes through the real execution path, with the case that motivated it and adversarial cases. What fails validation does not ship.
- 05
Release and measure
Controlled, versioned rollout with rollback available. The effect is tracked on subsequent usage; an improvement with no observable effect is reconsidered.
Today: spotting and sorting difficulties works in BANANA-CONTENT, in real use. The full loop — finding linked to fix, to its verification and to the measurement of its effect — is set up on the workflows chosen with you during the pilot.