Main site

Procurement AI agent · Buying policy

Buying-Policy Compliance AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Named owner
Exception first
After launch
Agent Care

What this agent does

Records the exception, never grants it

In

  1. 01

    An exception is sought, and the rule it would set aside is named before anything else is written.

  2. 02

    A rule is breached, and the purchase is read against the policy version that was live on that day.

Reason

  1. 03

    An approval is offered, and the delegation record is taken as it stood then, not as it reads now.

  2. 04

    A reason is entered, and what would have happened had the rule held is asked for beside it.

  3. 05

    An exception recurs in one category, and the run of them is raised rather than the latest one alone.

Decide

  1. 06

    A rule no system can test is marked untestable, and it is never quietly scored as passed.

  2. 07

    An approver has changed role since the delegation was written, and the approval is flagged for it.

Out

  1. 08

    An exception is granted and never revisited, and it stays open in the log until somebody closes it.

  2. 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

  1. 1Purchase proposedA requisition, a draft order, a renewal or a card purchase already made
  2. 2Policy and delegation read as at the dayThe policy version live then, the thresholds it set and the delegation record as it stood
  3. 3Rules tested and exceptions listedWhich rules pass, which are set aside and which no system can test
  4. 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

  1. 6Purchasing and policy records updatedOnly where write access and records policy allow it
  2. 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 required

8 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 boundary

    Agent 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 purchase

Illustrative example
Purchase
Renewal, one business unit
Recorded as
Above the delegated limit
Rule set aside
Exception, not granted
Evidence of record
Policy record, 3 August 2026
Confidence
Held unrecorded
Held for
The delegation owner, by name

As received

Read off the purchase as proposed and the policy live that day, and it claims nothing past those.

What the record holds

  • The rule set aside
  • The reason given
  • The delegation record

Why no exception here

Granting an exception is a judgement a named delegation owner owns.

What the score decides

Below the configured threshold a check picks up a second read before the owner sees it.

Action

RecordAmend reasonSend to delegation 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 purchase

Against 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.

04

Build 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 systems

    • SAP Ariba
    • Coupa
    • Jaggaer
    • Requisitions and the approval steps

  • Policy and delegation records

    • Policy library
    • DoA tables
    • Thresholds and signing limits

  • Identity and role records

    • HR 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 audit

    • ERP ledgers
    • card programmes
    • Internal audit and exception reporting

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

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

Agent controls

Six pins between the model and the exception log

Six pins set in one lock, the last the deepest. What finally turns is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeNarrow the agent to reading the policy when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and policy rules, and note the version each purchase was checked under.Track
L4TraceabilityRecord each check, the rules tested, the exceptions listed and every read of the file.Record
L3Delegation releaseHold the exception for a named delegation owner; the hold governs release, not whether the reason is sound.Gate
L2Policy guardrailsTest each purchase against the policy version live that day, and refuse a check whose version cannot be fixed.Restrict
L1Confidence thresholdsRoute an untestable rule to a category read before the exception reaches the owner.Require review
Model coreCheck produced — the rules tested, the exceptions listed, the approvers and the confidence
L1 – L2
Test whether a check may stand
L3
Leaves the granting to a delegation owner
L4 – L5
Keep the exception and the reason behind it
L6
Blocks the exception route when signals degrade

How Nestack evaluates it

Evaluate the whole check — not only the exception that comes out.

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

Surface — the exception an audit reads

  1. E1Final-output evaluationDid the check record the policy version it was actually run against?
  2. E2Step-level evaluationDid the agent read the right policy, the right delegation and the live thresholds?
  3. E3Tool evaluationDid it read and write the correct purchase and the correct exception?
  4. E4Confidence calibrationDo low-confidence checks attract more corrections from the owner?
  5. E5Slice evaluationHow does performance change across specific exception types?
  6. E6Business outcomeHow many purchases needed a correction before the owner would record them?

Floor — the policy a company actually runs

Failure modes

Where each failure originates in the agent

