AI customer service agent: what it is allowed to do

What an AI customer service agent is

An AI customer service agent is software that handles support work autonomously rather than assisting a human with it. The distinction from a chatbot is scope of action: a chatbot produces a response, an agent is expected to take steps toward resolving the underlying issue, which may mean looking up an order, issuing a refund or raising a replacement.

The category is moving fast and the labels are loose. The useful question is not whether something is called an agent, but what it is permitted to do and in which systems.

Every order is a promise. Keeyu keeps it. An agent that only talks can report a broken promise fluently.

Three things sold as agents

• Conversational agents that answer customer questions from your knowledge base and order data. Good at questions, cannot change outcomes.
• Agent copilots that draft replies and summarize context for a human. Real productivity gain, human still does the work.
• Operational agents that act in the store, warehouse and carrier systems to resolve the issue itself.

Most of the market is the first two. The third is where ticket volume actually falls, because it removes the event rather than the conversation about it.

There is a fourth distinction under those three. Ops AI isn't built to talk. It's built to fix, and it only works when three layers ship together: integration with every system that touches an order, intelligence that scores the risk, and orchestration that executes with guardrails. Ask which one you are buying before comparing feature lists.

What an operational agent does in practice

Take a lost parcel. If an item is still in transit well past its expected delivery date, it is functionally lost. The workflow cancels the order in the store, raises a new order, allocates express shipping, pushes it to the warehouse and notifies the customer. That is one action executed across four systems, and the customer never opens a ticket because there is nothing left to ask.

Our agents operate in read and write mode: identifying issues in real time, automating the workflows, gathering information from customers, and updating every connected system. My design principle is simple: the right tools transform an AI agent from a mere advisor into a doer.

The agent also learns which work to take on. Our co-founder and CEO Jevon Le Roux described how it spots that on Forward Thinking, the LogiHire podcast. The agent goes: "I'm noticing this person's doing this work repetitively four, five, six, seven times. It's the same work. Let's now turn it into a workflow."

Or take a stockout. Our out-of-stock workflow triggers the moment a warehouse types 'out of stock' into NetSuite, then searches other stores for inventory, finds product alternatives, checks the ERP for next shipments, and if no replacement exists, cancels the order and processes the refund.

Scale matters here. We can identify 45 lost-in-transit orders in real time, select them all, and resolve them in parallel against a predefined workflow. A human doing that opens 45 sets of tabs.

At EHP Labs an out-of-stock workflow that took 45 minutes now runs in five, reactive tickets fell 55%, and the CX team went from 18 people to 8.

Underneath the workflows sits plain visibility: a first-in-first-out tracker for orders, a delivery tracker, and a returns tracker. Behind them sit real events tracked with seconds of latency (a payment failed, a scan missed) under one shared order ID. Without that ID, operations are blind. The agent works from what those trackers surface.

The autonomy boundary

In e-commerce ops, fully autonomous automation is too risky, and that is what I have learned building AI agents so far. These actions cancel orders, move money and commit shipping spend against real customers. An agent that is confidently wrong at scale is far more expensive than a slow human, and it is wrong across hundreds of orders before anyone notices.

The design that holds up is an explicit boundary. Fulfillment, returns and payments produce thousands of decisions a day, and nobody can put a person in front of each one, so the checkpoints have to be flexible. Routine, high-confidence, bounded-cost cases execute automatically. Unusual, high-value or ambiguous cases go to a person with the detection already done and the context assembled. The human keeps the judgment and loses the tab-switching.

Two more guardrails go in before production, and I learned this the hard way. Full transparency: every action recorded, with its inputs, tools called and systems touched, because if you can't explain what happened, no one is signing off. And rollback: everything breaks eventually, so reversibility has to be a default. The pattern I keep coming back to is event, risk score, policy check, human in the loop, execute, audit log, rollback.

The end state I want is a quiet inbox, quiet because issues are fixed at the source and not because people grind harder. That reframes the autonomy question. It is not how much of the conversation the agent should own. It is how much of the conversation should never have to happen.

Integration is the real constraint

An agent is only as capable as its access. Plenty of warehouse systems and regional carriers have no usable API. We lost two customers because we could not integrate with their systems, so I built browser operator functionality that lets Keeyu work through the browser and read data from systems never designed to be automated.

Our answer is a browser operator: AI that opens the browser, reviews the information, takes photographs, and converts them into usable data. It constantly scans carrier portals like Royal Mail, and it is how we handle a Sydney 3PL notorious for giving nobody API access.

When you evaluate an agent, ask what it does with the one system in your stack that has no modern API. That answer usually determines whether you get resolution or a very articulate description of the problem.

A generic agent can read a Shopify webhook. A vertical agent understands carrier behaviors across several shipping providers, knows which 3PL quirks matter for which warehouse, recognizes fraud patterns specific to apparel, and handles the long tail of edge cases that happen once a quarter. No prompt gets you there. It takes years of customer deployments and integrations across Shopify, Magento, BigCommerce, NetSuite, the 3PL platforms and the marketplaces, and that depth is what allows an action instead of a notification. An agent is only as autonomous as its write access.

Where this sits

This is proactive e-commerce operations, a system of action rather than a smarter inbox. Detect. Decide. Act. The customer gets what they want, on time, as promised.

See how the workflows run or book a demo.

Related reading

For the wider category, read AI customer service. For the automation distinction, see customer service automation. For the posture shift, read proactive versus reactive customer service.

• AI in customer service: why inbox gains plateau
• Post-purchase operations, explained
• Proactive customer service: the tactics that actually cut tickets
• Ecommerce returns: the half of your return rate you caused

• Gartner, 2025: where service journeys start and stall.
• Harvard Business Review, 2010: the effort research behind resolution-first design.
• Marketing for SMEs, Jevon Le Roux on the E-Commerce Mistake Costing Millions - the orchestration layer, and the 55% ticket cut at EHP Labs.
• The Breakout CEO #86, The Pivot This Founder Made After an Investor Called It Impossible - one in five US shoppers not getting orders on time, and the ticket ratios behind it.
• The 9-5 Exit Plan, How AI Is Making Customer Support Invisible - proactive AI and support that disappears.