Agents are starting to buy. The decision stays on your IBM i.
Shopping agents can now go from search to paid order. When one reaches a business that runs on IBM i, the decisions it needs, whether this customer qualifies, what it costs, what's in stock, already live in your RPG and Db2. Pegasus Commerce lets agents buy while those decisions stay exactly where they are.
Coming soon for clients · demo store running today
01 · Running today
An agent shopped. The store held the line.
Alder & Pine Home is a demonstration furniture store running Pegasus Commerce, with Silver Lake Financial Group as its lender. On October 1 we connected an AI shopping agent to it, gave it a $5,000 spending limit through the store's own consent page, and asked it to shop.
01 · Bought
$1,899
The agent found the Harlow sofa and sent the cart for approval. The shopper reviewed it and paid on their own device. The agent got back the order number, never how it was paid.
02 · Refused
$4,980
The Marlow sectional, with $1,899 already spent against $5,000. The store refused the cart before the shopper ever saw it.
03 · Allowed
$7,500
The shopper raised the limit. The same cart went through, to the shopper, for approval. The agent proposed; the person decided.
02 · The crossing
The credit decision never leaves IBM i.
At the same checkout, a shopper can finance with Silver Lake. That decision isn't made by the store, by Pegasus Commerce, or by the agent. It's made where the lender has always made it.
The shopper
Chooses Silver Lake financing at checkout, on their own device. The agent is not in this step.
Pegasus Commerce
Asks the lender through the same interface every payment provider uses. It never decides credit.
IBM i
The request crosses through a gateway to the lender's IBM i, where LoanIQ runs the SP_ELIGCHK stored procedure: the lender's own decision logic, on its own system of record.
What crosses
A participant id and the amount. No SSN. No date of birth.
What comes back
A decision. A test shopper, Maya, was approved, Tier A, in 840 ms. She accepted the terms herself, and the acceptance was written back to IBM i.
The record
Every step, the request, the decision, the acceptance, lands on a hash-chained record that a public endpoint verifies end to end.
840 msa live credit decision from the lender's engine on IBM i, at checkout
0SSNs or birth dates sent to the box: only an id and the amount
275 / 275automated probes pass, including the cheats that must fail: no key, a forged key, over the limit, expired permission
The agent is brought to the decision. The decision is never brought to the agent.
03 · How it's governed
The same line of authority we build every team on.
Every Pegasus4i agent team runs on one rule: agents propose, a named person commits, every step logged. Pegasus Commerce is that rule, applied to buying.
Approved doorway
One door, a key per agent
Every agent that can buy carries its own key and is set to blocked, browse or transact. No key: it can look, at most. It never buys.
Next: signed agent credentials (Know Your Agent)
Set limits
The store holds the line
The shopper sets each agent's limit and end date. The store enforces it across every cart, so splitting a purchase doesn't get around it.
A named person commits
The shopper pays, the lender decides
Checkout charges nothing. The shopper approves and pays their way. Only the shopper accepts terms; only the lender decides credit.
Every step logged
A record you can prove
Requests, refusals, approvals, purchases and credit decisions, chained so that editing any entry breaks everything after it.
Next: the merchant console
04 · Know Your Agent
Their agent has a job title. Your platform decides what that job may touch.
Business agents now act for a role, not just a person: an agent working “on behalf of a specific role in an organization, like an analyst in your finance department,” carrying an identity its own vendor attests. When that agent reaches your IBM i, the vendor’s attestation doesn’t travel with it. Your side of the crossing has to answer four questions: who is the agent, who authorized it, what may it do, and how far does that authority travel, including whether it stops when the person in the role changes.
IBM i was built for this. Every object carries its own authority, user profiles already model who may touch what, and the journal records every change as it happens. The platform never trusted the application to be honest; it governed what touched it. That is exactly the stance an agent crossing needs.
Identity is not authority. A signed agent can prove where it came from. Your system of record decides what it may do.
Your credit logic already runs on IBM i. We connect it to agent checkouts as a provider: the request crosses in, the decision comes back, the acceptance is written to your system of record, and nothing you don't send ever leaves the box.
For banks, credit unions, captive and consumer finance
We build
Your store, on your system of record
If your catalog, pricing, stock and orders live in Db2, agents should buy against them, not against a copy. We build the store on the system you already run, with Pegasus Commerce's door in front. Scoped per engagement, and yours to keep.
For distributors, retailers and manufacturers
Alder & Pine Home and Silver Lake Financial Group are fictitious demonstration companies. The store runs in test mode: nothing is really sold or lent, and no real money moves.
Start with one decision agents should reach.
Pick the decision your customers' agents will need first: a credit approval, a price, an order. We'll show you the crossing on your own IBM i, governed from day one.