The estimator is the bottleneck, and RFQs don't make it easy
Almost every job shop and contract manufacturer has the same single point of failure: one skilled estimator who can look at a drawing and produce a defensible number. That person's time is worth spending on the judgment call — what this part should cost, whether the tolerance is really achievable at that price, whether to take the job at all. In practice, most of their day goes somewhere else entirely.
An RFQ arrives as an email with a PDF drawing attached, in whatever format the buyer's own system happened to export. Before anyone can price it, someone has to open the attachment, read the spec, and answer a question that sounds simple and rarely is: have we made this before? If the part number matches something in the ERP exactly, that's easy. If it's the same part under a customer's internal number, or a near-identical variant with one dimension changed, or a drawing revision that looks familiar but isn't quite the last one you quoted — that takes real digging, through a part history that was never organized for fast lookup. Only after that digging is done does the actual pricing judgment even start, and by then the buyer may already be three replies deep with a competitor.
The same pattern repeats on the other side of the shop. A purchase order goes out to a supplier for raw material against a promised delivery date, and nobody circles back until the date has already slipped and a planner is scrambling. A customer calls asking where their order stands, and answering means someone stops what they're doing to check the schedule by hand. A job starts running behind, and the first person to notice is usually the customer, on the phone, asking why it's late.
What the agent does day to day
The agent sits across the inbox, the ERP, and the production schedule you already use — it doesn't ask anyone to log into something new.
- Reads every inbound RFQ — the email body and any attached drawings or spec sheets — and extracts the part number, material, tolerances, quantity, and requested date.
- Classifies the RFQ as a repeat part, a variant, or genuinely new, by checking what it found against your part history, drawing revisions, and past quotes, even when the customer's numbering doesn't match your own.
- Assembles the quote packet before the estimator opens the message — the matching drawing, the last price quoted on this or a comparable part, current shop load, and anything about the customer worth knowing — so pricing starts from a full picture instead of a blank one.
- Chases suppliers on purchase orders with a delivery date that's passed unconfirmed, sending the follow-up and escalating to a buyer when a supplier has gone quiet past a set point.
- Answers order-status questions from customers by checking the real production schedule, not a guess, and replying directly to the routine "where's my order" question.
- Watches jobs against their committed ship date and flags the one trending toward a miss while there's still time to do something about it, instead of leaving the customer's own phone call as the first warning sign.
Every one of those is preparation, communication, or a flag — not a decision that commits the business to a price or a promise.
Walkthrough: an RFQ becomes a ready-to-price packet
A buyer emails a drawing for a bracket, with a note asking for a quote by the end of the week. The part number in the email doesn't match anything in your ERP directly, because it's the buyer's own internal number.
The agent reads the drawing's title block and dimensions and checks them against your part history rather than relying on the number in the subject line. It finds a close match — a bracket quoted eighteen months ago for a different customer, same material, one tolerance tightened. It pulls that prior quote, the drawing revision on file, current shop load for the relevant work centers, and a note that this customer has no order history with you yet. All of it lands in front of the estimator as a single packet, with the match and the difference called out explicitly, before they've done anything but open their inbox.
The estimator still sets the number. If the packet is solid, pricing might take minutes instead of the better part of an hour spent first figuring out whether this part existed before. If the agent can't find a confident match — a tolerance it hasn't seen, a material outside your normal range — it says so plainly and flags the RFQ as new rather than forcing a comparison that doesn't hold up. Nothing goes back to the buyer with a price on it until a person has seen it.
Walkthrough: chasing a supplier before the job stalls
A purchase order goes out for raw material with a delivery date tied to a customer job already on the schedule. Three days before that date, the supplier hasn't confirmed.
The agent has been tracking the PO since it was issued and sends the follow-up automatically — a straightforward check-in, not a renegotiation. If the supplier confirms, it logs the date and moves on without involving anyone. If the supplier goes quiet past the point your team has set as the threshold, the agent escalates to the buyer with the full history attached: when the PO was issued, what was promised, what's been sent since, and which job on your schedule depends on this material arriving on time. The buyer decides whether to push harder, find a backup source, or adjust the schedule — the agent's job was making sure that decision happens while there's still time to act on it, not after the material fails to show.
Walkthrough: the order that's about to miss its date, spotted first
A job is running, and the pace of work against the remaining time to its committed ship date has started to drift. In most shops, nobody notices this pattern forming — it shows up later as a customer calling to ask why their order is late, and then someone scrambles to explain what happened.
The agent compares each open job's actual progress, pulled from the ERP or MES status, against what the remaining time to the ship date requires. When a job's trajectory suggests it's headed for a miss, the agent flags it to the planner with the specifics — how far behind, what's driving it, what capacity might close the gap — well before the date itself arrives. If a customer calls in the meantime asking for a status update, the agent answers from the same real schedule data rather than a stale export, and routes anything that needs an actual commitment — a new date, an apology, a concession — to the account owner who should be making it.
What stays with a person
Nothing here quotes a price, confirms a delivery commitment to a customer, or renegotiates terms with a supplier on its own. Those are decisions that carry real consequence for the business, and they stay with the estimator, the planner, and the buyer who currently make them. What the agent does is remove the digging, the re-typing, and the waiting that sits in front of those decisions — assembling the packet, sending the chase, raising the flag — so the person making the call is working from a complete picture the moment they're needed, instead of starting from nothing.
What this isn't
This is office-side work: reading email, checking records, chasing replies, watching a schedule. It is not computer vision on the line and not predictive maintenance on equipment — both are real disciplines, but both need sensor infrastructure, historian data, and a hardware relationship that sits outside what Calfy builds. If what you actually need is a camera catching defects or a model predicting a bearing failure, that's a different vendor, and we'd rather say so on the first call than stretch an office system to cover it.
Integration notes: ERP, MES, and the inbox you already run
The agent is only as useful as its reach into the systems your plant already runs, and that reach is where most of the engineering effort goes.
Connection. We connect to whatever ERP and MES you run — through an API where one exists, and through a scheduled export, a shared database, or an email-based workflow where it doesn't. A modern ERP paired with an older MES, or no MES at all, is the normal case we build around, not an exception. Calfy doesn't claim a formal partnership with any ERP or MES vendor; the integration is built for your specific stack.
Documents as input. Most RFQs and POs arrive as PDFs, scans, or forwarded emails, not structured data. Reading those reliably — a drawing's title block, a spec sheet's tolerances — is harder than the pricing logic itself, and it's built and tested against your actual documents before anything goes live.
Permissions. The agent gets read access where reading is enough and scoped write access only where the job needs it — updating a status field, logging a confirmed date — never a shared login into your ERP. Every action is logged, so a packet assembled or a supplier chased three months ago can be traced back to exactly what the agent saw.
Where this sits next to the other two pieces. A lot of manufacturing back-office work is better served by a fixed pipeline than by an agent making judgment calls — see workflow automation for manufacturing for the RFQ-to-record and reporting side of that. And a fair amount of what feeds an RFQ packet is really a retrieval problem — finding the right drawing revision or spec — which is the territory covered by knowledge systems for manufacturing. This page is about the middle ground: an agent that decides what an RFQ actually is and chases the people who haven't replied. These are built on the same foundation as Calfy's custom AI agents generally, and the AI agent glossary entry explains the underlying mechanics if you want that first. For the wider view of where all three fit together, see AI in manufacturing operations.