AI Agent
From business process to working AI agent with clear constraints.
GiSoft does not begin an AI-agent project by asking which model should be connected. That question matters later. The first question is more practical: what work should become easier, faster or more reliable for the people who already run the process?
We look at how the task is performed today: what starts it, who participates, what information is used, where employees spend time, where repeated work appears, where mistakes happen and which decisions require experience. We also define which actions must remain under human control and what a successful result should look like.
A normal example is a customer sending a long technical request. An employee reads the message, identifies the subject, checks the customer history, selects the responsible department, prepares a response and updates the CRM. The useful objective is not simply “create a chatbot”. A better objective may be: reduce the time needed to understand and assign a new request, while keeping the employee responsible for the final classification.
The first production version should have a narrow responsibility that managers and employees can describe without technical language. Good first tasks include preparing a request summary, suggesting a category, extracting fields from a document, finding information in approved documentation, preparing a response draft, comparing a request with an internal procedure, suggesting the next administrative step or highlighting missing information.
“The agent should manage the whole company process” is usually too broad for a safe first release. A smaller responsibility is easier to test, easier to review, safer to introduce, easier to measure and easier to improve later.
Boundaries are part of the design, not a security detail added at the end. For a customer request, the agent may read approved request content, prepare a summary, suggest a category and prepare a response draft. It may not change customer permissions, approve a refund, modify an invoice, delete records, send the final response without approval or access unrelated customer data.
┌──────────────────────────────────────────┐
│ Current company process │
│ │
│ People • Documents • Systems • Decisions │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Process analysis │
│ │
│ Time • Repetition • Errors • Risks │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ One clearly defined AI responsibility │
└────────────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Measurable expected result │
└──────────────────────────────────────────┘In the current process, a customer sends a request, an employee reads the full message, checks the subject, assigns a category, decides priority, selects a team and prepares a response.
With an agent, the existing application still stores the request normally. The agent prepares a summary, suggests category and priority, finds related internal information and prepares a response draft. The employee verifies the proposal, accepts, edits or rejects it, and the existing application continues the normal process.
For example, a company asks for help modernising an old Symfony CRM and integrating it with a new ordering system. The agent may propose:
The employee receives a prepared starting point, not an automatic final decision.
In a manual process, an employee receives a supplier document, opens the PDF, finds the invoice number, copies dates and values, enters them into the system and verifies totals.
With an agent, the employee uploads the document in the existing application. The agent reads the document and proposes invoice number, supplier, issue date, payment date, net amount, tax amount, gross amount and currency. The application validates formats, shows proposed values in the existing form and the employee confirms or corrects them. The existing save process remains unchanged.
Confidence scores do not replace validation. The application still checks whether the supplier exists, whether the invoice is duplicated, whether amounts are valid, whether tax totals match, whether the employee has permission and whether required fields are complete.
Many organisations have procedures, technical instructions, product documentation, onboarding materials, service agreements and internal policies. A knowledge agent can help employees use this material without bypassing access control.
The employee asks a question, the application verifies access, the agent searches only approved materials, prepares an answer with references and the employee opens the source document to verify the information.
If someone asks what information should be collected before estimating a Symfony application upgrade, the answer may mention PHP version, Symfony version, dependencies, test coverage, database size, external integrations, deployment method and business-critical areas. If approved sources do not contain the answer, the agent should say so clearly. It must not invent company procedures.
The agent should receive only the information needed for its task. A complete entity, full database record or unrelated customer history should not automatically be sent to an external AI provider.
Existing application
│
│ Selected information only
▼
Input preparation
│
├── remove unnecessary data
├── verify permissions
└── define expected result
│
▼
AI agent
│
│ Structured proposal
▼
Validation
│
├── required fields
├── allowed values
├── business rules
└── security checks
│
▼
Human review or existing automated rule
│
▼
Existing application stores the approved resultBefore implementation we define what the result should contain. Instead of asking the agent to “analyse this request and tell us what you think”, we define a business structure: summary, category, priority, suggested team, missing information, suggested next step and confidence.
This makes the result easier to validate, display, compare, test and record in audit history.
Not every result should be applied automatically. Low-risk support, such as summarisation, classification, search assistance and draft preparation, can usually be displayed as a suggestion. Medium-risk workflow changes, such as assigning a request, selecting priority or proposing document values, normally require employee review. High-risk decisions, such as financial approval, permission changes, refunds, legal decisions, deletion of records or account suspension, must remain controlled by existing business rules and authorised people.
Agent result
│
▼
What type of action is proposed?
│
┌───┼────────────────┐
│ │ │
▼ ▼ ▼
Low Medium High risk
risk risk
│ │ │
▼ ▼ ▼
Show Employee Existing rules,
as review authorisation
help required and human decisionThe existing application remains responsible for users, permissions, customers, orders, documents, payments, statuses, audit history and final business actions. The controlled agent layer prepares approved data, communicates with the selected AI service, checks whether the answer has the expected structure, handles timeouts, records the result and presents the suggestion for review.
┌─────────────────────────────────────────┐
│ Existing application │
│ │
│ Users • Permissions • Business records │
│ Existing processes • Final decisions │
└───────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Controlled agent layer │
│ │
│ Input • Context • Validation • Audit │
└───────────────────┬─────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Selected AI provider or internal model │
└─────────────────────────────────────────┘This structure makes it possible to change the provider or model later without rebuilding the company application.
GiSoft usually starts with a focused prototype. It should answer whether the task is suitable for AI, whether source data is sufficient, whether suggestions are useful, how often employees correct them, what response time and cost look like, what happens in unusual cases and what data-protection requirements apply.
A prototype is not production implementation. A successful demonstration still needs security work, permission checks, failure handling, tests, audit, monitoring and controlled deployment.
We test more than the ideal case: normal, very short and very long input, incomplete documents, unsupported language, missing source data, invalid agent output, slow response, timeout, repeated request, unavailable service, user without permission, misleading instructions inside content, employee correction and employee rejection.
Expected result
│
├── valid proposal
├── incomplete proposal
├── invalid proposal
├── provider unavailable
└── human rejection
│
▼
Every case has a defined application responseThe agent should improve a process without becoming a new single point of failure.
Agent available
→ suggestion is prepared
→ employee reviews it
→ process continues
Agent unavailable
→ suggestion is marked as unavailable
→ employee uses the normal process
→ existing application continues workingFor non-essential workflows, users must be able to continue manually.
Rollout should be controlled. First the agent is enabled for the project team or administrators, then for selected employees who understand the current process, then for one department or workflow. Only after results are reviewed should the solution be expanded.
Prototype
↓
Internal users
↓
Selected team
↓
One production workflow
↓
Measurement and corrections
↓
Controlled expansionTechnical success is not the same as business value. Useful measures include reduced handling time, accepted suggestions, edited suggestions, rejected suggestions, faster assignment, fewer missing fields, shorter document processing, employee satisfaction, provider failure rate, cost per completed task and cases completed without delay. These values should be compared with the previous process.
An AI agent requires normal software maintenance. Company procedures change, categories change, document formats change, product information changes, providers change, models behave differently, employees identify missing rules and security requirements evolve.
GiSoft maintains the instructions provided to the agent, expected result structure, validation, access permissions, tests, source documentation, monitoring, cost controls and audit rules.
A project may include analysis of the current process, definition of the agent’s responsibility, approved input data, security and permission rules, integration architecture, prototype, structured result definition, connection with the existing application, human review interface, failure and fallback behavior, automated tests, monitoring, gradual deployment, documentation and a maintenance plan.
The company receives an agent connected to a specific process, clear rules describing what it can and cannot do, a review process, measurable results, protection against invalid output, normal work when the provider is unavailable, documentation, tests and a solution that can be extended later.
A production AI agent is not only a model connected to an application. It is a controlled process defining what information may be used, what result is expected, who verifies it and what happens when the service cannot provide a reliable answer. GiSoft designs the agent around real company work and introduces it gradually, without removing the controls already present in the application.