Should You Publish a Support API for Customer AI Agents?

Somewhere on your site there's a contact form with a dropdown, a 500-character message box, and a reCAPTCHA. An AI agent working on behalf of a customer is going to fill that form out. It will pick the wrong dropdown value, compress a structured question into prose, get an auto-acknowledgement, and then wait 14 hours for a reply it has to parse back out of HTML.

That's the state of the art in 2026, and it's ridiculous.

Here's the position, up front: if your product has an API, your support should have one too. Not for developers, but for the agents your customers are already pointing at you. The contact form isn't dying because forms are bad. It's dying because it's a human-shaped hole and the thing knocking is no longer human-shaped.

The readership already flipped

This isn't speculative. Documentation platforms have been measuring it, and the numbers moved faster than almost anyone predicted.

GitBook analysed a week of traffic across its hosted documentation sites in early May 2026 and found that once you exclude search crawlers and count only intentional reads, AI agents hold the majority: 51.8% to 48.2%. Their longitudinal view is the more striking part. AI accounted for under 10% of documentation traffic in January 2025, roughly 41% by December 2025, and crossed half of intentional reads five months into 2026. Mintlify's numbers point the same direction, with agents at around two-thirds of measured traffic across the docs sites it powers by mid-2026.

Help content is not documentation, exactly. But it is the same kind of asset being consumed by the same class of reader, and there is no reason to think the curve looks different. Your knowledge base has two audiences now and only one of them can use a search box.

What a support API actually means

The phrase makes people picture a six-month engineering project. It shouldn't. There's a ladder here, and the first two rungs are almost free.

1. Machine-readable help content. Serve your help centre as clean markdown alongside HTML, and publish an index. Mintlify benchmarked four ways of serving docs to agents across 2,400 runs and found a single link to llms.txt eliminated most agent 404s at no added cost. Cheap, reversible, and it improves the answers agents give about you whether or not you do anything else.
2. A read-only status endpoint. Order status, ticket status, shipment tracking, subscription state. Authenticated to the account, no write access. This is the rung that kills the most email volume, because WISMO tickets are the highest-volume, lowest-judgement category in most inboxes.
3. An authenticated action endpoint. Initiate a return, cancel an order, update an address, open a ticket with structured fields. Real write access, scoped and rate-limited, with the same guardrails your internal automation already runs behind.
4. A published agent card or MCP server. The full version: a signed declaration of what your support organisation can do, discoverable by any agent without a bilateral integration. A2A v1.0 made this practical, because Signed Agent Cards let an agent authenticate a counterparty with no pre-existing agreement between the two organisations.

Most companies arguing about whether to open up to agents are imagining rung four and ignoring that rungs one and two are a fortnight of work with an obvious payback.

The case for building one

Start with the thing that's already happening. Agents are hitting your support surfaces regardless of whether you invite them. The choice isn't whether to serve agent traffic. It's whether to serve it through an interface you designed or through one that was built for someone else.

Structured beats scraped, every time. When an agent asks for the status of order 88214 through an endpoint, you get an account-scoped, authenticated, rate-limited request that returns exactly one fact. When the same agent asks through your contact form, you get an unauthenticated blob of text that a human or an AI has to interpret, verify against your order system, and answer in prose the agent then has to re-parse. Same question, three times the cost, more room to get it wrong.

There's a quality argument too. An agent that can't reach a reliable source will do what it does everywhere else: infer. It will read a 2023 blog post about your return policy and tell your customer they have 60 days when they have 30. You'd rather it asked you.

And there's a strategic one that I think is underrated. Agent-mediated purchasing puts the merchant in the position of serving a customer they never speak to. Being reachable by that customer's agent, cleanly and on your terms, is how you stay in the relationship rather than becoming an inventory feed. The teams that get this right will look, in three years, the way mobile-first teams looked in 2012.

The case against, which is stronger than most vendors admit

I'd be doing you a disservice by only arguing one side. There are real reasons to wait, and some of them are good.

• Volume asymmetry. A human asks once. An agent asks ten times, in parallel, and retries on timeout. If your support endpoint is cheap to call and expensive to serve, you've built a cost centre that scales with somebody else's retry logic rather than with your customer count.
• The abuse surface is genuinely new. An authenticated action endpoint that can initiate refunds is an endpoint that can be driven by a compromised agent, a prompt-injected one, or a straightforwardly malicious one. The enterprise security checklist for AI support applies here with more force, not less.
• No standard has won yet. A2A has the strongest position and Linux Foundation governance behind it, but agent identity, payment authorisation, and capability declaration are still three separate specs from three different places. Building deeply against any one of them in 2026 carries rework risk.
• Your metrics will break. Deflection rate, tickets per customer, CSAT: all of them assume a human on the other end. An agent doesn't fill out a survey and doesn't get frustrated. You will need new measures before you can tell whether the thing is working.
• Support is not a profit centre. Engineering time spent on an agent-facing surface is engineering time not spent on the product. For a company with 400 tickets a month, this is a solution looking for a problem.

