A customer writes to change the shipping address of an order that has already been confirmed. The first Agent answers with precision. It explains where to find the orders section, which function to use, and within what time frame the change is allowed. The second Agent follows a different path. It verifies the customer's identity, checks that the order has not yet been handed over to the courier, updates the address and confirms the operation within the same conversation.
The first Agent automated the answer. The second automated the work.
This distinction defines the current phase of conversational AI in the enterprise. Language models have made language understanding and generation excellent, to the point that this level of quality is now a baseline requirement, not a differentiator. The value has moved one step further, into the Agent's ability to execute real operations on enterprise systems, with clear rules on what it can do autonomously and what requires oversight. It is the shift from the assistant that talks about the process to the Agent that operates within the process.
The difference between explaining and doing
A purely informational Agent delivers a partial result even when it answers flawlessly. The customer receives the correct explanation, but still has to carry out the action alone. They open the app, navigate the menu, and look for the function. If something does not add up, they call back. In the statistics, that conversation counts as handled by AI, but the need has not been resolved. It has merely been redirected.
This gap has a precise name in the vocabulary of metrics, and it is the distance between deflection and resolution. An answer that refers the customer to a further action generates apparent deflection and real repeat contacts. An operation completed within the conversation generates resolution, and the difference shows up in the numbers over the following weeks.
The operational Agent changes the terms of the problem. The most frequent customer service requests are not questions of knowledge; they are requests for intervention. Where is my order? I want to change the delivery date, split this bill into installments, block my card, reschedule my appointment. For each of these, the perfect answer is the completed action. Everything else is an intermediate step.
There is also a less visible effect, one that concerns the internal team. When the Agent executes repetitive operations from start to finish, operators stop acting as intermediaries between the customer and the systems and focus on the cases where human judgment is the source of value. It is the automation of actions, not of answers, that truly reduces the operational load.
Anatomy of an integration. What is actually needed
Integrating the Agent with enterprise systems evokes long and costly projects. In practice, the useful perimeter is narrower than one might imagine, and it is defined starting from the actions, not from the systems.
The systems involved are almost always the same, adapted to each industry.
CRM and customer data
They serve to recognize the customer, read their history, and update personal and contact details.
Order management and logistics
Shipment status, order changes, returns and refunds.
Ticketing and case management
Opening, updating and closing cases, with the context of the conversation already attached.
Billing and administrative systems
Invoice retrieval, installment plans, direct debits.
Industry core systems
Core banking, claims management, booking systems. They are the most sensitive and, at the same time, the most valuable, because they hold the highest-value operations.
The recurring mistake is planning the complete integration before starting. The correct approach reverses the sequence. You start with the three to five actions with the highest volume and lowest risk, integrate only the systems those actions require, and extend the perimeter based on results. A high-volume, low-complexity action, such as order status with exception handling, pays back the integration within a few weeks and builds the internal confidence needed for the next step.
On the technical level, every action follows the same pattern. Customer identification, data retrieval, execution of the operation, confirmation in the conversation, and a record in the systems. Standardizing this pattern makes the model scalable, and it is the reason protocols such as MCP are becoming the connection point between AI Agents and enterprise systems. Define once how the Agent accesses a tool, rather than building a dedicated integration for every use case.
The perimeter of permissions. What the Agent can do on its own
Faced with an Agent that acts, every company asks the same question. Who decides what it can do? The answer is not a switch; it is a scale. Actions are classified across three levels of autonomy, and the classification is a business decision, not a technical configuration.
Full autonomy
It covers reversible, low-risk actions with limited impact. Checking the status of an order, sending a copy of an invoice, updating a phone number. The Agent executes them and reports them. At this level, a confirmation request would add friction without adding control.
Explicit customer confirmation
It covers actions with concrete but circumscribed effects. Changing a shipping address, rescheduling an appointment, activating an installment plan. The Agent prepares the operation, summarizes it in plain language and executes it only after consent has been expressed in the conversation. The summary that precedes the action also protects the company, because it makes verifiable what the customer actually authorized.
Internal human approval
It covers high-impact actions, those that are hard to reverse or subject to regulatory constraints. Refunds above a threshold, contract cancellations, significant dispositive operations. The Agent prepares the case, gathers all the elements and hands it to an operator who approves or intervenes. The preparation work remains automated; the decision remains human.
The criterion that orders the three levels is reversibility. An action that can be undone as easily as it was executed can move up in autonomy; an irreversible action moves down. The assignment, moreover, is not final. An operation that debuts at the second level can rise to the first after months of correct executions, with data supporting the decision.
Two conditions make the system reliable over time.
The first is identity. The Agent operates on the systems with its own credentials and granular permissions, never with generic or shared service accounts. The second is traceability. Every action leaves a record that links the operation to the conversation that generated it, available in the event of a dispute or an audit. These are the same principles that govern the security and compliance of AI Agents in general, applied to the specific case where the Agent does not merely read but also writes.
Legacy does not mean impossible
The most frequent objection comes from IT. Our systems do not expose modern APIs, so this does not concern us yet. It is the objection that deserves the most direct answer, because waiting for the systems to be rebuilt is the most expensive way to address the problem.
The patterns for working with dated systems exist and are proven.
An intermediate API layer
A lightweight layer that exposes to the Agent only the operations it needs, translating them into the protocols the legacy system understands. It is the most solid pattern because it decouples the Agent from the underlying system. When the legacy system is replaced, the Agent will not notice.
Automation as a bridge
Where no programmatic interface exists, operations can be executed by automations that replicate the steps an operator performs on the management system. It is a transitional solution, fragile by definition, but it makes it possible to validate the value of the automated action before investing in structural integration.
Asynchronous execution
Not every action needs to be completed in real time within the conversation. The Agent can take charge of the request, forward it to the system on the system's own schedule and notify the customer once the operation is complete. For many administrative processes, reliable intake followed by notification is worth as much as immediate execution.
The choice among these patterns matters less than the underlying decision, which is to start from the value of the action rather than from the state of the architecture. A company with dated systems and three well-integrated actions serves its customers better than a company with a modern architecture and an Agent that only answers.
The metric changes. From deflection to actual resolution
When the Agent executes operations, the way it is measured must change as well. The question is no longer how many conversations it absorbed, but how many processes it carried through to completion.
Three measures become central.
Actual resolution
The share of requests in which the action was completed within the conversation, or taken over with a confirmed outcome. It is a more demanding measure than deflection, and for that very reason more credible.
Repeat contact rate
The truth test of any automation. How many customers come back with the same issue in the following days? An informational Agent can show high deflection and equally high repeat contacts. An operational Agent that works lowers both quantities, the volume and the return.
Process completion time
Not the duration of the conversation, but the time that separates the customer's request from the operation completed on the systems. It is the metric that makes the Agent comparable with the process it replaces, made of queues, handoffs between departments and callbacks.
The composition of human work
If the Agent executes repetitive operations, the share of time operators devote to complex, high-value cases must grow over the months. If it does not grow, the automation is shifting the work instead of absorbing it, and it is worth understanding where. A number built on resolution is credible. A number built on the resolution of executed actions is definitive.
Where to start
The path toward an operational Agent does not require a multi-year program. It requires four decisions, taken in the right order.
1. Map the requests for intervention
From the analysis of conversations and tickets, requests that require action are isolated and ranked by volume. The top ten almost always cover the majority of the load.
2. Classify by risk and reversibility
For each action, the level of autonomy is established among full execution, customer confirmation and internal approval. It pays to involve compliance and IT security from the outset, because defining the perimeter together is faster than negotiating it afterward.
3. Integrate the minimum necessary
The first three to five actions, only the systems they involve, the integration pattern suited to the state of the architecture.
4. Measure on resolution
Success metrics are set before release. Actual resolution, repeat contacts, completion time. The perimeter then extends action by action, with data guiding the sequence.
The answering Agent was the first chapter of conversational AI in the enterprise. The Agent that acts is the one in which value becomes measurable in completed processes, not in handled conversations. The distance between the two is not closed by a more powerful model. It is closed by the concrete, well-defined work of bringing the Agent inside the systems where the work happens.
FAQ
What is the difference between an integrated AI Agent and a chatbot connected to a few APIs?
The difference is architectural, not a matter of how many integrations there are. A chatbot with APIs executes predefined calls within rigid flows, and when the request steps outside the flow, it stops. An integrated AI Agent understands the intent, chooses which tools to use and in what sequence, handles exceptions and operates within an explicit perimeter of permissions, with confirmations and traceability. The former automates a path; the latter automates a task.
Do legacy systems need to be modernized before adopting operational AI Agents?
No. An intermediate API layer, the automation of manual steps as a temporary bridge, or asynchronous execution with notification make it possible to start with the existing architecture. Postponing adoption until modernization is complete means giving up for years the value of the actions that can be automated today, and reaching the new system without the operational experience accumulated in the meantime.
How is security ensured when an Agent executes operations on the systems?
Through four safeguards. Dedicated credentials with granular permissions for each action; never shared accounts. Explicit levels of autonomy, with customer confirmation or human approval where the risk requires it. Complete traceability, linking every operation to the conversation that generated it. Operational limits on amounts, frequencies and thresholds. The security of an operational Agent is not a property of the model; it is a property of the perimeter in which the model operates.
