Procurement & sourcing agents.
The obvious build — an agent that reads the bids and ranks the vendors — is the one thing procurement cannot buy, because a losing bidder has a right to the reasons for the award, and "the model scored you 6.8" is not a reason that survives a challenge. The work that actually consumes the weeks is duller and completely automatable: locating, for each of four hundred requirements, where each of nine vendors answered it, and whether they answered it at all. Build the coverage matrix, refuse to build the score, and the rest of the design follows.
Find where the time goes, and it is not the writing.
Sourcing feels like a document-generation problem because documents are its visible output. Time-and-motion says otherwise: drafting an RFP from a template is a day, and evaluating the responses to it is a month.
- The requirement-coverage matrix is the cost centre. Four hundred numbered requirements across nine responses is 3,600 lookups, each one a human reading a 200-page PDF to determine whether requirement 4.7.2 was answered, partially answered, deflected, or silently skipped. This is retrieval and extraction, it is mechanical, and it is where the value is.
- Non-responsiveness is the finding that matters most and is found last. A vendor who did not answer a mandatory requirement may be disqualifiable, and that determination changes the shortlist. Discovering it in week four rather than week one is the single most expensive ordinary failure in the process.
- Comparability is destroyed before evaluation starts. Nine vendors answer the same question in nine formats, nine vocabularies and nine levels of specificity. Normalising them into a common frame — same units, same terms, same granularity — is the step that makes a human comparison possible, and it is exactly what a language model is good at.
- Commercial terms hide in prose. Price is rarely one number. Tiering, minimums, uplift clauses, egress charges, renewal escalators and true-up mechanics are scattered across an MSA and three appendices, and the total-cost model is assembled by hand from them — the same extraction discipline as finance agents.
Run the diagnostic from adapting a playbook before scoping anything: ask the category manager what they did last Tuesday. The answer is almost never "wrote a document". It is "went through the security appendix of two responses looking for whether they support SCIM", which is a search problem wearing a procurement costume.
The agent extracts and compares. It does not score.
This is the load-bearing line in the whole playbook, and it is a design constraint rather than a caution. Split the pipeline at the point where judgement enters.
- On the agent's side: locate the answer to each requirement, quote it, cite the page and paragraph, classify coverage as answered / partial / not addressed, flag internal contradictions between a response and its own appendices, normalise units and terms, and assemble the total-cost model with every input traceable to a clause.
- On the human's side: whether "partial" is acceptable, what the requirement is worth relative to the others, and which tender wins. Those are the acts the buying organisation must own and be able to defend.
- Structured output is what makes the boundary real. The agent's deliverable is a row per requirement per vendor — quote, location, coverage class, confidence — not a paragraph of assessment. A prose summary re-imports the judgement you just excluded, because "vendor A's answer here is stronger" is a score written in words. Force the shape with structured outputs.
- Abstention beats a guess, at a wider margin here than almost anywhere. "I cannot find an answer to 4.7.2 in this response" is a valuable and actionable output. A fabricated locator is worse than useless: it sends an evaluator to a page that does not contain the claim, and if it survives to the award record it becomes a factual error inside a decision somebody may litigate.
The objection is always "but the model could score it, and a human reviews the score". That anchoring is the problem. A reviewer handed a ranked list checks the ranking; a reviewer handed a coverage matrix evaluates the tenders. The order in which you present the work determines which of those two things actually happens, and only one of them is the job.
Design backwards from the challenge, not forwards from the workflow.
Procurement is one of the few business processes with an adversary who is entitled to your reasoning. Under the EU public procurement directives a contracting authority must tell unsuccessful tenderers why they lost, and must then wait out a standstill period — at least 10 calendar days when notified electronically — during which a disappointed bidder can demand a debrief and file a challenge before the contract is signed. Private-sector sourcing has no standstill, but it has vendors who escalate to your executives and, in regulated industries, an internal audit function that will ask the same questions.
- The award decision must be attributable to named people against published criteria. Criteria and weightings are fixed in advance and are not supposed to move during the process; an evaluation rationale that traces to a model, or that no individual will put their name to, is the failure mode to design out.
- Every factual assertion in the evaluation must have a locator. "Vendor B does not offer regional data residency" needs to point at the sentence that supports it. Getting that wrong is not a quality issue, it is the substance of a challenge — and it is why the extraction layer needs the citation discipline in source-attribution UX, with per-claim spans rather than document-level references.
- Keep the machine contribution separable in the record. The award file should make it obvious which findings were extracted, which were verified by whom, and which were judged. Blending them produces a record where nobody can later say what the human actually decided — the distinction accountability and roles exists to preserve.
- Retain the inputs, not only the outputs. The submitted documents, the extraction results, the version of the prompt and model that produced them, and the reviewer's corrections all belong in the file, on a retention schedule that outlasts the limitation period for a challenge — see audit trails.
- Disclose the tooling if you would be uncomfortable being asked. Some public bodies now require it, and the test is simple: if learning that an agent pre-processed the responses would change a bidder's willingness to accept the outcome, you needed to say so up front.
Bid isolation is an architectural requirement, not a policy.
Every response you receive is confidential to its sender, and the information most useful to your agent — pricing, architecture, named subcontractors, roadmap commitments — is the information most damaging to leak to a competitor. Procurement is therefore a multi-tenant problem where the tenants are actively adversarial to each other, and the buyer is liable for the boundary.
- One index per bid, not one index per tender. A shared vector store over all responses will, sooner or later, retrieve vendor A's pricing while answering a question about vendor B, and the leak will be invisible because the answer will read fine. Partition at the store level; do not rely on a metadata filter you might forget to apply. The isolation shapes are in multi-tenancy for agents.
- Comparison happens over extracted facts, not over raw context. Build the per-vendor matrix in isolated runs, then compare the resulting rows. Never put two vendors' documents in the same context window — that is the single change that removes most cross-contamination risk.
- Watch the outbound side too. An agent drafting a clarification question to vendor B has a bidder's confidential material in its history. Treat outbound drafts as an exfiltration surface with a human release gate, on the reasoning in data exfiltration risks.
- Check what your NDA actually permits. Many vendor NDAs restrict disclosure to named evaluators and say nothing about processing by a third-party model API. That is a question for legal before the tender opens, not after a vendor asks — and it belongs in your data governance policy alongside the retention answer.
- Assume submitted documents are untrusted input. A vendor with an incentive to be shortlisted is submitting a document that a model will read. Instructions embedded in a PDF aimed at an evaluating agent are a low-effort, high-payoff attack, and the response file is one of the few channels where the attacker is a known, motivated commercial party.
The deadline is a hard real-time constraint, and it points both ways.
Most agent domains have soft latency requirements. Procurement has a submission clock that does not move, and in public tenders late submissions are typically inadmissible with no discretion to accept them. That changes how the loop is allowed to behave.
- Bound every run in wall-clock, not in steps. An agent that retries a flaky parse for two hours on the afternoon of a deadline has produced a business loss that no accuracy metric will show. Time budgets belong in the task definition, with a degraded but complete output as the fallback.
- Submission is irreversible and belongs behind an explicit human gate. Uploading to a tender portal, signing a bid, or clicking accept on a supplier agreement are one-way doors — the human-in-the-loop pattern applies to the act, not to the plan that preceded it.
- Clarification windows close before the deadline does. The chance to ask the buyer a question typically expires days early, so an agent that surfaces an ambiguity on the final morning has surfaced it too late. Front-load the ambiguity-detection pass; it is the highest-value early output on the sell side.
- Deadline pressure is when the isolation gets broken. The evening before a submission is when somebody pastes three vendors' pricing into one prompt to "just compare them quickly". Make the safe path the fast path, or the constraint in the previous step will not survive contact with a Thursday.
The sell side is the same machine pointed the other way — and that is a problem.
The mirror-image build is a proposal agent that answers RFPs and security questionnaires from a library of past responses. It works, it saves real weeks, and the two sides together are quietly destroying the signal the process was supposed to carry.
- Answering questionnaires is a retrieval problem with a maintenance problem attached. The answer library — SIG, CAIQ, and every bespoke variant — is only as good as its freshness, and a confidently-retrieved answer about a control you decommissioned last year is a written misrepresentation to a customer. Attach an owner and a review date to every stored answer, or the library becomes a liability with a search index on it.
- Never let the agent submit an unreviewed factual claim about your own controls. This is not a quality gate, it is the same class of statement as a compliance attestation. The review step is per-answer, by someone who can be wrong about it in a deposition.
- Prose questionnaires have stopped discriminating. When both sides automate, a well-written answer no longer signals anything about the underlying control. The counter-move on the buy side is to ask for artefacts a model cannot generate — the actual audit report, a screenshot of the configuration, an architecture diagram with names on it, a reference call — and to weight those above the narrative. Expect the categories that matter to move this way, as the same pressure did in KYC onboarding.
- Measure the right thing on both sides. The buy-side metric is requirement-location accuracy — for a sampled set of requirements with known answers, did the agent find the right passage, and did it correctly identify the ones with no answer at all? Recall on non-responsiveness is the number that matters, because a missed gap is the failure that reaches the award. The sell-side metric is per-answer factual accuracy against current reality, not similarity to the last submission. Build both into an evaluation harness before you scale usage.
Ship the coverage matrix for one live tender and nothing else: every requirement, every vendor, the quoted passage with a page locator, and a coverage class of answered / partial / not addressed. No scores, no recommendations, no summaries. It is a week of work, it removes the month that evaluators currently spend on lookup, and it fails safely because a wrong locator is caught the moment a human clicks it. The agent's job is to make every claim in the tender findable; the moment it starts ranking vendors you have automated the one decision that must belong to a named human and be defensible to the bidder who lost.
Related: legal agents for the contract-review half of the same pipeline, third-party and vendor risk for what the questionnaires are supposed to establish, document parsing for RAG for getting page-accurate locators out of a 200-page PDF, and adapting a playbook for the method used to derive this one.