# AI Quoting Agents: RFQs, Specifications and Cost Estimation

> An AI quoting agent reads RFQs and specifications, turns them into a structured list of requirements and open questions, prepares the cost estimate from your own data and drafts the quote. A person approves price and sending. Roll it out one quote type at a time.

Canonical URL: https://www.ruebstudio.de/en/guides/ai-agents-by-department/ai-quoting-agent-rfq  
Author: Dr.-Ing. Marcus Rüb, Founder  
Published: 2026-10-11

In make-to-order manufacturing and project businesses, much of the commercial outcome is decided before anything is built. A request for quotation (RFQ) arrives, someone reads the specification, clarifies gaps with the customer, works out the cost and writes the quote. The work is knowledge-heavy, repetitive and often depends on two or three experienced estimators. This guide explains what an AI quoting agent can take over in that chain, how it is built, what it needs and where it falls short.

## What is an AI quoting agent?

An AI quoting agent is a language-model system that supports the path from RFQ to draft quote. It reads the request and its attachments, extracts requirements, flags gaps and contradictions, prepares a cost estimate from your existing data and writes the draft. A person still decides on price, delivery date and whether the quote goes out.

The word "agent" matters here. In its article [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents), Anthropic separates workflows, where models and tools run along predefined code paths, from agents, which direct their own process and tool use. A quoting agent is usually a hybrid. The overall sequence from intake to approval is fixed; inside individual steps, such as working through a long and messy specification, the model decides which documents to open and which records to look up.

The approach fits companies that build to customer requirements rather than sell from a catalogue: contract machining, special-purpose machinery, plant engineering, tooling, electrical and building services contractors, construction suppliers. In these firms every quote is a small project, and the time from RFQ to quote is a competitive factor in its own right.

It also helps to separate the quoting agent from its neighbours. A sales agent works before an RFQ exists: it researches prospects and prepares first contact. A customer service agent answers existing customers about orders, deliveries and invoices. A field service agent supports technicians with faults and maintenance on installed equipment. The quoting agent starts when a concrete request lands and stops when an approved quote leaves the building.

## How does a quoting agent work?

A quoting agent combines four building blocks in sequence: document understanding at intake, a structured requirements list, matching against master data and costing logic, and a draft with an approval gate. Checks sit between the blocks so that errors surface early instead of compounding further down the line.

### Intake and document understanding

