Features
From request to result, inside your software.
An action carried out by the agent is not just another answer: it is a real effect in your application, with its audit trail and its safeguards.
What is never rounded up
A useful agent is one whose reports you can believe. These distinctions are held all the way into the interface.
Success comes from the server
An action is only reported as successful once the application has confirmed it. An animation or an optimistic message is not proof.
A refusal is a refusal
When a permission is missing or a business rule stands in the way, the agent says so and explains what blocks it, instead of working around it or staying vague.
A partial result is named
Across a batch, processed items and failed ones are distinguished. No half-success is presented as a success.
Uncertainty is stated
When the agent cannot confirm the final state, it says so rather than picking the most flattering version.
How a request travels
These four stages are always distinct, whatever the task. That is what makes it possible to know where the work stands.
- 01
The request
The user states their intent in plain language. The agent receives a reference to the current screen or record, not a copy of everything on display.
- 02
The proposal
The agent states what it proposes to do: the records involved, the intended change, the known cost if there is one. Nothing is committed at this stage.
- 03
The approval
Depending on the autonomy level set for that capability, the action proceeds directly or asks for confirmation. Widening the scope requires a new decision.
- 04
The result
The effect appears in the application. The agent states precisely what happened: success, partial result, refusal or failure.
The capabilities open to the agent are those your application exposes and you authorise. They are defined during pilot scoping, capability by capability.