Main site

Procurement AI agent · Sourcing

Sourcing and RFQ AI Agent

Unpick the requirement from the incumbent specification it was copied out of, name why each candidate is on the list, and leave the choosing — and any exclusion — to a named buyer.

Typical delivery
4–6 weeks
Deployment
Your stack
Named buyer
Why these names
After launch
Agent Care

What this agent does

Proposes the shortlist, never chooses from it

In

  1. 01

    A requirement lands, and what the business needs is written apart from what the last supplier gave it.

  2. 02

    A requirement is inherited, and the lines traceable to the incumbent contract are marked as inherited.

Reason

  1. 03

    A shortlist is drawn, and each name carries the reason it is on the list rather than a rank.

  2. 04

    A shortlist repeats the last one, and the repetition is reported as a finding rather than as agreement.

  3. 05

    A request is drafted, and a question no supplier could answer from its own records is pulled before it goes.

Decide

  1. 06

    A quote returns on its own basis, and the adjustments that make it comparable are shown one by one.

  2. 07

    A candidate leaves the list, and the reason and the person who removed it are held against the requirement.

Out

  1. 08

    A supplier declines to bid, and the decline is captured and asked about rather than left as silence.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

Separation, candidate proposal, drafting and normalisation belong to the agent. Choosing belongs to a named buyer, who awards the work and owns it there.

Example workflow

One requirement, brief to issue

  1. 1Requirement receivedA buying request, a renewal date, a specification or the contract that is expiring
  2. 2Need separated from incumbentWhat the business needs, what the last supplier happened to provide, and which lines came from which
  3. 3Candidates proposed with reasonsEach name, why it is on the list, and which names the last shortlist carried
  4. 4Controls appliedAnswerability checks, repetition checks, coverage checks and shortlist confidence

No human action required

Stages 1 to 4 run unaided, and nothing goes to a supplier at any of them — the agent is proposing, and the buyer lane opens at the shortlist gate.

5DecisionSplits at the shortlist gate
Shortlist moves off the last one

Goes to the named buyer to issue.

Anything that repeats it

Adds a category-manager read first.

Buyer review

The shortlist is held with the requirement, the reason per name and the names it did not carry.

Issue · Add candidate · Send to category review

Issued — by the named buyer

  1. 6Sourcing and supplier records updatedOnly where write access and records policy allow it
  2. 7Outcome evaluatedShortlist turnover, response comparability, buyer corrections and what review found

Corrections

Each buyer correction is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Choosing which supplier gets the work.
    • Dropping a candidate off the shortlist.
    • Awarding, or committing spend to a supplier.
    • Ruling that two quotes are equivalent.

  • Automation boundary

    Agent acts unaided

    • ✓Separate the requirement from the specification the incumbent wrote.
    • ✓Propose each candidate with the reason it is on the shortlist.
    • ✓Draft the request each candidate is asked to answer.
    • ✓Show every adjustment made to compare two quotes on one basis.

    Nothing is awarded except by a named buyer, working inside the boundaries agreed.

    • Judging whether a market test is needed at all.
    • Telling a supplier why it was not asked.
    • Settling what the business actually requires.
  • Changes to the source list or shortlist rules.

Example output

One shortlist and its request, annotated

A component desk names distribution paths per candidate and a supplier agent orders against approved sources; this is the requirement-to-shortlist step for any category, where the question is why these names.

Sourcing output · single requirement

Illustrative example
Requirement
Indirect category, one site
Recorded as
Shortlist proposed with reasons
Category
Requirement separated
Evidence of record
Requirement brief, 3 August 2026
Confidence
Held unissued
Held for
The named buyer, by name

As received

Read off the requirement as written and the sources on file, and it claims nothing about who should win.

What the record holds

  • The requirement
  • The reason per name
  • The last shortlist

Why the names are unranked

Putting these names in an order is a judgement a named buyer owns.

What the score decides

Where a shortlist repeats the last one it takes a category read before the buyer sees it.

Action

IssueAdd candidateSend to category review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every requirement

From the request that raised it

03Evidence

Where the evidence is used

Where a shortlist went out short of a name that should have been on it, the buyer reopens the requirement, the omission is recorded against it, and the case joins the suite.

