Buy inside a policy somebody else wrote, record what was bought and under which rule, surface the small repeated buys that are really one category, and leave the thresholds to a named buyer.
A buy is proposed, and the policy that would let it through is read before a supplier is approached.
02
A buy falls inside a written rule, and it is placed against that rule rather than against a habit.
Reason
03
A threshold is crossed, and the buy stops there for a named buyer instead of being split until it fits.
04
A buy wants a supplier nobody has onboarded, and it waits on that decision rather than routing around it.
05
A buy repeats across teams in small pieces, and the pattern is raised as a category rather than left as noise.
Decide
06
A catalogue line is quoted, and the price it carries is put against the live one before anything is bought.
07
A buy is released, and the rule it was made under, the day and the requester travel with the record.
Out
08
A buy no written policy covers is held and named, and the gap is reported rather than closed by judgement.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Buying inside policy, recording and aggregation belong to the agent. The threshold, the supplier and the exception belong to a named buyer, who owns them from there.
Example workflow
One small buy, request to release
AgentHuman
1Buying request receivedA catalogue line, a supplier quote, a renewal note or a link somebody sent over
2Policy read and rule matchedWhich policy covers this buy, which threshold it sits under and which channel it may use
3Channel and supplier chosenThe catalogue line or the quote, the supplier already on file and the price checked live
4Controls appliedThreshold checks, supplier checks, duplicate checks and policy-match confidence
No human action required
Stages 1 to 4 run unaided, and nothing is released at any of them — the agent is matching to policy, and the buyer lane opens at the release gate.
5DecisionSplits at the release gate
Inside policy and threshold
Goes to the named buyer to release.
Anything above
Adds a category read first.
Buyer review
The buy is held with the rule it matched, the supplier chosen and the price checked against live.
Release · Reprice · Send to category review
Released — by the named buyer▼
6Purchasing and card records updatedOnly where write access and records policy allow it
7Outcome evaluatedPolicy match, threshold accuracy, buyer corrections and what the read found
Corrections
Each buyer correction made in review is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Setting the threshold a buy may pass under.
Approving a purchase the agent itself proposed.
Onboarding a supplier for a single buy.
Deciding a buying policy does not apply.
Automation boundaryAgent acts unaided
✓Match the buy to the written rule that permits it.
✓Record the buy, the rule it was made under and who requested it.
✓Show the small repeated buys across teams that are one category.
✓Check a catalogue price against the live one.
No buy is released except by a named buyer, inside the boundaries agreed at implementation.
Judging that a buy is too small to check.
Telling a team its small spend needs no category.
Choosing which card a purchase goes on.
Changes to thresholds, policy or the catalogue.
Example output
One small buy, annotated
This serves a buying team whose smallest purchases are too many to review one at a time and too many to leave alone; below is one buy exactly as the agent leaves it.
Buying output · single purchaseIllustrative example
Buy
Recorded as
Requester
Evidence of record
Confidence
Held for
A one-off part for one team
Bought from the catalogue
Inside policy, unreleased
Policy record, 3 August 2026
Held unreleased
The named buyer, by name
As receivedRead off the catalogue line, the live price and the policy rule it matched, and it claims nothing past those.
What the record holdsThe request as sentThe rule it matchedThe price checked live
Why no release hereReleasing a buy, however small, is a judgement a named buyer owns.
ActionReleaseRepriceSend to category review
What the score decidesAbove the configured threshold the buy collects a category read before the buyer sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every buyAgainst the policy that allowed it
03Evidence
Where the evidence is used
Where a buy went through under a policy that had since changed, the named buyer reopens it with its trail attached, the rule is re-run against the live policy, and the case joins the suite.
01Approved path
Small buys, same rules
A purchase being small changes nothing about the supplier behind it, the terms on it or the data that leaves with it — only how much attention it gets.
02Human review
What was checked, and not found
No rule consulted sets a size below which a purchase stops mattering: thresholds are policy a company writes for itself, so what a small buy may bypass and what it may not are choices rather than requirements. What is measured here is your own policy and whether a buy met it.
04Build an evidence trail
The buy, the policy it was made under and the buyer who released it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A channel-level policy figure can read clean while off-catalogue one-off buys carry most of the buys that had to be corrected. Nestack reports the correction rate by channel, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Off-catalogue one-off buys
7.0%
3.7×
Review
Card and expense buys
5.0%
2.6×
Review
New-supplier small buys
3.1%
1.6×
Watch
Contracted catalogue buys
1.4%
0.7×
Normal
Bar: correction-rate lift vs. contracted-catalogue baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a purchase made on a card costs
A loop closes when the buy made outside policy is a regression case. That suite is what the next release made is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises on off-catalogue one-off buys.
02Diagnose
The purchase nobody would have approved, made on a card because approval would have taken a fortnight, is worked backwards until one cause is left standing.
03Improve
Number the change; the buys that drove it ride along with it.
04Verify
One buy case still failing holds the release where it is.
05Learn
It is kept for good, and the threshold rules are rewritten alongside it.
Learn → DetectThe return edge. The next buy 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, buying and policy logic, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Threshold capture and automation-boundary definition.
02Catalogue, card and supplier sources.
03Request-to-purchase and policy-coverage route mapping.
04Buy capture and catalogue normalisation.
05Policy binding and threshold matching.
06Confidence scoring and review routing.
07Buyer release workflow.
08Purchasing and card integration.
09Threshold and policy cases.
10Guardrails and release controls.
11Buy-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 team, one buying channelProductionProduction buying workflowAdvancedMultiple teams / entities
Introduced at Pilot
Buying to your written policy✓✓✓
Named buyer release✓✓✓
Tail-transaction baseline✓✓✓
Introduced at Production
Reporting by buying channel—✓✓
Buyer review workflow in your systems—✓✓
Approved write-back—✓✓
Catalogue-and-card integration—✓✓
Introduced at Advanced
Multi-policy threshold logic——✓
Cross-team aggregation packs——✓
Large transaction volumes——✓
Multi-threshold policy controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild 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.
You bringWe build with it
01Your live buying channels and the policy behind each→Buy capture and channel mappingWeek 1
02Representative small buys from a recent buying period→Channel capture, policy logic and the buying baselineWeek 2
03Your thresholds and the buyers they name→Policy mapping, threshold logic and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Catalogue, card and supplier source assessment, then integration setupWeek 2
05Buys you would not want reviewed→Threshold cases and the evaluation runWeek 4
06What no small buy may bypass→Confidence scoring, review routing, guardrails and release controlsWeek 3
07A named buyer who releases the buy→Release to the named tail-spend buyer, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Nothing was padded to reach the next column; the pair in week five is a real overlap, not a gap.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Policy discovery, threshold mapping and the automation boundaryW2Catalogue and card integration and the tail-transaction baselineW3Policy matching, buying logic and release controlsW4Evaluation suite, threshold cases and failure-mode testingW5Purchasing integration, pilot buys and targeted correctionsW6One buying month run under the tail-spend owner, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and two bands genuinely share week five.
At the end of W6Once the release record validates, Agent Care assumes the agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Procurement AI agent
Build a tail-spend agent around the purchase your approval chain never saw.
Somebody bought something last month on a card because the queue would have taken a fortnight. Show us your buying policy and the buys that went round it, and we will show you which of them were really one category. A purchase nobody reviewed comes back as a finding.
