The machine that answers the machines

Your inbox is already being read by machines. It is being written to by them, too.

On the buying side of the market, purchasing agents — software that runs sourcing cycles on behalf of procurement teams — already generate and send RFQs at a tempo no team of human buyers ever produced. One agent can run more quote cycles in a day than a department ran in a month: more requests per supplier, more follow-ups, tighter expected response windows, and no hesitation about sending at 11 p.m. on a Sunday. The volume arriving in a supplier's inbox is no longer set by how many buyers exist. It is set by how much compute the buyer's side wants to spend, and compute is cheap.

The asymmetry is the problem

That volume lands on a supplier-side process that, at most companies, is still a person reading email. The numbers of that mismatch are concrete. At the aviation MRO distributor where our production workload runs, manual quote turnaround ran 24–72h — against buyers who decide in about four hours. The first complete, priced answer wins the line, and a hand-built answer arriving on day two is not an answer; it is an archive entry.

Hiring does not fix this. Headcount grows linearly: each person answers roughly what a person answers. Machine-generated volume does not grow linearly — it grows with the buyer's automation budget. A supplier that staffs against last year's RFQ count has already lost next year's math. And the per-RFQ economics go the wrong way: the cheaper it gets to send an RFQ, the more of them arrive with no intent to buy from you, and the more expensive each hand-typed response becomes relative to its win rate.

What the supplier-side machine must do

Answering machines with a machine is not optional at scale. But "automation" is not the bar — a fast wrong answer loses the order and sometimes the account. A supplier-side decision engine has five jobs, and skipping any of them is how automation projects end in a rollback.

1. Read every request completely. Machine-sent RFQs arrive structured; human-sent ones arrive as PDFs, spreadsheets, and three-line emails. The engine extracts every line — part numbers, quantities, certs, delivery terms, deadlines — in whatever form they arrive, with field-level provenance so a disputed extraction is a lookup, not an argument.

2. Ground every answer in live ERP state. A quote is only as good as the state it was priced against. Price, availability, lead time, credit status — read at answer time, not from last Tuesday's export. An answer grounded in stale state is a confident way to promise what you cannot ship.

3. Run the dry run before the write. Nothing posts to the ERP until a dry run has shown what will happen and the result has been reviewed. The write is the last step of a decision, not the first.

4. Keep humans on the consequential gates. Autonomy is a dial, not a switch — set per decision type and per customer. A routine re-quote under a value limit can run on autopilot, inside your rules; a new-customer quote with credit implications routes to a person. Every gate — human or policy — writes to the ledger, a record of every decision: what changed, who approved it, when. The answer to "why did this go out" is always a record, never an interview.

5. Prove it against history. Replay the engine against last month's real inbox before believing it. Accuracy is something you measure and publish, not something the demo implies.

Speed with governance is the whole bar

Speed without governance hallucinates a price once, ships it to a customer at machine tempo, and spends a quarter repairing the relationship. Governance without speed answers Tuesday's RFQ on Friday with a beautifully compliant no-bid. Neither survives contact with a market where the counterparty is software.

The buyer's side made its choice: it automated the ask. The supplier's side now makes its own — answer at machine speed, or stop answering. The only part that is actually a choice is whether the machine doing the answering is one you can audit, gate, and trust with your margins.