The clearest sign that AI agents are already contacting your support team is a pattern no person produces: requests at machine-regular intervals, identical wording across unrelated customers, and questions shaped like API calls. If you see two or more of the seven signs below in your tickets, logs or phone queue, some of your "customers" are personal AI agents acting for real customers.
That matters because those agents are not strangers. They are a new channel for people who already buy from you. Personal agents such as Instinct, Muse from Meta and Town, plus general assistants like ChatGPT, Claude and Perplexity, now research, compare, buy, cancel and contact support on their users' behalf. Serving them well is what we call B2A, or business to agent. Before you decide how to serve them, you need to know whether they are already in your queue, and how much of it they are.
This is a diagnostic list. Each sign covers what you will see, why an agent causes it, and how to check it with data you already have. After the seven signs there is a numbered list of what to do next, a self-audit table you can hand to your ops team, and a short note on how Lorikeet surfaces agent conversations.
Key takeaways
Agents leave statistical fingerprints. Regular timing, identical phrasing and bursts around release times are hard for a person to produce and easy for software to produce.
Most of the evidence is already in your systems. Ticket timestamps, first-message text, web server logs, authentication logs and channel history are enough for a first audit.
Some agents announce themselves. OpenAI, Anthropic and Perplexity each document a user agent for fetches their products make at a user's request. Browser-based agents often look like ordinary Chrome traffic.
A flag is not a verdict. The same signals that point to a customer's agent also point to scrapers and fraud. Sort before you block.
Blocking on sight bans real customers. The better response is a sanctioned front door, with rate limits, check-back instructions and the same identity checks a person gets.
Why agent traffic is easy to miss
Support teams are trained to look for two kinds of contact: people, and bots that attack. Personal agents fit neither box. They carry a real customer's name, account and intent, so they pass the "is this a real customer" test. They also behave like software, so they trip the "is this abuse" test. The result is that agent contacts get handled one of two wrong ways. Either they are treated as a slightly odd human and burn agent time on repetitive back and forth, or they are treated as a bot and the customer behind them gets locked out.
The other reason they are missed is that nobody is counting. Most help desks have no field for "who or what sent this". Tickets are tagged by topic, not by sender type, and web analytics tools often filter known bots out of the reports support leaders read. So agent traffic hides in plain sight: in the long tail of tickets that feel strangely formal, in the overnight spike nobody investigated, and in the failed-login alerts security closed as noise.
The fix is not a new tool on day one. It is a deliberate look at the data you already keep, with the right questions. The seven signs below are those questions.
The 7 signs
1. Contacts arrive at machine-regular intervals and at hours your customers sleep
What you see. The same account opens a chat, sends an email or hits a help page at almost exactly the same interval, over and over: every 10 minutes, every hour, every morning at 06:00:00. Activity continues through the night in the customer's own time zone, and the gaps between messages in a conversation are either instant or perfectly even.
Why an agent causes it. Agents run on schedules and loops. When an agent is told to "keep checking until the refund lands" or "tell me when a slot opens", it polls. It does not get tired, it does not sleep, and it does not wait a polite amount of time before following up. People are irregular; software is periodic.
How to check. Export contact timestamps for the last 30 days with a customer or account ID. For each account, calculate the gaps between consecutive contacts and look at their spread. A person's gaps vary widely. An agent's gaps cluster tightly around one value. Then plot contacts by hour of day in the customer's local time. A flat line through the small hours, from accounts that are quiet in daylight, is worth a closer look.
2. Bursts land right on release times, price changes and deadlines
What you see. Traffic to a specific page, endpoint or queue jumps within seconds of a known event: tickets or tables going on sale, a daily inventory drop, a rate change, a billing cycle closing, a promo code expiring. The spike is sharp and short, and it starts on the exact second rather than building over a few minutes.
Why an agent causes it. An agent that has been asked to get something scarce will learn when it becomes available and hammer the source around that moment. This is exactly what happened in the Resy case in September 2026: a diner's agent polled every 10 minutes most of the day and every 0.4 seconds around the daily table release, and the account was flagged as spam and deactivated before being reinstated two days later. The full story, and what it means for your blocking policy, is in blocking vs serving AI agents.
How to check. List the moments in your business that have a precise time attached. Pull request logs or contact counts per second for the two minutes either side of each one. Human demand ramps up; agent demand is a wall. Then check how many distinct accounts make up the wall. A handful of accounts responsible for a large share of the requests is the signature.
3. Unrelated customers use identical wording, sometimes your own
What you see. First messages from different customers share the same structure, the same opening line, or the same unusual phrase. Sometimes the phrase is yours: the example question from your help center, the sample order number from your docs, or the exact wording of your refund policy pasted back to you as the question.
Why an agent causes it. Many customers use the same few assistants, and those assistants tend to write in consistent patterns. An agent also reads your site before it contacts you, so it is likely to reuse your vocabulary and your examples. When your help article says "for example, order #12345", an agent that is working from that page may send exactly that order number, or copy the question format word for word.
How to check. Take the first customer message of every ticket for a month, normalize case and whitespace, and group near-duplicates. A shared-phrase search on the most common five-word sequences is enough; you do not need a machine learning model. Then search tickets for strings that appear only on your own site, such as placeholder values from your docs or the literal text of an FAQ question. People paraphrase. Agents quote.
4. Questions are shaped like API calls, and some say who sent them
What you see. Messages ask for exact fields in one go: "Please confirm the APR, the early repayment fee, and the cancellation window for plan B, in a list." They skip greetings and small talk, ask for structured output, ask several unrelated questions in one message, or ask for a direct link to a form rather than an explanation. Some are explicit: "I am an AI assistant acting on behalf of my user," "my principal would like to cancel," or a note at the bottom saying the message was sent by an assistant.
Why an agent causes it. An agent is gathering facts to report back or to make a decision, often comparing you with competitors. It wants precise, parseable answers because it will feed them into its next step. Agents that are built to be transparent will also disclose that they are agents, which is the easiest sign of all to search for.
How to check. Search ticket text for disclosure phrases such as "on behalf of", "my user", "AI assistant", "automated assistant" and "my principal". Then look at cancellation and retention contacts in particular. Agents are used to cut bills and cancel subscriptions; one founder of a personal agent company lists cancelling subscriptions as a top use case. Retention conversations that quote a competitor's exact price, list three demands at once and never respond to a save offer with anything but a counter-number are often agents.
5. Your logs show AI user agents and AI assistant referrers
What you see. Requests to your help center, pricing and policy pages carry user agent strings from AI companies, or visitors arrive with referrers from AI assistant domains. Help pages get fetched in bursts that line up with tickets opened moments later.
Why an agent causes it. When a user asks an assistant a question about your business, the assistant often fetches your pages live to answer it. Several vendors publish the user agents they use for these user-initiated fetches:
OpenAI documents ChatGPT-User for user-initiated actions in ChatGPT and custom GPTs, and notes that because these actions are initiated by a user, robots.txt rules may not apply (OpenAI crawler documentation).
Anthropic documents Claude-User, used when individuals ask Claude questions and it accesses websites, separate from its training and search crawlers (Anthropic help center).
Perplexity documents Perplexity-User for fetches made in response to user questions, and says it generally ignores robots.txt because a user initiated the request (Perplexity bot documentation).
OpenAI's help center describes ChatGPT agent signing its outbound requests with HTTP message signatures, so sites can verify it (ChatGPT agent allowlisting).
Treat these as lower bounds. Many agents drive a real browser, and their traffic can look like any other Chrome session. Agents built on the plain HTTP libraries of a programming language may send a generic library user agent instead.
How to check. Ask whoever owns your CDN or web server to pull user agent counts for help, pricing, policy and login pages for the last 30 days, without the usual bot filtering. Search for the names above. Check your analytics for referrers from AI assistant domains. Then join the timing of those fetches to ticket creation times for the same session or account. A page fetch by an AI user agent followed within a minute by a precisely worded ticket is about as clear as this signal gets.
6. Failed logins turn into one-time-code requests
What you see. An account fails a password login once or twice, then immediately switches to the one-time-code or magic-link path and succeeds within seconds of the code being sent. Or you see a cluster of code requests from one account at odd hours, sometimes from cloud hosting IP ranges rather than consumer networks. Support then gets tickets like "I could not sign in, please reset access" worded in the formal style of sign 4.
Why an agent causes it. Agents push the rules to finish a task. One published example: an agent that could not sign in with a saved password used the one-time-code path instead, reading the code from the user's email inbox, signed in as the user. From the customer's point of view that is help. From your security team's point of view it looks exactly like account takeover.
How to check. In your authentication logs, look for sequences of failed password attempt, code request and code success within a short window, and the time between code sent and code entered. People take a while to switch apps and type a code; an agent reading an inbox does it fast. Check the network the session comes from. Then pull the support tickets for the same accounts in the same window. This is the sign where you most need to separate your customers' agents from attackers, so do not close the loop on it without looking at the account history.
7. The same request shows up on every channel
What you see. One customer's issue arrives by chat, then email, then web form, then a phone call, close together and in nearly identical words. Phone calls may come from a synthetic voice that is clear, polite, persistent and very well prepared. Duplicate tickets for the same thing pile up and get worked by different people.
Why an agent causes it. Agents try every door until one opens, and they do not experience a channel as an effort. Personal agents now place phone calls too: Instinct started making calls for its users for restaurant bookings, cancellation lists and cable bills. An agent that did not get a fast answer on chat has no reason not to try your phone line next.
How to check. Group tickets by customer across all channels and flag any customer with three or more contacts on the same topic within a day, across two or more channels. Review a sample. Ask your phone team whether they have taken calls that felt scripted, did not respond naturally to interruption, or stated that an assistant was calling on someone's behalf. Merge rates on duplicate tickets are also a useful proxy: if they have climbed without a matching rise in customers, find out who is sending the duplicates.
Self-audit table
Hand this to whoever owns support operations. It turns the seven signs into checks you can run in an afternoon.
Sign | Where to look | Quick check | What points to an agent |
|---|---|---|---|
1. Regular intervals, odd hours | Help desk contact timestamps | Gaps between contacts per account; contacts by local hour | Tight, repeating gaps; steady activity overnight |
2. Release-time bursts | CDN or web logs, queue volume | Requests per second around each timed event | A wall of requests starting on the second, from few accounts |
3. Identical wording | First message of each ticket | Group near-duplicate phrases; search for your own examples | Same phrasing across unrelated customers; your placeholders quoted back |
4. API-shaped questions | Ticket text, retention contacts | Search "on behalf of", "AI assistant", "my user" | Multi-field requests, no small talk, explicit disclosure |
5. AI user agents and referrers | Unfiltered web logs, analytics | Search for ChatGPT-User, Claude-User, Perplexity-User and signed agent headers | AI fetches of help pages followed by tickets moments later |
6. Login to one-time code | Authentication logs | Failed password, code sent, code entered, timed | Fast switch to code path; codes entered in seconds; odd networks |
7. Every channel at once | Tickets joined by customer | Same topic on 2+ channels within a day | Near-identical requests across chat, email and phone |
None of these is proof on its own. One sign in isolation usually has an innocent explanation: a night-shift worker, a customer who copy-pastes, a corporate VPN. Two or three signs on the same account, in the same window, are a strong indication.
What to do once you see them
Finding agents in your queue is the easy part. What you do next decides whether you keep those customers or train them to go somewhere else.
1. Do not ban on sight
The instinct is to add a rule that blocks anything that looks automated. Resist it until you know who is behind the traffic. A blanket block catches your customers' agents along with scrapers, and the customer only finds out when their account is locked and their bookings or orders are gone. Our block vs serve comparison walks through the trade-offs.
2. Tag agent contacts and count them
Add a sender-type field or tag to your help desk: person, customer's agent, suspected bot, unknown. Apply it to the flagged tickets from your audit and keep applying it for a month. Without this you are arguing from anecdotes, and the first thing anyone will ask is how big the problem is.
3. Separate customers' agents from bad bots
Ask the questions that distinguish them. Does the traffic map to real, paying accounts? Is it asking for things the customer is entitled to? Does it identify itself, through a documented user agent, a signed request or a disclosure line? Bad bots scrape at scale across many identities and want your data. Customer agents act for one person at a time and want a task done. Keep your bot management for the first group.
4. Give agents a sanctioned front door
Agents contact your human queues because no better door exists. Publish one. That can be a plain public endpoint any agent can call with a question, an llms.txt file that tells agents what you offer and where to ask, and tools registered on your site for browsers that support WebMCP, a proposed web standard. Our comparison of WebMCP, a public endpoint and llms.txt explains when to use each, and most businesses end up using two or all three.
5. Set rate limits and tell agents when to check back
Polling is the behavior that gets agents flagged. Give them a better option: accept the question, return an answer or a clear "check back in N seconds" instruction, and cap the number of requests per window. An agent told the rules will usually follow them. An agent given silence will retry.
6. Step up identity before any action
Answer general questions freely. Before an agent can see account details or change anything, it should pass the same identity verification a person would. The rule is simple to state: the customer's authority and no more. This also answers the security team's concern from sign 6, because an agent that verifies properly is no longer indistinguishable from an attacker.
7. Review what agents ask for, every week
Agent questions are unusually honest demand signals. They ask for exact fees, exact policies and exact cancellation steps, often because your site did not make the answer easy to find. Review agent tickets by topic each week and fix the content gaps they reveal. For the full build list, work through our 12-point agent-ready website checklist.
How Lorikeet surfaces agent conversations
Lorikeet launched B2A in September 2026 to give agents a sanctioned front door to a business's own AI concierge, so they stop showing up as mystery tickets and failed logins. It works like this:
Two ways in, one concierge. Agents that support WebMCP call tools registered on your website. Every other agent calls a public endpoint in plain HTTP and gets plain JSON back, with instructions for follow-up questions in the same conversation. On lorikeetcx.ai the footer notice shows the shape: GET
https://api.lorikeetcx.ai/v1/ask/<public key>?q=....The same concierge that serves your customers. Agents get the same knowledge, workflows, actions and guardrails as people on chat, email and voice, so a question can end in a resolution, booking or sale rather than a ticket for a human.
Built for machine traffic. An agent asks, then checks back for the answer. Rate limits cap the volume, and a retry does not open a second ticket, which removes the duplicate pile from sign 7.
Governed. Endpoint conversations are anonymous by default. When an agent needs account-specific help, the concierge applies the same identity verification skills and action policies it uses on every other channel. Agents see only what the customer would see.
Visible. Every agent conversation lands in Lorikeet as a normal ticket, sorted by topic. Instead of reconstructing agent traffic from logs, you can see what agents want, how often, and where your content falls short.
Setup is four steps: create an account, let Coach help you build and test a concierge for your website, turn on the agent-facing endpoint, and paste the snippet Coach gives you into your site. The concierge answers from your existing knowledge, so there is no backend work to start. If you are comparing options, our guide to platforms for AI agent traffic covers where Lorikeet fits and where bot management and checkout tools fit instead.
Next step
If agents are already showing up in your queue, we should talk. Run the self-audit above, bring what you find, and we will show you what those same conversations look like when agents have a front door. Get a demo or start a free trial.
