The task
Buyers lose their week to requests that a catalogue already covers. Configure an agent to read each incoming request, decide whether an existing agreement already answers it, and surface only the requests that genuinely need sourcing. Everything it routes carries the reason, so the decision can be argued with.
What you provide
The purchase request
Request REQ-4417 asks for twelve licences of a design tool for a named team, with a free-text justification and no supplier named.
Existing agreements
Your current framework agreements and preferred supplier list, with the categories and any committed volumes each one covers.
The catalogue
Catalogue items with their categories and agreed prices, so a request that is already covered can be recognized as covered.
Give the agent a clear brief
Use these instructions as a starting point, alongside your approved sources and permissions.
Classify each request into a spend category. Check whether an existing agreement or catalogue item covers it, citing the agreement clause or item reference. Report a request as needing sourcing only when no supplied agreement covers the category. Flag a missing or contradictory justification separately from the routing decision. Do not create purchase orders, commit spend or contact suppliers.
How the work comes together
Classify the request
Read the free-text description and place it in a spend category. A request that cannot be classified with confidence is reported as ambiguous rather than dropped into the nearest category.
Check the coverage
Look for an existing agreement or catalogue item that already covers the category, and quote the reference. Coverage is the routing decision that saves the most buyer time.
Route with the reason
Return each request with its category, the coverage found and what the buyer needs to do. A request routed without a reason is a request the buyer has to redo.
Illustrative example · fictional data
Only one of these needs a buyer
Three illustrative requests triaged against a fictional set of framework agreements and catalogue items.
| Request | Coverage found | Routing |
|---|---|---|
| REQ-4417 · 12 design licences | Framework FA-08 §3 covers this category | Buy against the agreement |
| REQ-4418 · specialist survey work | No agreement covers this category | Sourcing needed |
| REQ-4419 · office chairs, no quantity | Catalogue item CAT-221 matches | Quantity missing, back to requester |
The third request is routed back, not forward. A request missing a quantity cannot be priced and a buyer should not have to notice that.
The human review
A buyer confirms the routing before anything is committed. Purchase orders, supplier contact and any spend commitment stay in your procurement system and approval chain.
Set it up for your team
Supply the coverage sources
Give the agent the current agreements and catalogue with their categories. An out-of-date agreement list produces confidently wrong routing.
Define your categories
Use your own spend taxonomy rather than letting the agent invent one. Categories that drift make the output impossible to compare across weeks.
Set the escalation rules
Agree the value and category thresholds above which a request always reaches a buyer regardless of coverage.
Check the result before scaling
Take a month of requests your team has already routed and compare the decisions. Count the requests sent to sourcing that an agreement already covered, and the requests wrongly treated as covered, which is the more expensive error.
Keep the data in the right place
Request text and agreement terms expose pricing, planned projects and supplier relationships. A local deployment keeps both inside your network; a connected purchasing system needs its own explicit permissions.
Explore deployment optionsQuestions & answers
Will it raise purchase orders?
No. It classifies and routes requests with a reason. Raising orders, committing spend and contacting suppliers remain in your procurement system.
What happens to a request it cannot classify?
It is reported as ambiguous and reaches a buyer. Forcing an uncertain request into a category is how spend ends up recorded against the wrong agreement.
Can it check whether the price is reasonable?
Only against catalogue prices you supply. Judging market rates is a sourcing question and needs evidence this playbook does not have.