The honest summary: rungs one and two are close to free and worth doing almost regardless of size. Rungs three and four are a real bet, and the case for taking it depends heavily on whether your customers are technical, whether your ticket volume is high and repetitive, and whether your product already sits inside somebody's automated workflow.

How to tell whether it's your problem yet

Four signals worth checking before you commit anything:

• Agent traffic in your logs. Filter your help centre access logs by known agent user-agents. If a meaningful share of your help traffic is already non-human, the decision is being made for you.
• Structured-looking tickets. Support email that arrives well-formatted, precisely scoped, oddly polite, and at 3 a.m. is a tell. Count them.
• Repetitive status queries. If order status, shipment tracking, and account state make up a large slice of your queue, rung two pays for itself quickly.
• Customer-side automation. If your customers are B2B and already integrating with you, their agents will find you before consumer agents do.

If none of those are true, do rung one, publish clean machine-readable help content, and revisit in six months. That's a defensible answer and I'd give it to most companies under a few thousand tickets a month.

What we'd actually recommend

Ship the content layer now. Serve markdown, publish an index, keep your help centre accurate. This is the cheapest reputation insurance available and it improves what every AI system says about your product whether or not it ever hits an endpoint.

Then build rung two against a real ticket category rather than as a platform project. Pick order status or subscription state, expose one authenticated read endpoint, and measure whether the matching email volume drops. If it does, you've got evidence for rung three. If it doesn't, you've spent two weeks and learned something.

Gate rung three behind an actual security review, not a checklist. Scope tokens to a single account, cap what an agent can do without a human confirmation, rate-limit aggressively, and log everything in a form you can replay. Treat every inbound agent request as untrusted content, because that's exactly what it is.

Rung four can wait for most people. Signed agent cards are the right long-term shape and A2A is the right bet, but there is no penalty for arriving in 2027 with a well-built version instead of arriving in 2026 with a fragile one.

Where Robylon sits in this

Robylon's email agents resolve 60-80% of customer emails autonomously, and a large part of that is action-taking rather than answering: querying an order, processing a refund, updating a record across 60+ write-access integrations. That machinery is, functionally, a support API with an email front end. The same capability that lets our agent resolve a WISMO email in 30 seconds is the capability an external agent would call.

Which is the practical shortcut for most teams. You don't need to build an agent-facing support surface from scratch if the resolution layer already exists and already has the guardrails, the escalation rules, and the audit trail attached. The interface in front of it is the easy part. We'd rather teams got the knowledge and action layer right first, then decided what to expose.

For the payments-side version of this question, what happens when the agent on the other end has signed authority to spend money, see AP2 and agentic payments for refund and billing email. It's the same argument arriving through a different door.

Frequently Asked Questions

What is a support API for AI agents?

It's an interface that lets a customer's AI agent get support answers and take support actions programmatically instead of going through a contact form or an email thread. It ranges from machine-readable help content at the simplest end to authenticated endpoints for checking order status or initiating a return, up to a published agent card that any external agent can discover and call. Most teams start at the content layer, which requires no new infrastructure.

Do AI agents really read help content that often?

Yes, and the share is rising fast. GitBook's May 2026 analysis found AI agents accounted for 51.8% of intentional documentation reads across its hosted sites, up from under 10% in early 2025. Mintlify measured agents at roughly two-thirds of docs traffic by mid-2026. Help centres aren't identical to developer docs, but they're consumed by the same systems, so assume your knowledge base has two audiences.

Is this a security risk?

Read-only endpoints are low risk if properly authenticated and scoped to a single account. Write access is a different matter. An endpoint that can initiate refunds or change account details is reachable by compromised and prompt-injected agents as well as legitimate ones, so it needs scoped tokens, aggressive rate limits, and human confirmation above a value threshold. Treat every inbound agent request as untrusted input, because that's what it is.

What's the difference between this and a normal public API?

Scope and audience. A product API is built for developers who read documentation, write code, and maintain an integration over time. An agent-facing support interface is built for an autonomous caller with no prior relationship, which means capability discovery and identity verification matter far more than developer ergonomics. Standards like A2A's signed agent cards exist specifically so an agent can authenticate and call without a bilateral integration agreement in place.

Should a small support team do this?

Probably not beyond the first step. If you handle a few hundred tickets a month, publishing clean machine-readable help content is worth the afternoon it takes, and everything past that is premature. The signals that justify going further are high repetitive volume, technical or B2B customers, and measurable agent traffic already showing up in your help centre logs. Without those, wait and revisit.

Ready to give customer agents something real to talk to? Robylon AI resolves 60-80% of customer emails autonomously with AI agents that take action across Shopify, Zendesk, Salesforce, and 60+ other integrations. Start free at robylon.ai