AI Agent
We design process automation with clear roles for the application, selected AI tasks and the people responsible for decisions.
Before automating, we establish the participants, data sources, bottlenecks, exceptions, possible failures and intended outcome. When a task follows a clear rule, application logic may be simpler, faster and more predictable than AI.
| Participant | Example responsibility | |---|---| | Application | identity, permissions, validation, calculations, process state and authorised actions | | AI | proposed categories and document values, summaries and reply drafts | | Authorised person | exceptions, corrections and responsibility for required approvals |
This is an example allocation, not a universal architecture. The scope depends on data, consequences and business requirements. Generating a proposal does not change the case record.
Consider a hypothetical customer-support process. The application records a message and assigns it under existing rules. AI prepares a summary and reply draft, which an employee checks against the original and edits where necessary.
For an invoice, AI might propose extracted fields. The application checks formats, amounts, business rules and potential duplicates. An authorised person verifies the data through the existing approval process.
Other hypothetical uses include organising sales enquiries before a CRM update and preparing a new employee’s checklist from approved information. AI does not independently grant access, approve payments or make binding decisions in these examples.
Application: record the request and check access
|
+-- AI: proposal -> application validates output
|
+-- valid -> employee reviews / edits
| -> validate and store proposal and review
|
+-- invalid / unavailable -> agreed exception path
(e.g. manual handling)
Subsequent action, such as sending a reply:
approved proposal + permissions + business rules
-> existing application performs the actionThe application validates corrections too. Storing the proposal and review does not send the reply; a rejected proposal is not applied.
Keep the original document or request, the AI proposal and the reviewed or approved result separate. Task status identifies pending work, completion and failures. A queue lets longer tasks run in the background so submitting a request need not wait for its result. A queue alone does not make execution reliable.
Timeouts, an unavailable provider and invalid output are failures, not successful results. Retries are bounded and reserved for temporary errors.
Idempotency means repeating the same operation without duplicating its effects. A case number alone is insufficient: an operation key, such as case, task and data version, needs a durable execution record. A database uniqueness rule and an indivisible write prevent concurrent tasks from creating duplicate execution records. They do not guarantee a single provider call; the provider’s duplicate-handling behaviour needs separate verification.
Design and test manual handling for the specific process, including what can finish without AI and what must wait.
Send AI only the data it needs. The application enforces user and organisation access boundaries, validates results and records important decisions in an audit trail. A high confidence score proves neither accuracy nor permission to act. Human review supports these safeguards; it does not replace them.
At GiSoft, we begin with a limited scope. We measure handling time, employee corrections, accepted proposals, failures and cost per completed case. Comparison with the existing process informs whether to expand automation, change its rules or remove the AI-assisted step.