IT vendor support tickets between agents

When a company’s service desk finds that an incident sits in a vendor’s product, someone opens a second ticket in the vendor’s portal and copies the facts across. From then on there are two ticket numbers, two severity scales and two clocks, kept in step by email. An agent-to-agent version lets the customer’s service desk agent open the vendor case directly, attach diagnostics, answer the vendor’s questions, and receive status changes into the original ticket.

How it works today

ITIL 4 describes incident management as the practice of restoring normal service as quickly as possible after a disruption. Inside one company, a service desk tool tracks that work. The trouble starts when the fix depends on a vendor.

The usual path looks like this:

1. The customer’s service desk logs an incident and triages it.
2. An engineer decides the vendor’s hardware, software or cloud service is involved.
3. The engineer signs in to the vendor’s support portal, re-enters the product, version, serial number, contract or entitlement ID, symptoms and business impact, and uploads a diagnostic bundle.
4. The vendor’s support team works the case in its own tool. Questions come back by portal message or email.
5. The customer’s engineer copies each update into the internal ticket, by hand, when they remember.

Some pairs of companies connect their tools directly. ServiceNow documents an Integration Hub spoke with actions to create and manage integrations between ServiceNow instances, and its support portal covers an eBonding spoke for keeping incidents in step across instances. Zendesk lets one account invite another to a sharing agreement so tickets pass between them; each agreement is one-way, has a status such as pending, accepted or declined, and a reciprocal flow needs a second agreement. Where the two tools differ, teams build on the ticketing APIs, such as Zendesk’s POST /api/v2/tickets or Jira Service Management’s POST /rest/servicedeskapi/request, which needs a service desk ID, a request type ID and a map of field values.

Each of these bonds is a small integration project: field mappings, status mappings, credentials and error handling for one pair of companies. Between vendors, TSANet runs a collaboration network where member companies’ support engineers raise multi-vendor issues with each other. Most customers and vendors have neither, so the portal and the inbox remain the interface.

The agent-to-agent version

Illustrative. A customer’s service desk agent reaches a storage vendor’s support agent at the endpoint in the vendor’s Agent Card and opens a case:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-inc0044713-1",
      "role": "ROLE_USER",
      "parts": [
        { "text": "Controller B on one array reports repeated path failovers since the firmware 2.14.1 update. Redundancy is degraded on a production cluster." },
        {
          "data": {
            "entitlementId": "SUP-88213",
            "product": "Example Array 5000",
            "serialNumber": "EXA5K-0042",
            "firmware": "2.14.1",
            "customerSeverity": "S2",
            "customerTicket": "INC0044713"
          },
          "mediaType": "application/json"
        },
        {
          "url": "https://files.customer.example/diag/INC0044713.tgz",
          "filename": "diag-bundle.tgz",
          "mediaType": "application/gzip"
        }
      ]
    }
  }
}

From there:

1. The vendor’s agent checks the entitlement against the serial number, opens its internal case and returns a task whose artifact carries the vendor case number.
2. It needs one more log, so it moves the task to TASK_STATE_INPUT_REQUIRED with a question. The customer’s agent collects the log and replies on the same task.
3. The customer’s agent registered a push notification config, so each status change reaches it without polling. It writes each change into INC0044713.
4. The vendor’s engineer publishes a fix. The task completes with the resolution and the firmware version as artifacts, and the customer’s agent proposes closing its own ticket.

A2A task states line up with the statuses help desks already use. Zendesk’s ticket statuses, for example, are new, open, pending, hold, solved and closed:

A2A task state	Typical ticket status
TASK_STATE_WORKING	Open, in progress
TASK_STATE_INPUT_REQUIRED	Pending, waiting on the customer
TASK_STATE_COMPLETED	Solved
TASK_STATE_REJECTED	Closed without work, for example no valid entitlement
TASK_STATE_CANCELED	Closed at the customer’s request

The mapping is a convention each pair must agree on. A2A defines the states; what each one means for an SLA belongs in the support contract.

What has to be true

Identity. The vendor must know which customer account is calling before it reveals case data or spends engineering time. Today that is a portal login plus a contract number. In the agent version, the vendor’s Agent Card declares its security schemes, the customer’s agent authenticates with credentials the vendor issued to that account, and the vendor checks the entitlement on every request. The customer, in turn, needs to know the endpoint really belongs to the vendor; a signed Agent Card served from the vendor’s own domain answers that.

Authority. Three decisions need explicit limits:

• Who may raise severity. A top-severity case can page on-call engineers and may carry contractual response times. The customer’s agent should only raise it within rules its owner set.
• What the vendor’s agent may do in the customer’s environment. Reading uploaded diagnostics is one thing. Opening a remote session or changing configuration needs a separate, per-change approval, usually from a person. Least privilege applies to both sides.
• What data may leave. Diagnostic bundles can contain hostnames, user names, personal data and sometimes secrets. The customer’s agent should scrub or withhold them by policy before upload.

Record. SLA credits, renewal negotiations and post-incident reviews all depend on timestamps both sides accept: when the case was opened, when the vendor first responded, how long it sat waiting on the customer. Today each side has its own history, and the two rarely match. A shared record of the exchange, with both ticket numbers cross-referenced, settles those arguments.

Standards involved: A2A tasks, multi-turn input and push notifications for the exchange; OAuth 2.0 or mutual TLS for client authentication; the ticketing APIs above on each side; and each company’s ITIL-style incident process for what the states mean.

Where Emissar fits

• Front Door (open to design partners) is a hosted A2A endpoint in front of a vendor’s existing support systems, so the vendor does not run agent infrastructure itself.
• Verify (in development) checks which agent is calling and who built it before the vendor acts on a request.
• Ledger (spec in progress) is a signed, tamper-evident record of what each side asked and answered, which is what an SLA dispute needs.
• Handoff (in development) passes a case to a vendor engineer, with the full exchange attached, in the help desk they already use.

Resolve adds little here: the customer already knows its vendor’s domain.

Open questions

• Severity scales differ by vendor. Who maps a customer’s S2 to a vendor’s P2, and is the mapping part of the contract?
• A diagnostic bundle may contain personal data. Which party is responsible for it once uploaded, and how long may the vendor keep it?
• Two-way sync can loop: a status change on one side triggers an update on the other, which triggers another. Which side owns which fields?
• Multi-vendor incidents involve three or more parties. Does each vendor open its own task, or does one coordinate, as TSANet members do today?
• How should an agent exchange coexist with an existing eBonding contract on the same account without creating duplicate cases?