Why an AI agent breaks on real integrations
In a demo, an autonomous scenario looks seamless: the agent accepts a request, contacts the necessary services itself, and returns a finished result.
On live data, it hits things that were not in the test environment: response delays, partial failures, and different representations of the same entities in different accounting systems.
The first gap is data desynchronization. The agent reads a request's status from one external system and the remaining balance under a contract from another, and then works from a snapshot that is already outdated.
If the step is repeated after a timeout, the same call goes out a second time and duplicate operations appear: two records instead of one, a repeated email to the client with different terms, a duplicate account movement.
A one-off failure here turns into an accounting data discrepancy that is later searched for manually.
The second gap is loss of context between steps. A long scenario breaks into separate calls, and the agent has to reassemble the state from responses, some of which are already outdated.
This leads to more manual investigations: the operator checks which step went through and which did not, and completes the scenario on behalf of the agent — autonomy drops exactly where it was needed most.
The weak points lie at the junctions with external systems, not in the model itself. Below we analyze how this is closed.
What an AI agent with access to external systems provides
Managed access to external systems is when the agent reads and changes data where it lives: in an accounting system such as Bitrix24, in an internal order database, or in a queue of inquiries.
Every call follows a described contract: what is allowed, what requires human confirmation, what is completely prohibited. Below is what exactly changes in measurable terms.
- Processing speed. Collecting context from two or three systems and preparing a response happens in a single pass instead of a manual chain of approvals. The processing time for one request drops from tens of minutes to units, and this is visible not only in the average but also in the tail of the distribution.
- Share of operations without a human. The agent closes typical inquiries itself; disputed and non-standard ones remain with the operator. In a pilot environment, this is 60–80% of the flow, and the freed-up hours go to complex cases rather than routine.
- Failure isolation. External calls go through a separate layer with a timeout, retries, and a rate limit. A slow response from one system does not drag down the entire agent: the scenario degrades to a manual step, and the rest continue working.
- Downtime. When an external system is unavailable, operations are queued and completed after recovery — the retry does not create a duplicate. We measure downtime in minutes; there are no lost requests.
- Support load. Statuses, standard edits, and data collection go to the agent. The share of manual actions in the flow falls along with the number of input errors and "where is my request" inquiries.
We verify this in a narrow environment: one process, real data, metrics before and after access. We expand the agent's rights only after the numbers are confirmed.
Ways to connect to external systems: what to choose
An agent almost never works in a vacuum: it reads requests from an accounting system, writes statuses to billing, and requests stock levels in a warehouse.
The connection method determines not the speed of the demonstration but the blast radius of an error — what exactly the agent can break if the model makes a mistake or the wrong request comes in.
There are four real options, and each is a trade-off between the speed of delivering the integration and control over the agent's actions.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection | 1–2 external services, stable interface, low load | The agent's credentials equal employee access; no common point for logging and limits |
| Message bus | Multiple systems, different protocols, asynchronous operation needed | Message delivery delay; the bus must be operated separately and the data schema monitored |
| Isolated environment | Sensitive data, regulated environment | No external access, exchange through a gateway, a new integration takes longer to deliver |
| Hybrid scheme | Production systems where a write error is costly | More complex setup: two permission domains and two logs that need to be reconciled |
Access restrictions are configured on top of any scheme: the agent works under a separate service account, not under an employee's login; rights are granted for specific operations, not for the entire system.
Irreversible actions — write-off, sending a document to the client, changing the price — go for operator confirmation; the rest passes automatically. A call log with parameters and result is mandatory: without it, an incident cannot be investigated. Next, we show how this fork looks in a real environment.
Implementation stages: from task analysis to handover
The stages follow a strict sequence: until access boundaries are fixed, integration setup turns into reworking code that has already been written.
Each stage ends with an artifact — a diagram, a configuration, or a verification report — that the customer accepts before moving to the next step.
- Task analysis. Interviews with performers and a map of inquiries: who initiates, on what event, what result is considered closed. The output is a list of the agent's operations and a separate list of what it never does.
- Access boundaries. We determine external systems and rights: read or write, a separate service account, a ban on bulk exports. We leave irreversible actions to a human who confirms them manually.
- Integration scheme and setup. We describe the exchange with external systems: the structure of requests and responses, error handling, retries without creating duplicates, logging of every agent step.
- Testing in a staging environment. A test environment with copies of systems and anonymized data. We run not only successful scenarios but also failures: an unavailable service, an empty response, a permission conflict, exceeding limits.
- Measuring results. We calculate the share of inquiries brought to completion by the agent without human involvement and the time for a standard operation before and after. This is the basis for deciding whether to expand rights.
- Handover to operation. An update procedure, monitoring and failure alerts, first-line instructions, and training for the customer's team. We support the first period until the agent's behavior becomes predictable.
What remains in your infrastructure after implementation
The handover package is not a folder with a presentation but the working tooling around the agent that your engineers use without us.
If after implementation only messenger correspondence and a description of "how everything works in general terms" remain, there is no one to operate the system: any permission change or disabling of one connection turns into a call to the contractor. Therefore, the closing package includes:
- Interaction diagram — the route of a request from the user through the agent to each external system, the places where restrictions are applied, and the points where the request stops altogether. A new engineer understands the flow in a day, not a week.
- Access matrix — for each connection: what the agent performs itself, what it does only after human confirmation, what is prohibited at the permission level. Changes are made through approval, and the edit history is preserved.
- Rollback procedure — the order for disconnecting the agent from an external system, revoking granted rights, returning the previous configuration, and the time for each operation. It is run in staging, not existing only on paper.
- Documentation — configurations, environment variables, connection owners, and contacts of responsible persons on the external systems' side. It is stored next to the code, not in a separate folder.
- Action log — what the agent requested, what it changed, with whose confirmation; retention periods are configured, and export for incident investigation is worked out.
- Observability tools — failure metrics, notifications about anomalous actions, and a monitoring dashboard broken down by systems and operation types.
- Verification scenarios — a set of tests for key paths, including external system unavailability and permission denial.
All of this is hosted in your repository, on your accounts, and with your access keys — ours are closed after acceptance. We conduct acceptance together with your engineer: they run the rollback scenarios themselves and review the log rather than reading about them in a report.
Case study: removing manual operations in support and sales
One of our teams handled support and sales in a shared queue: about one and a half thousand inquiries per month, three quarters of them typical.
The operator spent 12–15 minutes on each, and most of it went to manual operations: finding the client, checking the order status, transferring data into a template.
Before: queue of tickets and manual operations
The peak occurred on Monday mornings and days after mailings: up to 60 unprocessed inquiries, first response averaged 50 minutes. Half of the tickets were order status and payment; data was collected manually from three systems.
Hence errors: an outdated status went to the client, the ticket returned to the queue and added another cycle.
After: typical cases to the agent, exceptions to the human
The agent is connected to systems via API: inquiries come from Zendesk, statuses from the accounting system and delivery service, and responses are assembled from the knowledge base.
In typical scenarios, it finds the order itself, checks payment, and closes the inquiry — processing time dropped from 12–15 minutes to 40–60 seconds.
68% of inquiries are closed without an operator, the peak queue shrank from 60 to 8–10 tickets, and the first response takes 3–4 minutes.
Manual operations in typical scenarios are gone: data collection, insertion into a template, and moving a ticket between statuses are no longer done manually.
Refunds, non-standard discounts, contract edits, and inquiries flagged as conflicts remained under human confirmation — about one fifth of the volume.
The agent prepares a draft and attaches the conversation history; the operator confirms with one action: disputed cases go to a human before responding to the client.
How an autonomous scenario differs from conventional automation
Conventional automation is a predefined scheme: event, conditions, sequence of actions. The route is known at the design stage, and branching is rigid: if a field is empty, we go to one branch; if filled, to another. Anything not provided for by the scheme stops the process.
An autonomous scenario does not store the entire route.
It receives a goal and a list of available actions — system queries, reading reference data, service calls — and at each step chooses what will bring it closer to the result, relying on the current state of the data rather than a condition specified by someone.
Hence the main difference is decision-making.
In rule-based automation, the choice is made by the engineer who defined the branch; in an autonomous scenario, the model chooses, and we set the boundaries: which systems are accessible, what is allowed to be changed, what is read-only.
Behavior during failure differs just as noticeably. A rule, upon encountering an unexpected system response, fails and goes to the review queue.
The agent recognizes a non-standard response, tries an alternative source or formulates a clarifying request, and beyond policy hands the situation to a human along with the collected context.
Therefore it is more accurate to speak not of "whether automation exists or not" but of the level of autonomy: it prompts the operator, suggests an action with confirmation, performs it itself within defined boundaries.
The boundaries are maintained by a step limit per task, access rights, a log of every call, and reversibility of actions. Without them, autonomy turns into unpredictability that can be neither debugged nor accepted into operation.
Common technical concerns before launch
The customer's technical teams at the evaluation stage ask roughly the same things: access rights, behavior when an external system fails, testing the scenario without risk to the production environment, and rollback of changes.
The general principle is the same — the agent works from a separate service account with the minimum necessary set of rights, and every call to an external system and its result are written to the log with the session ID.
What rights does the agent get?
Exactly those needed by the scenario: reading requests, writing to a specific section, sending a notification. Rights are granted by area and revoked with one operation; access is not expanded "just in case."
What happens if an external system is unavailable?
Retry with increasing delay, then a queue of deferred tasks. The agent does not substitute a fabricated answer or continue the chain on incomplete data: the task is marked incomplete, and the on-call engineer receives a notification.
Can the scenario be tested without risk to the production environment?
We set up an environment with a copy of the data structure and stubs of external systems, and run rare branches: integration failure, request limit, record version conflict. Logs and traces of each step are stored in Grafana — incident investigation takes minutes.
How are changes rolled back?
Before writing, the previous state of the object is saved; rollback is performed granularly from the log — one record or the entire batch of operations for the session. Bulk edits are first shown by the agent for confirmation.
Let's discuss the task: what to send us for evaluation
For the evaluation to be substantive rather than "by eye," a few inputs are enough — we will clarify the rest during a technical session with your team.
The more specifically the process is described, the fewer assumptions make it into the plan and the more reliable the timelines.
- Process description: how the task is solved now, who is involved, and which steps are repeated daily or weekly.
- List of systems: accounting and warehouse environments, knowledge base, internal services, email and messengers, external interfaces — everything the agent needs to reach.
- Expected rights: what the agent reads, what it changes itself, and what remains with a human and requires confirmation.
- Constraints: security service requirements, personal data handling rules, isolated environments, windows when changes are allowed.
- Current workflow: exports, queues, manual operations, files on disk — and the place where the process slows down the most.
- Entry points and result format: which system initiates the request and in what form the answer is needed — request, email, record in the accounting system.
If some data is closed, that is not a blocker: we start with the process description and system list, and collect the rest during the session.
Based on these inputs, we come back with a work plan: stages, what we do in each, which accesses are needed and in what order, and where the acceptance points are.
We provide the estimate and timelines by stage, not as a single number — this makes it clear what can be launched earlier and what depends on your side's readiness. Describe the task in free form — we will ask clarifying questions ourselves.
