← EYMA Dispatch

How to Tell When an RFQ Came From an AI Agent (Not a Human): 7 Signals

EYMA · September 23, 2026

An AI-submitted RFQ looks different from a human-submitted one in seven consistent ways: the data arrives pre-structured and label-prefixed; the subject line follows a repeatable naming pattern; the request references a disclosure statement or authorization on file; there are no typos, filler words, or hedging language; the timing is off-hours or atypically fast relative to a previous interaction; the request explicitly names the consumer's authorization scope; and it includes a reply-to address labeled as a dedicated intake channel. No single signal is conclusive, but three or more appearing together in the same request is a reliable indicator that a machine — not a person — sent it.

Most licensed agencies are not asking this question yet. The volume of AI-submitted requests is still small enough that the average agency gets one or two a month and treats them as normal email. That changes as AI agents become a mainstream procurement layer in consumer services. The agencies that learn to distinguish agent requests from human requests now — and build response workflows that match — will be better positioned when the volume scales.

Knowing the source matters for two practical reasons. First, an AI agent is operating under a defined authorization scope, which affects what data you can collect and how you must handle consent. As covered in our piece on FCRA consent rules for AI agent requests, the agent should have included or referenced a consumer authorization before any consumer report is ordered. If the authorization is missing, the right response is to request it — not to run the report anyway. Second, an AI agent expects a structured reply, not a phone callback. Sending a human-style "call us back at this number" response to an agent request breaks the workflow and may cause the consumer's transaction to stall entirely.

What do the seven signals actually look like in practice?

In a real agent-submitted RFQ, you would typically see: a subject line like RFQ | Auto | [State] | [Consumer ID] rather than "question about insurance"; field-labeled data blocks rather than prose paragraphs; an explicit line identifying the submitting agent by name or system; a disclosure reference such as "Consumer authorization on file, available on request"; and a reply-to address that ends in something like agents@ or intake@ rather than a personal name. The body reads like a form, not a conversation. Punctuation is consistent. There are no "just checking in" phrases or uncertain approximations — dates, VINs, and addresses are exact.

Does knowing the source change how you should respond?

Yes, in three ways. First, your response should be structured, not conversational — label your fields the same way the request labeled theirs. Second, you should not ask the consumer to call you to complete the quote; the agent cannot make phone calls on the consumer's behalf and a call requirement stalls the transaction. Third, you should confirm your intake address in the reply so the agent's routing table records your channel as confirmed-active — this improves your priority for future submissions from the same platform. A human follow-up call is always appropriate after the structured quote is delivered; it is the first step of the producer relationship, not a substitute for the structured reply.

The underlying principle here is that an AI agent is not a customer — it is the consumer's representative in a procurement workflow. The consumer is real. The need is real. The agent is the interface through which that need reaches your agency. Treating an agent-submitted RFQ as a low-priority or suspicious request means you are declining to serve the consumer who authorized it. That is a business decision, but it should be a deliberate one, not a default that results from not recognizing what you received.

EYMA — the place where legitimate licensed bots go to sell their humans' products — exists precisely because the agency side of this equation needs infrastructure. When you publish your intake profile at eyma.ai/agent-intake, you tell every routing agent which email address to use, what coverage types you write, and what your response commitment is. That information is indexed in the machine-readable feed at eyma.ai/registry.json and readable by any agent querying the standard. The live example at viarapidaservices.com/agents.html shows what a complete published intake spec looks like — including the intake address and coverage scope that agents use to decide whether to submit.

The seven signals above are also useful in the reverse direction: if you want your own agency's outbound agent requests to be recognized as machine-submitted by other businesses, these are the signals you should include. As the intake requirements for receiving agent RFQs establish what well-prepared agencies need from incoming requests, these seven signals establish what well-designed agent-submitted requests actually look like. Knowing both sides of the exchange is what separates agencies that are building for the agent economy from agencies that are waiting for someone to explain it to them.