“Let’s hire AI bots and make support cheaper.” What could go wrong?

A simple operation that took five hours

A customer accidentally signed up for the wrong product from the same provider. The account contained no websites, domains, mail or databases. The task was simply to transfer the available balance from a shared-hosting account to a new Cloud account so the customer could buy a server.

At first, we tried to understand why the customer could not sign in. Support checked account blocks, country restrictions and the IP address. The actual reason emerged separately: hosting and Cloud used different authentication systems. A customer could reasonably believe they had registered with one provider while actually entering a different product and control panel.

Once that was clear, the request was precise: transfer the entire balance between two products. The conversation nevertheless repeated the same loop:

1. The customer explains the task

   They identify the source, destination and expected outcome.

2. The agent asks for known context

   The customer repeats information already present in the conversation.

3. The case is handed to a colleague

   The next participant reconstructs the meaning of the thread from scratch.

4. The loop starts again

   Replies arrive quickly, but the operation does not move closer to completion.

The root cause was not necessarily a weak model or an individual operator. It was an architectural gap: the case had no reliable shared state and no single owner accountable for the outcome.

What the backend should store

After the first few messages, the system could already have built structured case state. All identifiers in this example are intentionally redacted.

{
  "intent": "transfer_full_balance",
  "source": {
    "account_id": "hosting_account_redacted",
    "product": "virtual_hosting",
    "owner_verified": true
  },
  "destination": {
    "account_id": "cloud_account_pending",
    "product": "cloud",
    "owner_verified": false
  },
  "assets": {
    "balance": "all_available",
    "sites": 0,
    "domains": 0,
    "mailboxes": 0,
    "databases": 0
  },
  "status": "identity_verification_required",
  "next_action": "verify_owner",
  "completion": [
    "balance_visible_in_cloud",
    "customer_can_sign_in",
    "server_purchase_available"
  ]
}

The next agent should start from a machine-readable handoff contract: the reason for transfer, known and verified facts, completed and failed actions, missing information and the next required step.

A correct fact attached to the wrong entity

During the conversation, support quoted an exact account balance. A later check showed that the amount belonged to a different account. This was not merely an inaccurate reply; it was an entity resolution failure.

The case simultaneously involved the account used to contact support, the customer's account, Hosting and Cloud products and the owner's email. Without an explicit “fact → entity → source → verification time” relationship, a dangerous combination appears:

Correct fact + wrong entity = wrong answer.

The specificity makes such an answer unusually convincing. Critical facts therefore cannot live only inside a model-generated summary. They need stable entity identifiers, provenance and verification status.

A technical event is not a customer outcome

Support eventually reported that the Cloud account had been created. The customer still could not sign in. The internal workflow may have ended at a technical event:

cloud_account_created = true

The business outcome was different:

customer_can_access_cloud = true
balance_is_visible = true
server_purchase_is_available = true

Until that entire sequence is verified, the case is not resolved. Support is responsible for the observable customer outcome, not merely a successful internal API call.

How to place an LLM inside a support orchestrator

An LLM is valuable here, but it should not be the only place where the business process exists. Its job is to understand unstructured language and help choose the next step.

1. Extract

   After every message, return intent, entities, facts and requested_action against a strict schema.

2. Validate and persist

   The backend validates types, links facts to entities, records provenance and saves the state change.

3. Resolve conflicts

   A new value must not silently overwrite a verified fact. Create a conflict and require another check.

4. Select a workflow

   Rules choose the allowed action: request data, call an API, route to a specialist or stop a risky operation.

5. Create a handoff contract

   The recipient sees structured context, the transfer reason and the next action—not only a long chat transcript.

6. Verify the outcome

   Close the case only after completion criteria pass or the customer explicitly confirms the result.

Every case needs an owner

An agent → agent → agent chain cannot continue indefinitely. If the current participant cannot perform the action, the case must move to a named operator or queue with the required permissions. Accountability and a deadline for the next step move with it.