Hackathon concept
Our Lori.
One AI concierge. Every subscriber. Customer in control.
Our Lori01 · The gap
The gap
Every subscriber's agent lives on an island.
A Lorikeet agent knows one subscriber's world. Customer problems don't stop at that edge. The agent that could help never meets the customer who needs it, and context that would resolve the ticket lives one tenant over.
Today
A customer with 6 subscriber accounts talks to 6 agents.
Each starts from scratch. Nothing carries. The customer explains their situation six times.
Today
A subscriber can only close a ticket if the answer is inside its walls.
If the real fix lives in a partner product, the ticket dead-ends. Best case: deflect. Worst case: escalate to a human who also can't help.
Today
Cross-subscriber context is dark.
A customer's day spans multiple subscribers. Each agent sees a keyhole. Nobody sees the room.
The shift
Treat the network of subscribers as one thing the customer can address.
The customer opts in. Subscribers opt in. Lori brokers what moves between them. Nothing new gets built by any subscriber to make this work.
Our Lori02 · Concept
Concept
Customer at the centre. Lori in the middle. Subscribers around.
Lori
consent · routing · context
Subscriber A
agent, tools,own data
Subscriber B
agent, tools,own data
Subscriber C
agent, tools,own data
Mode 1
MyLori
The customer-side surface. The customer's wallet of subscriber connections. One agent that can act across all of them.
Mode 2
Omni Lori
The subscriber-side surface, enriched. The subscriber's agent gets cross-subscriber context, with the customer's consent.
Mode 3
Connect, not deflect
The subscriber-to-subscriber surface. When one agent can't resolve, it warm-hands off to a partner agent that can.
Our Lori03 · The three-way test
Guiding principle
We only build it if all three parties win.
Every interaction Our Lori brokers touches three parties: the subscriber giving, the subscriber receiving, and the customer in the middle. If any one of them doesn't clearly benefit, the feature doesn't ship.
Party 1
Subscriber A · the one giving
Whether they're referring a customer out, sharing context, or letting MyLori suggest them, they gain something concrete.
- Resolution on tickets they couldn't close alone
- Distribution into MyLori's customer base
- Brand extension, not brand dilution
Party 2
Subscriber B · the one receiving
Whether they're accepting a handoff, ingesting context, or being suggested by MyLori, the trade is worth it.
- Warm, qualified, in-context inbound
- Higher first-contact resolution
- Clear control over what they accept
Party 3
The customer
The whole thing exists to make their day work. If any interaction is worse for them, the design is wrong.
- Faster resolution, less re-explaining
- Granular control of what's shared, with whom
- Discovery of solutions they'd otherwise miss
The disqualifier
If any party lands neutral or negative, it doesn't get built.
Not a hope, a filter. Every scenario on the following slides passes this test explicitly. When you see one that doesn't, hold us to it.
Our Lori04 · Evidence
Evidence
This isn't theoretical. It's happening in production, today.
30+ matched cross-subscriber conversation pairs, pulled from production on 15 Sep 2026, matched on the same customer across subscribers. The answer to the second conversation was already sitting in the first one.
33 min apart
Same day
Credit-builder card, then rent provider. Customer calls one about a card that won't pay rent. Correct diagnosis, offline handoff fails. 33 minutes later, chats to the rent provider — generic advice, ticket opened. Both failed. The rent provider's answer was already in the first conversation.
10 weeks
7 conversations
Car-finance lender and remittance app. One customer, family emergency overseas, £34,627 loan balance. The lender saw a pricing objection. The remittance app saw stuck transfers. Nobody saw the hardship draining both wallets.
3 days
Payout in transit
Payouts provider and rent provider. $3,400 payout in one subscriber's queue. Rent payment declined at another two days later. The money he needed was already in the building.
1 day
Pre-trip, in-trip
Telehealth and travel eSIM. 5 Jul: "pause my treatment, I'm going away." 6 Jul: 30 minutes troubleshooting an eSIM in a Vietnam airport. Same customer, one day apart. Neither concierge could see the trip.
The reveal
Every one of these is a production ticket. We can already point to the answer in the transcript.
Our Lori just puts the two conversations in the same room.
Our Lori05 · Omni Lori
Mode 1 · Omni Lori · The cleanest possible proof
Two halves of one problem, 33 minutes apart.
What's happening in production
- 04:11 · Credit-builder card provider. "I'm trying to make a payment and it won't go through." Lori diagnoses: it's a secured credit card, rent needs a debit card. Cannot fix. Team offline. Handoff fails.
- 04:44 · Rent-payment provider, same customer. "I'm trying to make payments with my card and it's not working." Generic card-type advice. "I used a different card, still not working." Ticket opened.
- Result today. Two subscribers, two tickets, zero resolutions, one problem. The answer to the second conversation was written in the first.
With Our Lori
The rent provider's concierge opens with the answer: "The card you're trying to use is a secured credit card, which rent payments can't accept. Here's what will work, and here's how to link your bank account instead." Resolved in one turn.
Three-way test
All three parties win.
Card provider: correct diagnosis lands instead of dying in an offline queue — prevents the customer concluding "this card doesn't work" and closing the account. Rent provider: hard-fail ticket becomes automated resolution — rent payment goes through, which is revenue, not a support metric. Customer: rent gets paid, in one conversation.
R
Rent-payment provider · Support
04:44 · Powered by Lorikeet
I'm trying to make payments with my card and it's not working.
Hi. Before we start — I can see you spoke to your card provider 33 minutes ago about this exact card. It's a secured credit card, which rent payments can't accept.
Here's what will work: link your bank account directly and we'll take the payment from there. Want me to set that up now?
Yes please.
Our Lori06 · Connect, not deflect
Mode 2 · Connect, not deflect · The first revenue-side use case
When the answer is no, hand off to a partner who can say yes.
What's happening in production
- Car-finance customer tells the lender. "I can't make this month's payment. I have to send emergency money to family overseas."
- Lender can't change the instalment. Today the conversation ends there — a "no", a callback, or a handoff to collections. Everyone loses.
- The other half of the problem is a Lorikeet subscriber too. The customer's actual need is a cheaper remittance corridor. The remittance app already sits in the network.
With Our Lori
The lender's concierge says: "I can't change your instalment date, but I can help with the other half of this. Would you like me to set you up with a partner to send that money at a lower fee? With your permission I can pass across what we've already discussed." One consent, one link, already logged in on the other side.
Three-way test
All three parties win — and one of them gets paid.
Lender: unresolvable ticket becomes resolved. Customer leaves better off even though the answer was no — CSAT on a "no" is the hardest number in support to move. Remittance app: a warm, intent-verified, pre-contexted customer. The highest-converting acquisition channel that exists. Customer: the problem behind the problem gets solved, in one conversation.
L
Car-finance lender · Support
Powered by Lorikeet
I can't make this month's payment. I have to send emergency money to family in India.
I hear you, and I'm sorry — I can't change your instalment date directly. But I can help with the other half of this.
Would you like me to set you up with a remittance partner who covers the UK–India corridor at a lower fee? With your permission I can pass across what we've discussed so you don't repeat it.
Yes, hand me over with the context.
Done. You're already logged in on the other side.
Our Lori07 · MyLori
Mode 3 · MyLori · The defensive moat
The customer's Lori. Acts across every subscriber they've linked.
The delivery rider on payday
Leases his e-bike from one subscriber. Draws a wage advance from a second. Sends money home to family through a third. All three are Lorikeet. All three concierges serve him well individually. None knows the other two exist. When the advance repayment and the bike payment land on the same empty day, three separate conversations happen and everyone loses.
With MyLori
One interface, one connection set that the customer owns. Lori executes across all three because the customer authorised the connection, not the subscriber.
Three-way test
Every subscriber wins on the same event.
All three subscribers: payments scheduled to succeed instead of scheduled to bounce. A failed direct debit is the most expensive routine event in all three of those businesses, and it's usually caused by a collision none of them could see. Customer: one place, one conversation, no juggling three apps on payday. Controls exactly who sees what.
Why we build MyLori even if we ship tier 1 first
Every one of these customers will have a consumer agent within two years. The only question is whose.
If it's a general-purpose assistant, it sits in front of every subscriber's concierge, commoditises them, and turns Lorikeet into the API it calls. If it's MyLori, our subscribers are the products inside it, and we own the interface.
L
MyLori
Wallet · 3 subscribers linked
I get paid Thursday. Move my bike repayment to Friday, send $200 home Friday morning, and don't let the advance repayment land the same day as rent.
On it. Coordinating across your three linked subscribers.
E-bike leaseWage advanceRemittance
Here's what I'd action, with your OK:
· Bike lease — move Thu repayment to Fri 08:00
· Remittance — send $200 home Fri 09:00
· Wage advance — reschedule collection to avoid rent day
· Bike lease — move Thu repayment to Fri 08:00
· Remittance — send $200 home Fri 09:00
· Wage advance — reschedule collection to avoid rent day
Our Lori08 · Flywheel
The flywheel
Why a subscriber opts in.
Every subscriber that joins the network makes the network more valuable to every other subscriber, and to the customer. Three payoffs, one loop.
01
Better own-ticket resolution
Omni Lori enriches every ticket with customer context that lives outside your walls. Higher first-contact resolution, less repeat-info friction, hardship spotted earlier.
02
Warm inbound from partners
Every time a partner subscriber's agent can't resolve and yours can, the ticket lands with you already qualified and half-briefed. The first time Lorikeet appears on the revenue side of your P&L, not the cost side.
03
Discovery via MyLori
When a MyLori customer asks a question your product can answer, you get suggested. A new acquisition channel that only opens to opted-in subscribers.
Network effect
Every subscriber that joins makes the network more valuable to the next one, and makes leaving more expensive.
That's the Afterpay shape. We'd be the only support platform with it.
Our Lori09 · Objections
The pushback we'll get
The four objections, and the answers.
Objection 1
"Subscribers won't share with competitors."
They won't, and they've told us so directly. Matching is complementary-only and never within category. Each subscriber holds their own allow and deny list. Category exclusivity becomes something we can sell.
Objection 2
"This feels icky."
Consent is per-conversation and explicit, in the customer's own words. What crosses the boundary is a category signal, not transaction history. The customer can revoke any connection. That control is the product, not the fine print.
Objection 3
"How do we bill it?"
Not per-ticket. Tier 1 is a referral fee or marketplace take rate paid by the receiving subscriber, out of their acquisition budget. That's a new budget line for Lorikeet — and it scales with the network, not with headcount.
Objection 4
"Why now?"
Because every consumer will have an AI agent within two years. If we don't own the customer surface, someone else does — and Lorikeet becomes the commoditised API they call. Start with tier 1 revenue this quarter, protect the surface for later.
Our Lori10 · The ask
To ship for real
Four primitives, one question for the room.
Primitive 1
Consent
A first-class Lorikeet object. Records what the customer has agreed to share, with which subscriber, at what granularity, for how long. Rendered as the consent chip everywhere it fires.
Primitive 2
Subscriber opt-in config
A subscriber-facing surface: allow list, deny list, categories they'll accept referrals in, categories they want to be suggested for. Curated by the subscriber, not a black box.
Primitive 3
Cross-tenant identity resolver
The customer is one person across subscribers. Lori needs to know that securely — federated identity, not a shared database. Never a Lorikeet-owned customer graph.
Primitive 4
Referral logging and rev share
Log every handoff, its outcome, and its economic value. Rev-share on landed referrals is the strong default. Everything else is negotiable per pair.
The ask
Start with tier 1 this quarter. Prove revenue on the network before we build the customer surface.
One referral flow, two opted-in subscribers, one paid handoff. If it lands, the primitives above are the next four steps. If it doesn't, we've spent the quarter finding out cheaply.