Seven failure modes, each sited at the stage it first shows itself.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • OW-03

      Stale delegation record read

      The delegation read is not the one in force.

    Stage gathers

    The policy, the limits, the roles and the dates

  2. 02 · Reasoning

    2 modes

    • OW-04

      Reason that justifies nothing

      The entry records urgency, not why the rule should give way.

    • OW-06

      Superseded policy version worked

      A retired policy version is read as the current one.

    Stage proposes

    The rules tested, the exceptions and the approvers

  3. 03 · Tool / write

    2 modes

    • OW-02

      Untestable rule marked clear

      A rule no system can test is scored as passed.

    • OW-05

      Repeat exception read as new

      The same exception recurs and is logged as first.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • OW-01

      Approved outside the delegation

      The approver was not allowed to approve that day.

    Stage returns

    The exception a log carries and an owner reads

  5. 05 · Change / Version

    1 mode

    • OW-07

      Silent delegation drift

      A role changes while the stored record keeps the old one.

    Stage tracks

    Model, prompt, policy rules and role dates

  • Sev-1 · an approval outside the delegation
  • Sev-2 · an exception recorded with no reason
  • Sev-3 · signals degrade, check held back
See the complete Procurement failure-mode catalogue

Affected slices

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Delegation-limit exceptions10.0%3.7×Review
Single-source exceptions7.1%2.6×Review
Retrospective approvals4.4%1.6×Watch
Catalogue purchases1.8%0.7×Normal

Bar: correction-rate lift vs. catalogue-purchase baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Correction rate rises on delegation-limit exceptions.

  2. 02

    Diagnose

    The exception approved by somebody who was not, on that day, allowed to approve it is worked backwards until one cause is left standing.

  3. 03

    Improve

    A change ships numbered, and the exceptions that caused it travel beneath it.

  4. 04

    Verify

    Each touched exception case is run once more, and one red stops it.

  5. 05

    Learn

    The case is kept for good, and the approval rules move with it.

  6. Learn → Detect

    The 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.

Workstream

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

  1. 01Policy discovery and automation-boundary definition.Week 1
  2. 02Policy, delegation and purchasing sources.Week 1, Week 2
  3. 03Buying-policy rule and delegation-coverage mapping.Week 1, Week 2
  4. 04Purchase capture and policy normalisation.Week 2
  5. 05Rule testing and delegation binding.Week 2, Week 3
  6. 06Confidence scoring and exception routing.Week 3
  7. 07Delegation review workflow.Week 3, Week 4
  8. 08Purchasing and policy integration.Week 5
  9. 09Exception and approval cases.Week 4, Week 5
  10. 10Guardrails and delegation controls.Week 4
  11. 11Exception-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 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 price
Confirmed after discovery based on integrations, workflow complexity, purchase 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 buying policy and the delegation beneath it

    Policy capture and version binding

    Week 1

  2. 02Representative purchases from a recent buying period

    Rule encoding, delegation binding and the check baseline

    Week 2

  3. 03Your exception log and the reasons already recorded

    Policy mapping, delegation binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Policy, delegation and purchasing source assessment, then integration setup

    Week 2

  5. 05Exceptions you would not want audited

    Approval cases and the evaluation run

    Week 4

  6. 06What no policy exception may authorise

    Confidence scoring, exception routing, guardrails and release controls

    Week 3

  7. 07A named delegation owner who records the exception

    Release to the delegation owner, 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 columns are counted rather than drawn to fit; a pair in the fifth week is a pair that runs.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Policy discovery, delegation mapping and the automation boundary

W2Purchasing integration and the policy-and-limit baseline

W3Rule testing, exception logic and release controls

W4Evaluation suite, approval cases and failure-mode testing

W5Approval-workflow integration, pilot checks and targeted corrections

W6One policy cycle run under the delegation owner, 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 by design.
At the end of W6
Once the exception record validates, Agent Care picks the agent up.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your live policy
Named owner
Exception first
After launch
Agent Care available

Nestack Agents · Buying-policy compliance

AGT-PR-12 · Agent Care available after launch

Build a buying-policy compliance agent

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

About you
Your policy

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