01Approved path

A shortlist is a set of choices

Nobody made those choices in one sitting: the requirement narrowed the field, the source list narrowed it again, and the last shortlist did most of the narrowing before anyone sat down.

02Human review

What was checked, and not found

No law examined tells a private company who to invite to quote. Public-sector procurement rules are real, and this page is not about them. Nothing consulted obliges a market test, a floor on how many candidates are asked, a published notice, or a stated reason for leaving a supplier off a list, and nothing sets a period for keeping the reasons. So the discipline here is a control the company chooses to run, and what it is run against is habit rather than a rule.

04

Build an evidence trail

The shortlist, the requirement it answers and the buyer who chose stay together.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Sourcing platforms

    • Coupa Sourcing
    • Jaggaer
    • Keelvar
    • Ariba and RFx event records

  • Supplier and market data

    • Registries
    • directories
    • Trade bodies and market listings

  • Spend and contract history

    • ERP spend lines
    • contract register
    • Prior quotes and awards recorded

Agent

Sourcing and request preparation

  • Reads the requirement
  • Proposes candidates
  • Holds for the buyer

  • Requests and responses

    • Email
    • supplier portals
    • EDI
    • Quotes returned and declines to bid

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six riddles between the model and the shortlist

Six riddles in a stack, the last the finest. What falls through is drawn in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to listing sources when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and sourcing rules, and note the version each shortlist was drawn under.Track
L4TraceabilityRecord each shortlist, the requirement under it, the reason held per name and every read.Record
L3Buyer releaseHold the shortlist for a named buyer; the hold governs release, not whether the names are the right ones.Gate
L2Sourcing guardrailsTest each shortlist against the separated requirement, and refuse a list drawn from the incumbent specification.Restrict
L1Repetition thresholdsRoute a shortlist that repeats the last one to a category read before it reaches the buyer.Require review
Model coreShortlist drawn — the requirement, the names, the reason for each and the confidence
L1 – L2
Test whether a shortlist may stand
L3
Leaves the choosing to a named buyer
L4 – L5
Keep the shortlist and the requirement behind it
L6
Returns to the source list when signals degrade

How Nestack evaluates it

Evaluate the whole selection — not only the shortlist that comes out.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the shortlist a supplier reads

  1. E1Final-output evaluationDid the shortlist record the requirement it was actually drawn against?
  2. E2Step-level evaluationDid the agent read the right requirement, the right sources and the live source list?
  3. E3Tool evaluationDid it read and write the correct requirement and the correct candidate?
  4. E4Confidence calibrationDo low-confidence shortlists actually attract more buyer corrections?
  5. E5Slice evaluationHow does performance change across specific requirement types?
  6. E6Business outcomeHow many shortlists needed a correction before the buyer would issue?

Floor — the market a shortlist actually tested

Failure modes

Where each failure originates in the agent

Seven failure modes, each pinned to the stage where it first shows.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • OG-03

      Stale source list read

      The source list read is not the one now approved.

    Stage gathers

    The need, the sources, the names and the dates

  2. 02 · Reasoning

    2 modes

    • OG-04

      Shortlist repeats the last one

      The names are the names that were asked last time.

    • OG-06

      Retired requirement read as live

      An old specification is worked as the current one.

    Stage proposes

    The requirement, the candidates and the reasons

  3. 03 · Tool / write

    2 modes

    • OG-02

      Thin shortlist passed forward

      A list moves on without the category read.

    • OG-05

      Quote bound to the wrong requirement

      The response is filed against another requirement.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • OG-01

      Issued with the reasons unrecorded

      The record shows the names but not why each is there.

    Stage returns

    The shortlist a supplier reads and answers

  5. 05 · Change / Version

    1 mode

    • OG-07

      Silent source-list drift

      The approved list narrows while stored shortlists keep the old one.

    Stage tracks

    Model, prompt, source rules and list dates

  • Sev-1 · a shortlist issued with no reasons
  • Sev-2 · a repeated list reaches the market
  • Sev-3 · sources degrade, shortlist held back
See the complete Procurement failure-mode catalogue

Affected slices

