Acquisition Is Being Automated. Retention Is What's Left.

What building walletKit taught me about loyalty in the AI era

I've been obsessed with customer retention for a long time now. Not the marketing-conference version of it — the version where you sit with a café owner who has served the same forty people every week for three years and still cannot tell you a single one of their names.

That gap is the whole business. Everything I've built for the last stretch of my life has been an attempt to close it.

Here's where that got me, what I got wrong, and why I think the AI era makes loyalty more valuable rather than less.

v1: right problem, wrong altitude

The first version of walletKit was a loyalty and engagement platform. The pitch was simple and, I still believe, correct: customer apps are a tax nobody wants to pay. Merchants spend real money acquiring someone, then ask that person to download a 60MB app to earn a free coffee. Most people decline. The relationship ends at the till.

So: put the card in the wallet that's already on the phone. No download, no password, no app-store review. One scan, one tap, done.

I launched it thinking about events as the wedge — conferences, churches, campuses, nightlife — because events manufacture the exact thing a loyalty product needs: a crowd of people, all at once, all willing to add something to their phone. That instinct was right. Events are still the cleanest cold start in this category.

What I got wrong was the altitude. I described walletKit as an engagement channel. That framing put me in a knife fight with every loyalty app in the Shopify ecosystem, competing on points mechanics and email templates. It's a crowded, commoditising market — and while I was framing walletKit as a marketing tool, Apple and Google were quietly turning the wallet into something else entirely.

What actually changed underneath us

Somewhere in the last two years, the mobile wallet stopped being a container for barcodes and became a container for credentials.

Apple and Google both now issue government-grade digital IDs into the wallet. Both support selective disclosure — proving you're over 18 without handing over your birthday, your name, or your address. Google open-sourced zero-knowledge-proof libraries to do it. Browsers shipped a standard API for requesting these credentials. The building blocks of verifiable identity went from academic to preinstalled, on nearly every phone, without most people noticing.

That reframed my own product for me. A loyalty card in Apple Wallet isn't a marketing asset that happens to live on a phone. It's a credential that says this person is entitled to something — a rate, an access level, a balance, a tier. The barcode is just the human-readable rendering of it.

Once you see a pass as an entitlement rather than a coupon, the category you're in changes. And so does what you should build.

The pivot: UK, and from channel to infrastructure

Two things moved at once.

Geographically, I moved the focus to the UK and global markets. Not because the original market was wrong, but because the regulatory and platform gravity — digital ID rollouts, age-verification mandates, the EU forcing open NFC access on iPhones — is concentrated here right now, and that gravity creates demand that doesn't depend on me convincing anyone of anything.

Architecturally, I stopped building a channel and started building infrastructure. The product today does the unglamorous work: cryptographic signing for Apple .pkpass and Google Wallet JWTs, a real-time points ledger, a browser-based scanner so no venue has to buy a £500 terminal, push updates straight to the lock screen, bulk provisioning from legacy POS systems, and the analytics to tell a merchant which regulars have quietly stopped showing up.

None of that is exciting to describe. All of it is the difference between a demo and a business.

Why AI makes this more valuable, not less

Here's the part I've been thinking hardest about.

The obvious take is that AI kills loyalty programs — assistants will do the shopping, price will win, brand relationships will evaporate. I think that's exactly backwards, for three reasons.

1. Acquisition is being automated into a commodity.

Every merchant now has access to the same AI tools for ad copy, targeting, creative testing, and bid optimisation. When everyone's acquisition gets equally good, acquisition stops being a differentiator and just gets more expensive — you're all bidding against each other with the same weapons. The asymmetry moves to the part AI can't equalise: whether the customer already has a reason to come back to you. Retention is the last unfair advantage.

2. Assistants are becoming an intermediary layer, and intermediaries erode relationships.

We've watched this movie before. Search engines, then marketplaces, then delivery aggregators — each one made distribution easier and the customer relationship thinner. AI assistants are the next layer, and they'll be the most capable intermediary yet. The merchants who survive that transition will be the ones holding a direct, permissioned line to the customer that doesn't route through anybody's ranking algorithm.

A wallet pass is one of the very few channels with that property. It sits on the lock screen. No CPM, no deliverability rate, no algorithm deciding whether today's message is worth showing. The merchant issued it; the customer chose to keep it.