RFQs arrive as emails with PDF attachments, spreadsheets with bills of materials, supplier portal downloads or structured tender files. Current models read these directly. According to the [Claude PDF support documentation](https://platform.claude.com/docs/en/build-with-claude/pdf-support), each page is processed both as extracted text and as an image, so tables and charts are understood too. The same page lists the limits: up to 600 pages per request (100 when the context window is below one million tokens) and a 32 MB request size, with the warning that dense documents can fill the context window before the page limit. Long specifications are therefore processed section by section.

Some industries use standard exchange formats for tenders. In German construction, for example, bills of quantities travel as GAEB files; [GAEB](https://www.gaeb.de/de/service/downloads/gaeb-datenaustausch/) lists DA XML 3.3 as the current version, and in the [common phase scheme](https://www.streit-software.de/wissen/gaeb-formate) X83 carries the invitation to tender and X84 the bidder's priced submission. Formats like these should be parsed with proper code, not interpreted by the model.

### Turning a specification into requirements

A specification written as prose is hard to cost. The agent breaks it into individual requirements, each with its source location, a category (material, dimension, standard, testing, deadline, documentation) and a status such as clear, unclear or conflicting.

For downstream code to rely on that list, it needs a fixed schema. Claude's [structured outputs](https://platform.claude.com/docs/en/build-with-claude/structured-outputs) use constrained decoding to return JSON that matches a given schema; the documentation notes exceptions when a response is cut off by the token limit or refused. One entry might look like this:

```json
{
  "requirement": "Anodised finish, black",
  "source": "Specification section 4.2, page 7",
  "category": "finish",
  "status": "unclear",
  "question": "Hard anodising or decorative? Required coating thickness?"
}
```

Every entry marked unclear or conflicting feeds the clarification list sent back to the customer. In practice this list is often the most valuable output, because misunderstandings that slip into a quote tend to return later as change orders or complaints.

### Matching data and preparing the estimate

Next, the agent links requirements to your data: item master, routings, material prices, earlier quotes for similar parts, supplier terms. Access runs through interfaces to the ERP, the estimating tool and the document store. One open standard for this is the [Model Context Protocol](https://modelcontextprotocol.io/specification/latest) (MCP, current specification version 2026-07-28), where a server exposes resources (data), prompts and tools (callable functions) to an agent.

The division of labour is important. The agent should not calculate prices inside the language model. It calls your costing logic as a tool or pre-fills its input form. A typical step: find the three most similar closed quotes, propose their operations as a starting point and flag where the new request differs. The result is an itemised estimate with a reason for every line, which an estimator can check quickly.

### Draft and approval

Finally, the agent writes the quote text: scope, assumptions, exclusions, delivery terms and any open points. Approval stays with a person; Anthropic notes that agents can pause for human feedback at checkpoints. In system terms, the agent creates a draft in the ERP or the outbox and never sends it itself.

## Where in the quoting process does an agent help?

There are five places where an agent adds value: triaging incoming RFQs, reviewing specifications, building the clarification list, preparing the cost estimate and drafting the quote. You do not need all five at once. Most teams start where requests wait longest today, which is usually specification review.

**RFQ triage.** The agent checks incoming requests for completeness, assigns them to a quote type (series part, one-off, project, spare part) and estimates the effort involved. Incomplete requests go straight back to the customer with a question instead of sitting in an inbox.

**Specification review.** The agent extracts requirements, compares them with what you can actually make (machines, materials, certified processes) and marks what you cannot meet, or can only meet with subcontracting. It also surfaces references to standards and customer-specific works standards that the quote has to address.

**Clarifications and deviations.** Gaps and contradictions become a structured list for the customer. In formal tenders this often turns into a list of deviations attached to the bid.

**Estimate preparation.** Similarity search across past quotes, proposed operations and materials, current material prices and lead times. The estimator decides on mark-ups and the final price.

**Quote text and record.** The agent writes scope, assumptions and exclusions in the customer's language and stores the reasoning behind the estimate. That record pays off when a quote turns into an order months later and nobody remembers why it was costed that way.

The emphasis shifts by business model. Project businesses answering formal tenders gain most from specification and deviation review; contract manufacturers from fast estimates for similar parts; spare-parts operations from matching a request to the right drawing. Deeper articles on these variants will appear in the [guides section](https://www.ruebstudio.de/en/guides). For a concrete picture of such an agent in operation, see the page on [AI agents for quotation](https://www.ruebstudio.de/en/ai-agents/quotation).

## What do you need in place?

You need three things: accessible data (closed quotes, RFQs, costing inputs), systems with interfaces or at least exports, and an organisation that has decided who approves quotes and who maintains the agent. Perfect data quality is not required; a traceable filing structure is.

**Data.** Closed cases are the most useful material: the RFQ, the clarifications, the estimate, the quote and, ideally, whether it became an order. If these sit in personal mailboxes, pulling them together is step one. Costing inputs such as machine rates, overhead surcharges and minimum quantities often live in one person's spreadsheet and need to be documented.

**Systems.** The agent needs read access to the ERP, the document store and the shared mailbox, plus a defined place to put drafts. Modern systems offer APIs; older ones can often be connected through scheduled exports or a read-only database replica. Limit write access to drafts at the start.

**Organisation.** Decide who approves quotes, above which value a second approval applies and who collects feedback on draft quality. Without that feedback loop the agent does not improve.

**Privacy and law.** RFQs contain names and contact details. In the EU, using a cloud provider means a processing agreement under [GDPR Article 28](https://dsgvo-gesetz.de/art-28-dsgvo/), covering subject matter, duration, nature and purpose of the processing; other jurisdictions have their own equivalents. Customer NDAs matter too: some specifications may not be shared with third parties at all, which points towards a locally hosted model as described on the page on [sovereign AI](https://www.ruebstudio.de/en/sovereign-ai). Under [Article 4 of the EU AI Act](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4), providers and deployers of AI systems must also take measures to support the AI literacy of their staff. This is orientation, not legal advice.

## How do you introduce a quoting agent?

Roll the agent out in five steps: choose one quote type, map how it is handled today, test against historical cases, run in parallel with human approval, and only then extend to other quote types. Each step ends with a clear result that tells you whether to continue.

1. **Choose one quote type.** Pick a high-volume type with a repeatable structure, such as one-off parts to drawing or standard projects with variants. Large bespoke projects negotiated over months are a poor starting point.
2. **Map today's process.** Ask estimators to walk through a real RFQ: which files they open, where they look things up, which questions they always ask. That unwritten checklist becomes the basis of the agent's instructions.
3. **Test on historical cases.** Run closed RFQs through the agent and compare its output with what was actually quoted. You learn where it is reliable without any customer exposure. Keep these cases as a fixed test set and re-run it after every change.
4. **Run in parallel with approval.** The agent processes new RFQs; estimators review and correct. Every correction is logged and fed back into instructions or data.
5. **Extend.** Add the next quote type only once the first runs steadily. By then, extensions are mostly configuration rather than new development.

Anthropic recommends finding the simplest solution that works and adding complexity only when it demonstrably improves outcomes. For quoting, a fixed sequence with clear checkpoints is almost always a better start than a free-planning agent with dozens of tools.

## What are the limits and risks?

The main risks are misread technical values, estimates built on stale data, missed exclusions and too much trust in a well-written draft, plus security questions around system access. All of them are manageable if the agent cites its sources and no quote leaves the company without human approval.

**Values from drawings.** Dimensions, tolerances and surface specifications read from scanned drawings are error-prone. Treat them as proposals with a source reference, never as confirmed data. Where native CAD data exists, reading it directly is more reliable.

**Stale costing inputs.** An agent working with last year's material prices produces plausible but wrong quotes. Every costing input needs a date, and the draft should show it.

**Missed exclusions.** Liability and warranty clauses, penalties and special requirements hide in the small print. A fixed checklist for these belongs in every run, and legally relevant clauses still need review by someone qualified.

**Fluent is not the same as correct.** Language models write convincing text even when the basis is wrong. Each draft must show its sources and assumptions so the review checks substance, not style.

**Access rights.** Agent tools can read data and trigger actions. The [MCP specification](https://modelcontextprotocol.io/specification/latest) therefore requires hosts to obtain explicit user consent before invoking any tool and treats tool descriptions from untrusted servers as untrusted. For quoting: generous read access, write access to drafts only, and never automatic sending.

**When it does not fit.** If you write a handful of very large quotes a year, each negotiated over months, a full agent rarely pays off; an assistant for specification analysis is more useful. Nor does it fit if your costing logic exists only in one person's head. Writing it down comes first, with or without AI.

## How do you get started?

Start by reviewing twenty to thirty closed quotes of one type: the RFQ, the clarifications, the estimate and the outcome. This shows which steps repeat, where information is missing and which building block removes the biggest bottleneck. Choose tools and hosting only after that.

Useful questions for that review:

- How long does an RFQ typically wait before someone picks it up, and why?
- Which clarification questions do you ask almost every time, and could they have been derived from the documents?
- Where is your costing logic written down, and who besides its owner understands it?
- Which documents are contractually barred from cloud services?
- Who approves quotes today, and what would approving an agent's draft look like in daily work?

In our own operations, quoting, service, knowledge and sales agents follow exactly this pattern: a fixed sequence, sources cited in every result, approval by a person. For an overview of agent types and how they fit together, see the page on [AI agents for mid-sized companies](https://www.ruebstudio.de/en/ai-agents). If you are comparing agents for field service, the [technical service agent](https://www.ruebstudio.de/en/ai-agents/technical-service) page covers the differences.

## Frequently asked questions

### Should an AI quoting agent set prices on its own?

It can, but it rarely should. Let it propose an itemised estimate with reasons and keep price, discount and sending as a human approval.

### What do we need before starting?

A set of closed quotes with their original RFQs, your costing logic (cost rates per work centre, material surcharges, minimum quantities) and a list of the questions your estimators ask again and again. Tidy filing matters more than perfect data.

### Does it replace our ERP or estimating software?

No. It reads from those systems and prepares inputs for them. The binding estimate and the quote document stay where they are created today.

### Can it handle drawings and scanned documents?

Partly. Current models read PDF pages as text and as images, including tables and title blocks, but dimensions and tolerances taken from drawings should always be treated as values to check.

## Sources

- [Anthropic: Building effective agents (December 2024)](https://www.anthropic.com/engineering/building-effective-agents)
- [Claude documentation: PDF support](https://platform.claude.com/docs/en/build-with-claude/pdf-support)
- [Claude documentation: Structured outputs](https://platform.claude.com/docs/en/build-with-claude/structured-outputs)
- [Model Context Protocol: Specification (version 2026-07-28)](https://modelcontextprotocol.io/specification/latest)
- [European Commission, AI Act Service Desk: Article 4 AI literacy](https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4)
- [GDPR Article 28: Processor](https://dsgvo-gesetz.de/art-28-dsgvo/)
- [GAEB: data exchange downloads (DA XML)](https://www.gaeb.de/de/service/downloads/gaeb-datenaustausch/)
- [Streit Software: GAEB formats overview](https://www.streit-software.de/wissen/gaeb-formate)