Renewals carry the repeated shortlists

A requirement-level coverage figure can read clean while renewals of expiring contracts carry most of the shortlists that repeat the last one. Nestack reports the repeat rate by requirement type, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Renewals of expiring contracts9.5%3.7×Review
Incumbent-written requirements6.8%2.6×Review
Single-source technical builds4.2%1.6×Watch
Open specification requirements2.2%0.9×Normal

Bar: repeat-rate lift vs. open-specification baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

What a repeated shortlist costs

A cycle ends when the shortlist nobody could justify is a standing case. That suite is what the next shortlist issued is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Repeat rate rises on renewals of expiring contracts.

  2. 02

    Diagnose

    The three names on the shortlist that were the three names on the last one are worked backwards until one cause is left standing.

  3. 03

    Improve

    The change ships numbered, and the shortlists that forced it ride with it.

  4. 04

    Verify

    One shortlist case still failing is enough to hold the release back.

  5. 05

    Learn

    It is kept for good, and the sourcing rules are amended in the same commit.

  6. Learn → Detect

    The return edge. The next shortlist is measured against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, shortlist and request logic, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Requirement-separation and automation-boundary work.Week 1
  2. 02Sourcing, spend and market sources.Week 1, Week 2
  3. 03Candidate-to-reason and requirement-coverage mapping.Week 1, Week 2
  4. 04Requirement ingestion and normalisation.Week 2
  5. 05Candidate proposal and reason binding.Week 2, Week 3
  6. 06Repetition scoring and review routing.Week 3
  7. 07Buyer review workflow.Week 3, Week 4
  8. 08Sourcing-platform integration.Week 5
  9. 09Requirement and shortlist cases.Week 4, Week 5
  10. 10Guardrails and selection controls.Week 4
  11. 11Shortlist-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne category, one requirementProductionProduction sourcing workflowAdvancedMultiple categories / markets
Introduced at Pilot
Shortlists drawn to your requirements✓✓✓
Named buyer selection✓✓✓
Source-list baseline✓✓✓
Introduced at Production
Reporting by requirement—✓✓
Buyer review workflow in your systems—✓✓
Approved write-back—✓✓
Sourcing-platform integration—✓✓
Introduced at Advanced
Multi-source candidate research——✓
Cross-category shortlist packs——✓
Large source libraries——✓
Multi-market shortlist controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, sourcing volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your live categories and the requirement each starts from

    Requirement capture and incumbent separation

    Week 1

  2. 02Representative requirements and the shortlists they drew

    Source binding, candidate logic and the shortlist baseline

    Week 2

  3. 03Your sourcing calendar and the buyers it names

    Requirement mapping, source binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Sourcing, spend and market source assessment, then integration setup

    Week 2

  5. 05Shortlists you would not want defended

    Requirement cases and failure-mode testing

    Week 4

  6. 06What no shortlist may settle

    Repetition scoring, review routing, guardrails and release controls

    Week 3

  7. 07A named buyer who chooses from the shortlist

    Release to the named buyer, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

The bands here are counted, not spaced to look even; the fifth carries two phases because it does.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Requirement discovery, incumbent separation and the automation boundary

W2Sourcing and spend integration and the source-list baseline

W3Candidate logic, reason binding and release controls

W4Evaluation suite, requirement cases and failure-mode testing

W5Sourcing-platform integration, pilot requirements and corrections

W6One sourcing cycle run under the category buyer, then Agent Care handover

Reading the band
Each bar covers only the weeks its own work is named for, and the fifth week carries two phases.
At the end of W6
When the shortlist record validates, Agent Care takes the agent on.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Procurement AI agent

Build a sourcing agent around the requirement your last shortlist never questioned.

Show us one category you re-tender and the three names that answered last time. If those three are the three that answered the time before, then the shortlist is a habit rather than a market test. A supplier who declined without being asked why comes back as a finding.

Typical delivery
4–6 weeks
Deployment
Your live categories
Named buyer
Why these names
After launch
Agent Care available

Nestack Agents · Sourcing and RFQ

AGT-PR-01 · Agent Care available after launch

Build a sourcing agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your sourcing

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.