3. Structured beats unstructured, and passes are structured.

This is the bit most people miss. A pass isn't prose — it's typed, signed, machine-readable data with a defined schema: who holds it, what tier, what balance, what it entitles them to, when it expires. As more commerce gets mediated by software agents acting for customers, the businesses whose customer relationships are already expressed as structured, verifiable data will be legible to that software. The ones whose loyalty program lives in an email list and a spreadsheet will not.

So I built the missing piece

For a while I described this as a gap and left it there. That got uncomfortable, because a gap you can describe but haven't tried to close is just a slide.

Here is the specific problem. When an agent acts for you — books the table, buys the tickets, renews the membership — it can prove two things to a merchant. It can prove it can pay, which is what x402 and the card networks' agent protocols handle. It can prove who it is, which is what agent-identity work like Visa's Trusted Agent Protocol handles.

It cannot prove what you are entitled to. Nothing in that stack carries "the human behind this agent is a Gold member, and this agent may act on that membership up to £150, twice, for the next hour, and no further."

So walletKit now has a delegated authorisation layer, and an open MCP server on top of it. The model is deliberately boring, because the interesting failure modes are all in the details:

• The human is always the holder. The agent is never the holder. In the token the person is the subject and the agent is the actor, never the other way round. An agent can acquire a pass on your behalf; it cannot become the person who owns it. Every issued pass resolves back to the human.
• A mandate is bound to the agent's key, not carried as a bearer token. A stolen mandate is useless without the matching key proof. Bearer credentials for autonomous software are a bad idea and I didn't want to ship one.
• Scope comes only from the signed grant, never the request. An agent asking for more than it was granted doesn't get more. It gets refused, or the request goes back to the human.
• Above a threshold you set, it asks. Under £100, the agent proceeds. Over it, you get asked. That boundary is yours to place, and it's the difference between delegation and abdication.
• Retries can't grind past a refusal. Identical requests replay the stored outcome — including stored denials. A retry loop cannot turn a no into a yes.
• Timeouts fail closed. An approval request that expires is a denial, not an unknown.
• Every decision writes an audit record. Allow, deny, escalate, error. There is no path that returns without one.

None of those invariants are novel individually. That's the point — I profiled existing standards rather than inventing a format, because a bespoke delegation scheme is a liability, not a moat.

What I did build that I haven't seen elsewhere is the conformance suite. It's the part I'd want to see from anyone making claims in this space, and it's how I find out when I'm wrong. It runs adversarial cases, not happy paths: an agent wrapping a mandate to buy beyond its cap, a prompt-injected request trying to widen its own scope, a spliced delegation chain, a confused-deputy attempt to make the agent the pass holder, replayed denials, escalation race conditions, and how fast a revoked mandate actually stops working under load.

Some of those cases fail in ways I'm still fixing. That's what a conformance suite is for.

What I actually believe

Loyalty isn't dying. Loyalty software is commoditising, which is a completely different thing — and the response to commoditisation is to go down a layer, not sideways into more features.

So the thesis I'm building on:

The wallet pass is the most under-exploited piece of infrastructure on the modern smartphone. It's preinstalled, permissioned, free to message, structured by design, and increasingly capable of carrying verifiable credentials. Most merchants use it as a nicer barcode. It's actually the customer relationship, in a form both humans and machines can read.

Four months in, walletKit is a working platform issuing passes for real venues, with a delegation layer and an open MCP server sitting on top of it. The next stretch is making the credential itself genuinely verifiable — so the proof travels with the pass rather than depending on a call back to my API.

I want to be precise about what I am and am not claiming. The ecosystem has not settled how agents present entitlements; there is no standard here yet, and mine is one implementation with a conformance suite attached, not a specification anyone has agreed to. What I'm confident about is narrower and, I think, more useful: the question "what is this customer entitled to, and who may act on it?" is going to need an authoritative answer, and merchants who already hold that answer in signed, structured, revocable form will be ready when everyone else is starting from an email list.

I'll be writing about that as I go, including the parts that don't work.

I'm building walletKit — turning Apple Wallet and Google Wallet into a retention and entitlement layer for modern brands. If you run a venue, a membership, or a merchant platform and any of this resonates, I'd like to hear from you.