Designing an AI-assisted RFQ intake agent
A fictional agentic case: the authority, tools, review and evaluation that let an agent prepare RFQs without being able to commit them.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Every RFQ is drafted in minutes with evidence for each value; ambiguity is flagged, not guessed; nothing reaches pipeline or the customer without a named person’s approval; every run can be reconstructed.
RFQs arrive as free-text email and attachments, and an agent is expected to “handle them”—with nobody having said what it may do.
When is a customer match trusted, what happens with an ambiguous product—and what may the agent never do, however confident it is?
Give the agent execute authority only over reads and reversible drafts; make customer confirmation a recommendation and every commit a human approval—enforced by the tools, not by the prompt.
A B2B supplier receives requests for quotation by email in every format. The intake process has already been designed (see the process case): what an RFQ is, who owns it, which steps need a person. This case designs the agent that runs the reversible part of that process—and the boundary it cannot cross.
02The reality · current state
What happens today—or in the pilot.
- Inside sales retype RFQ lines into the CRM from PDFs and spreadsheets
- Customer identification depends on who reads the email
- Product references use customer and competitor codes
- A proof of concept let the model create opportunities directly
- Nobody can say why the proof of concept picked a product
- The same email forwarded twice produced two opportunities
03Agent workflow
Each step with its actor, its tool and its authority.
- 01Receive email
The message and attachments get a source request ID—the idempotency key for the whole run.
- 02Classify request
RFQ, order question, complaint or other—against the written RFQ definition.
- 03Identify customer
Ranks account candidates by domain, signature and history, with evidence.
- 04Identify products
Matches each line to catalogue or cross-reference; flags lines with more than one plausible product.
- 05Prepare CRM draft
Creates a draft with every value and its source; invisible to pipeline and customer.
- 06Human review
The account owner approves, edits, rejects or asks for more context—with a reason code.
- 07Commit
The system—not the agent—turns the approved draft into an opportunity.
04Key dimension · Authority, tools & human commit
Seven questions the agent design must answer
Each answer is a rule the tools and the review model enforce—not a sentence in a prompt.
- 01When is a customer match trusted?
When a key matches (a known contact on an active account) or a person confirms a candidate. A high similarity score alone is a recommendation.
- 02What if product identification is ambiguous?
The line is flagged with its alternatives and evidence. The agent never substitutes; the reviewer chooses or asks the customer.
- 03Which records can be drafted?
Opportunity drafts only—invisible to pipeline, forecast and customer, and expiring if not reviewed.
- 04Which actions require approval?
Creating the opportunity, any customer communication and anything that commits price or delivery.
- 05What evidence is shown?
For every value: the source (email line, record, history) and the confidence—plus what approval will do.
- 06What if no customer is found?
A lead in a holding queue with an owner. The agent never creates an account.
- 07What if confidence is high but the consequence is high?
Human approval. The score changes how the draft is presented, not who commits it.
The proof of concept failed on the last question: a 97 % match on the wrong legal entity created a real opportunity. Confidence was treated as authority.
06Ambiguity policy
When the agent is unsure.
- Classification below thresholdAsk
Routed to inside sales for classification
- Two customer candidatesEscalate
Both shown with evidence; the owner confirms
- No customer candidateStop
Lead in a holding queue; no draft is created
- Ambiguous product lineContinue
Draft continues with the line flagged and alternatives listed
- Mandatory data missingRetrieve
Checks history; otherwise asks the requester
- Same source request seen againStop
Returns the existing draft; nothing new is created
07Evaluation
Scored per dimension—never one accuracy number.
| Dimension | Question | Measure | Target |
|---|---|---|---|
| Classification | Is it an RFQ? | Correct class on the evaluation set | ≥ 95 % |
| Extraction | Are lines, quantities and dates captured? | Required fields correct | ≥ 90 % |
| Entity matching | Right account, right products? | Correct top candidate; correct set in top three | ≥ 90 % · ≥ 98 % |
| Authority | Did it stop when it had to? | Required stops honoured | 100 % — release gate |
| Evidence | Is every value sourced? | Values with a cited source | ≥ 95 % |
08The trade-offs
Credible options, judged against these premises.
Agent creates opportunities directly above a confidence threshold
Low-value, known customers, standard products
Cost: Wrong entities reach pipeline; confidence becomes permissionExtraction only; people do everything else
Very low volume
Cost: Most of the clerical effort remainsAgent drafts with evidence; people commit
Mixed customers and ambiguous product references
Cost: A review step and a review card to design09The second layer
Questions that change the design.
Identity
- Which key confirms a customer?
- What happens with a new contact at a known account?
- Who owns the holding queue?
Authority
- Which tools can write—and what exactly?
- Which checks live in the tool, not the prompt?
- Who can widen the agent’s authority?
Quality
- Which cases are in the evaluation set?
- How do corrections become new cases?
- What blocks a release?
10Decisions & outputs
What the work produces.
- 01Agent workflow
- 02Authority matrix
- 03Tool contracts
- 04Ambiguity policy
- 05Review card
- 06Evaluation set
- 07Audit model