Match a proposed purchase to the buying policy and the delegation of authority as they stood on that day, then hold each exception with its reason and its approver for a named delegation owner.
An exception is sought, and the rule it would set aside is named before anything else is written.
02
A rule is breached, and the purchase is read against the policy version that was live on that day.
Reason
03
An approval is offered, and the delegation record is taken as it stood then, not as it reads now.
04
A reason is entered, and what would have happened had the rule held is asked for beside it.
05
An exception recurs in one category, and the run of them is raised rather than the latest one alone.
Decide
06
A rule no system can test is marked untestable, and it is never quietly scored as passed.
07
An approver has changed role since the delegation was written, and the approval is flagged for it.
Out
08
An exception is granted and never revisited, and it stays open in the log until somebody closes it.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Checking, recording and pattern-finding belong to the agent. Granting an exception belongs to a named delegation owner, who signs it and owns it from there.
Example workflow
One proposed purchase, request to record
AgentHuman
1Purchase proposedA requisition, a draft order, a renewal or a card purchase already made
2Policy and delegation read as at the dayThe policy version live then, the thresholds it set and the delegation record as it stood
3Rules tested and exceptions listedWhich rules pass, which are set aside and which no system can test
4Controls appliedThreshold checks, delegation checks, version checks and rule-test confidence
No human action required
Stages 1 to 4 run unaided, and no exception is granted at any of them — the agent is checking, and the delegation lane opens at the exception gate.
5DecisionSplits at the exception gate
Policy met throughout
Goes to the delegation owner to record.
Anything set aside
Adds a category read first.
Delegation review
The purchase is held with the rules it failed, the reason offered and who may approve it.
Record · Amend reason · Send to delegation review
Recorded — by the delegation owner▼
6Purchasing and policy records updatedOnly where write access and records policy allow it
7Outcome evaluatedRule-test accuracy, delegation matches, owner corrections and what review found
Corrections
Every correction the owner makes is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Granting an exception to the buying policy.
Approving a purchase outside the delegation.
Deciding that a policy rule is unreasonable.
Rewriting a rule in the buying policy.
Automation boundaryAgent acts unaided
✓Test the purchase against the policy live that day.
✓Read the delegation record as it stood on the day of approval.
✓Record each exception with the reason given and the approver named.
✓Show the same exception granted again and again.
No exception is granted except by a named delegation owner, inside the boundaries agreed.
Judging whether a recorded reason is good enough.
Telling an auditor the policy was complied with.
Choosing who may approve at which threshold.
Changes to the policy, the delegation or the thresholds.
Example output
One proposed purchase, annotated
Our tail-spend agent buys inside a policy; this one is about the policy itself and what happens when it is set aside, and below is one purchase as the agent leaves it.
Policy check output · single purchaseIllustrative example
Purchase
Recorded as
Rule set aside
Evidence of record
Confidence
Held for
Renewal, one business unit
Above the delegated limit
Exception, not granted
Policy record, 3 August 2026
Held unrecorded
The delegation owner, by name
As receivedRead off the purchase as proposed and the policy live that day, and it claims nothing past those.
What the record holdsThe rule set asideThe reason givenThe delegation record
Why no exception hereGranting an exception is a judgement a named delegation owner owns.
ActionRecordAmend reasonSend to delegation review
What the score decidesBelow the configured threshold a check picks up a second read before the owner 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 purchaseAgainst the policy live that day
03Evidence
Where the evidence is used
Where an exception was recorded against the wrong rule and the purchase has already been made, the owner reopens it with its policy trail attached and the case joins the suite.
01Approved path
The exception is the policy
What a company permits is the document plus the exceptions granted against it, and only the first half is ever read.
02Human review
What was checked, and not found
No rule consulted requires a company to hold a buying policy at all, still less what it should say: the policy and the delegation beneath it are instruments a company writes for itself. What is measured here is your own policy and whether a purchase met it.
04Build an evidence trail
The exception, the reason recorded for it and the approver who granted it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Purchasing systemsSAP Ariba · Coupa · Jaggaer Requisitions and the approval steps
Policy and delegation recordsPolicy library · DoA tables Thresholds and signing limits
Identity and role recordsHR systems · directory groups Role changes, leave cover and acting up
Agent
Buying-policy compliance
Reads the policy Tests the purchase Holds for the owner
Finance and auditERP ledgers · card programmes Internal audit and exception reporting
Delegation-limit exceptions absorb the corrections
A type-level reason-coverage figure can read clean while delegation-limit exceptions carry most of the entries that had to be corrected. Nestack reports the correction rate by exception type, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Delegation-limit exceptions
10.0%
3.7×
Review
Single-source exceptions
7.1%
2.6×
Review
Retrospective approvals
4.4%
1.6×
Watch
Catalogue purchases
1.8%
0.7×
Normal
Bar: correction-rate lift vs. catalogue-purchase baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What an unread exception log costs
The cycle closes when the exception granted without a reason is a regression case. That suite is what the next approval is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises on delegation-limit exceptions.
02Diagnose
The exception approved by somebody who was not, on that day, allowed to approve it is worked backwards until one cause is left standing.
03Improve
A change ships numbered, and the exceptions that caused it travel beneath it.
04Verify
Each touched exception case is run once more, and one red stops it.
05Learn
The case is kept for good, and the approval rules move with it.
Learn → DetectThe return edge. The next approval 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, policy and delegation logic, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Policy discovery and automation-boundary definition.
02Policy, delegation and purchasing sources.
03Buying-policy rule and delegation-coverage mapping.
04Purchase capture and policy normalisation.
05Rule testing and delegation binding.
06Confidence scoring and exception routing.
07Delegation review workflow.
08Purchasing and policy integration.
09Exception and approval cases.
10Guardrails and delegation controls.
11Exception-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 entity, one policyProductionProduction purchasing workflowAdvancedMultiple entities / policies
Introduced at Pilot
Policy checking to your rules✓✓✓
Named delegation-owner recording✓✓✓
Policy-and-limit baseline✓✓✓
Introduced at Production
Reporting by exception type—✓✓
Delegation review workflow in your systems—✓✓
Approved write-back—✓✓
Approval-workflow integration—✓✓
Introduced at Advanced
Multi-policy rule sets——✓
Cross-entity exception packs——✓
Large purchase volumes——✓
Multi-entity delegation controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, purchase 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 policy and the delegation beneath it→Policy capture and version bindingWeek 1
02Representative purchases from a recent buying period→Rule encoding, delegation binding and the check baselineWeek 2
03Your exception log and the reasons already recorded→Policy mapping, delegation binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Policy, delegation and purchasing source assessment, then integration setupWeek 2
05Exceptions you would not want audited→Approval cases and the evaluation runWeek 4
06What no policy exception may authorise→Confidence scoring, exception routing, guardrails and release controlsWeek 3
07A named delegation owner who records the exception→Release to the delegation owner, 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
The columns are counted rather than drawn to fit; a pair in the fifth week is a pair that runs.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Policy discovery, delegation mapping and the automation boundaryW2Purchasing integration and the policy-and-limit baselineW3Rule testing, exception logic and release controlsW4Evaluation suite, approval cases and failure-mode testingW5Approval-workflow integration, pilot checks and targeted correctionsW6One policy cycle run under the delegation owner, then Agent Care handover
Reading the bandEach bar covers only the weeks its own work is named for, and the fifth week carries two by design.
At the end of W6Once the exception record validates, Agent Care picks the agent up.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Procurement AI agent
Build a buying-policy compliance agent around the exception log nobody has read.
Show us your buying policy and the exception log sitting behind it. What has your company actually permitted this year — the policy plus everything granted against it, and the second half is the half nobody reads. An approval outside the delegation comes back as a finding.
