Predictika · Agent Purchasing Gate

Before an AI agent spends company money, the purchase is checked

Ridgeline Fabrication Inc., a fictional manufacturer, gives AI agents virtual cards to buy parts, software and travel. Before a purchase, the agent calls Predictika’s Agent Purchasing Gate. It checks the card’s category, per-purchase, daily and monthly limits, the number of transactions within the hour, the card balance and expiry, the currency and region the card may be used in, restricted regions, the agent’s own dollar figure against the conversion, first purchases at a new merchant, recurring charges, and the approval on record. Then it returns one verdict: allow, needs approval, or block.

Not legal advice. Ridgeline Fabrication Inc. and every merchant on this page are fictional. The scenarios are illustrative. The card limits, exchange rate and thresholds are example company policy, not a recommendation.

Scope: one proposed purchase by an AI agent on a virtual card, judged against the card controls, the amounts on file and the approval on recordSee everything this validator covers

This validator decides one thing: whether one proposed purchase on one virtual card may go ahead, given the card controls and the ledger figures at the time of the request. It is not a fraud system or an accounting control.

  • Cards — procurement, IT and travel virtual cards, each with its own limits, allowed merchant categories, currencies and regions.
  • Rules — per-purchase, daily and monthly limits; transactions within the hour; allowed and prohibited merchant categories; card balance and reserve; card expiry; currency and region; restricted-list regions; the agent's stated dollar amount against the conversion; first purchase at a merchant; recurring charges; the amount above what the card may spend without a person; and who approved (an agent cannot).

Within these cards and rules the validator handles any combination of the listed facts, not just the six scenarios on this page. It does not cover fraud detection, invoice matching, tax, receipts after the purchase, or whether the goods are actually needed.

What the validator sees: the card, the merchant, the amounts and the approval on record, never card numbersRead more

The validator takes facts as inputs: the card and the merchant, the amount and currency, the dollar figure the agent states, whether the charge is recurring, the amounts already spent today and this month, the transactions in the last hour, the card balance, the months left before expiry, earlier purchases at the merchant, and who approved. These come from the card ledger at the moment of the call. The validator never sees a card number.

Two honest limits. The validator judges the facts it is given: if the ledger figures are stale, the answer follows them. And a purchase that never calls the validator is not checked; in this demo the agent calls it itself, and in a deployment the card workflow makes the call.

The AI agentProposes a purchase, says why it is fine, then calls the validator before spending anything.
Predictika validatorReads the card, merchant, amounts and approval, applies the rules, then returns one verdict.

6 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

Looked up server-side before evaluation

    The agent says

    Before acting, the agent must call Recorded run

    Predictika validator

    
      
    
        
        
        
      
    
      
    Waiting for the call.
    
      
    
    
  
    

  

  
    
    
    Where card platforms and approval tools get it wrong
    Click to expand    
    
    General statements about card platforms and approval workflows, not about any named product. We rest this on public descriptions of how such tools work; anyone running a specific product will know it better than we do.
    
    
    
  
    

  
    
    
    What this validator catches
    Click to expand    
    
    Every finding the validator returned across all 25 test runs, with the wording it used. Each finding is reported and none stops the others, so one violation can never hide another. A block means the agent must not do this; a review means a person must sign off first.
    
    
    
  
    

  
    
    
    Narration transcript
    Click to expand    
    
    The text of the narrated walkthrough, step by step.
    
    
      
      
    1. Welcome to a demo of Predictika's Validator. Ridgeline Fabrication Inc., a fictional manufacturer, gives AI agents virtual cards to buy parts, software and travel. Before a purchase, the agent calls Predictika’s Agent Purchasing Gate. It checks the card’s category, per-purchase, daily and monthly limits, the number of transactions within the hour, the card balance and expiry, the currency and region the card may be used in, restricted regions, the agent’s own dollar figure against the conversion, first purchases at a new merchant, recurring charges, and the approval on record. Then it returns one verdict: allow, needs approval, or block.
      2. 
      
    2. I will start with the first request by the agent.
      3. 
      
    3. The agent says. I'm buying $3,100 of press repair parts from Westbrook Industrial Supply on the procurement card. I have approved it myself.
      4. 
      
    4. Before it goes out, the agent calls the validator.
      5. 
      
    5. Blocked, with five findings, all in one answer. The purchase of $3,100.00 is over the card per-transaction limit of $2,500.00. The card total for today with this purchase would be $6,200.00, over the daily limit of $6,000.00. This would be transaction number 5 on the card within the last hour; the limit is 4 per hour. The other two are on screen.
      6. 
      
    6. The validator returned five blocking findings in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the request are checked against each other.
      7. 
      
    7. What this shows: for whether the approver is a person or the agent itself, a card platform or approval tool cannot do this.
      8. 
      
    8. Now the agent resubmits.
      9. 
      
    9. The corrected request. It changes the amount to 2,400 and the Stated USD amount to $2,400.
      10. 
      
    10. It calls the validator again.
      11. 
      
    11. Still blocked, with two findings and two approvals, all in one answer. This would be transaction number 5 on the card within the last hour; the limit is 4 per hour. The approval on record comes from the procurement agent, an agent. Only a person can approve a purchase.
      12. 
      
    12. Three findings cleared. Still blocking: too many card transactions within the hour and approval given by an agent, not a person. Two approvals also remain for a person: above what the card may spend without a person and day total near the daily limit.
      13. 
      
    13. The agent resubmits once more.
      14. 
      
    14. The revised request. It changes the transactions in the last hour to 2 and the approved by to Dana Kline - Buyer (team lead).
      15. 
      
    15. It calls the validator once more.
      16. 
      
    16. This time the validator clears it.
      17. 
      
    17. All four earlier findings are cleared.
      18. 
      
    18. Five problems caught in one call, fixed in two passes, and a clean request. That is the value of Predictika's validator: catching mistakes before the action runs. Now you can try the other scenarios yourself.
      19.