SquadTab

The friend who knows everyone's budget and tells no one. Text it privately, it finds a night out you can all afford, and nobody pays until everyone's in.

Comment

Track: Applied Intelligence (plus Overall). Company challenges: Photon iMessage · CREAO AI-First Disruptor · Visa "The Future of Shopping" · Paper Best Designed Hack · MLH Commit Fellowship.

SquadTab is the friend who knows everyone's budget and tells no one. Say no without saying why. Nobody pays until everyone's in.

💡 Inspiration

Every friend group has a dead plan sitting in its chat. It usually dies at one of two moments:

  1. Someone has to say "I can't afford that", in front of everyone. So nobody does, and the quiet friend silently drops out.
  2. Someone fronts the money, then spends two weeks chasing payment requests. According to Zelle research (June 2026), 76% of Gen Z consumers who fronted money for a group expense say they were not fully repaid.

Both are the same problem: money talk only works in private. So we built a planner that never joins your group chat, on purpose.

🧭 What it does

  1. Everyone DMs SquadTab privately in iMessage: "I can do thirty, and I'm vegetarian." Only that person's private delegate ever hears it.
  2. SquadTab Scout, a CREAO agent, researches real dinners and shows that fit the area, time and diet.
  3. Plain code keeps only the bundles everyone can afford and picks three fair options, without revealing whose budget ruled anything out.
  4. Friends vote from their own DMs. There's one price, the same for everyone.
  5. Each friend holds only their own share on the merchant's Cybersource card page. It's a hold, not a charge.
  6. When every share is held, SquadTab's agent signs the exact deal with the Visa Trusted Agent Protocol. The merchant checks it against its own records and captures every share at once.
  7. One "I'm out" releases everyone: "Nobody was charged; your pending authorization was released."
  8. SquadTab Concierge, our second CREAO agent, writes the itinerary and a calendar file.

The only privacy claim we make: only your own agent hears your budget. CREAO, the group messages and everyone else's agent never get it, and every money decision is plain code.

🏗️ How we built it

iMessage DMs ──Photon 2.0──▶ Agent (TypeScript · Hono · Fly.io)
                              ├─ one private delegate per friend (Claude, no tools, sees one person only)
                              ├─ plan state machine + fixed money/privacy message templates
                              ├─ compose → filter → score → pick   (pure code, not callable by any model)
                              ├─ CREAO Scout + Concierge  (API runs, webhook re-fetch, 15 s polling)
                              └─ TAP signer (Ed25519) ──signed request──▶ Partner Venue (Next.js · Vercel)
                                                                           ├─ prices every order itself
                                                                           ├─ Cybersource Microform pay page
                                                                           ├─ 6-step TAP verifier + nonce store
                                                                           └─ all-or-nothing capture / release

Trust Console (Next.js): lanes · context X-ray (budgets always 🔒) · CREAO lane · TAP panel · ledger
Supabase Postgres: separate schemas and roles for the agent and the venue

1. One price, computed by the merchant

Every friend pays the same all-in price per person, rounded up to a whole dollar. With dinner estimate d, show estimate s, tax τ = 0.1025 and tip θ = 0.18:

$$P = \left\lceil\, d\,(1+\tau+\theta) + s\,(1+\tau) \,\right\rceil \qquad T = n \cdot P$$

The venue computes P and the total T itself. No amount is ever accepted from a model or from a request body.

2. A private filter no model can call

Each friend i has a private target tᵢ and an optional hard max hᵢ. Their effective cap is cᵢ = hᵢ if they gave one, otherwise round(1.1 · tᵢ). A bundle b survives only if

$$P_b \le \min_i c_i$$

It's a single comparison inside a pipeline step, not a tool. That blocks the attack where someone keeps asking an AI "would 41 work? 39?" to binary-search a friend's budget.

3. Fair, not loudest-wins

Each friend's delegate rates each bundle, rᵢ,b between 0.05 and 1. Price comfort drops gently once a bundle passes someone's target:

$$\kappa_i(P) = \begin{cases} 1 & P \le t_i \ \max!\left(0.6,\; 1 - 0.4\,\dfrac{P - t_i}{\max(1,\; c_i - t_i)}\right) & P > t_i \end{cases}$$

A bundle's group score is

$$W(b) = \sum_{i=1}^{n} \ln!\big(r_{i,b}\cdot \kappa_i(P_b)\big)$$

Summing logs is the same as multiplying everyone's satisfaction, so no single person can be sacrificed to make the rest happier. We shortlist the top three bundles by W, with no two sharing a dinner or a show, so the group gets three real choices. The winner is the most-approved bundle in the private vote, with ties broken by W, then by price.

4. All or nothing, provably

Each friend i places their own authorization aᵢ with capture turned off. The merchant captures only when all of this holds:

$$\text{TAP}_{\text{valid}} \;\wedge\; \forall i:\ \text{status}_i = \text{AUTHORIZED} \;\wedge\; \sum_i a_i = T \;\wedge\; \text{body} = \text{canon}(\text{DB})$$

Otherwise nothing is captured. On "I'm out" or at the deadline, every aᵢ is reversed.

5. The Visa Trusted Agent Protocol commit

The agent signs an RFC 9421 signature base covering the method, host, path and a digest of the deal. The merchant checks six steps in order: tag, fields, time window, nonce, key, signature. The time window is

$$\text{created} \le \text{now} + 5\,\text{s} \qquad \text{expires} > \text{now} \qquad \text{expires} - \text{created} \le 480\,\text{s}$$

The body digest is

$$D = \text{SHA-256}\big(\text{canon}(\text{order},\; T,\; {(\text{share}_i,\ \text{authId}_i,\ a_i)})\big)$$

and the merchant recomputes it from its own database. Change one share by a single dollar after signing and D no longer matches, so step 6 fails and nothing is captured. Every nonce works once, and pay links are 128-bit single-use tokens, so a random guess succeeds with probability

$$2^{-128}$$

Stack

  • Agent: TypeScript and Hono on Fly.io.
    • Claude Haiku 5.5 parses budgets, preferences and ballots. Claude Sonnet 5.5 rates bundles for one person at a time.
    • No model has tools. There is no group-coordinator LLM, and every money and privacy message is a fixed template.
  • Messaging: Photon 2.0 Beta (@photon-ai/api), live on iMessage shared lines, with the Socket.IO event stream and a persisted replay cursor.
  • Research: two CREAO agents built on agent.creao.ai. Our own tab skill and CLI are saved into their environment, so they can stream progress, validate their output against our schema, fix errors (up to 5 rounds) and submit.
  • Payments: a Next.js partner venue holds all Cybersource code: Microform v2 card fields, authorization (capture:false), capture, reversal, timeout reversal and one-tap saved cards (TMS). Its pay page uses the same design system as the rest of SquadTab.
  • Data: Supabase Postgres, with separate schemas and roles for the agent and the venue.
  • Tests: 1,500+ automated tests (Vitest). They include:
    • a privacy test that seeds odd budgets (\$31.17, \$47.29, …) and fails the build if any appears outside its owner's delegate and DM
    • a race test for the exactly-once commit
    • every TAP rejection mode
    • the full money flow on a real Postgres

🏆 How SquadTab meets each challenge

Applied Intelligence

AI does what it's good at: understanding a person's natural-language budget and taste, and researching the open world. It stays out of everything it must not be trusted with. No LLM has tools, there is no group-coordinator LLM, the fair filter is a pipeline step no model can call, and every number that moves money comes from code and the venue's database. Privacy is enforced by context isolation and a build-failing test, not by a prompt.

Photon: build a messaging agent on Photon 2.0

Built on Photon 2.0 Beta (@photon-ai/api 0.5.0) and live on iMessage through shared lines. Judges can text it from their own phones today.

  • Vision: a private delegate per friend, a code mechanism between them, and humans keep the final yes. The DM is the product: no app, nothing to install.
  • Craft: typing indicator during long research runs, mark-as-read, an idempotency key on every send, and a persisted Socket.IO replay cursor so no message is lost across restarts. On production, a message reached a team phone in 2.2 s; replies take about 1–4 s.
  • Depth: the shared-line rules (user texts first, DM-only, no threaded replies) shaped the whole design. Replies stay truthful at the edges: "I'm out" after booking gets an honest too-late reply, and a budget-blocked plan asks for a recovery instead of failing silently.
  • Traction: it runs end to end on real phones over plain iMessage, including a real card hold and capture in the payment sandbox.

CREAO: Best AI-First Disruptor

Remove the agent and SquadTab has nothing to vote on. Scout produces every option the group votes on, and Concierge produces the itinerary and calendar file after checkout.

  • SquadTab Scout: agent ID 1b834601-b727-40aa-b80d-7e7d1c0cabe0, run: https://agent.creao.ai/share/12ea3fa0f9699dabe5175e2cb6eadc28
  • SquadTab Concierge: agent ID 465a1d2e-a46f-496c-adea-fc471a396a6c, run: https://agent.creao.ai/share/6d95ca9660e15924b0f91c5e19e19894
  • API Trigger + webhooks: runs start through the API with an idempotency key. Webhooks are unsigned, so each one only triggers a re-fetch of the run, backed by a 15 s poll.
  • Our own tools: the tab skill and python3 CLI (https://github.com/L00SIRE/SquadTab/tree/main/skills/tab) stream progress into our console and validate output against our schema before submitting.
  • Real output: live Scout runs returned 12 real dinners and 12 real shows with dated showtimes; Concierge returned an itinerary and a correct calendar file.
  • Honest fallback: on a timeout we fall back to a real earlier Scout snapshot, and the console labels every run live or cached.
  • Keys stay on the server: CREAO only ever sees a research brief (enums, area, date, times, party size), never names, phones or budgets.

Visa: The Future of Shopping

Agent shopping today is one person, one card. Groups are the unsolved case: private budgets, and a purchase that only goes through if all N agree. SquadTab covers discovery (CREAO), decision-making (private ballot, fair shortlist), personalization (private caps), checkout (split holds plus a signed commit) and post-purchase (itinerary, calendar).

  • Innovation: a group purchase becomes an assurance contract at the merchant of record: N cardholder-initiated authorizations plus one identified agent that can commit only the exact consent set.
  • User experience: each friend pays only their own share, in a DM, as a hold rather than a charge. Amber means held, green means captured, and there is no red: a drop-out is the promise working, not an error.
  • Technical execution: real Cybersource sandbox authorization, capture, reversal and timeout reversal. Cybersource has no idempotency header, so exactly-once is designed: unique (share, op, attempt) records, deterministic reference codes, persisted transaction IDs and no blind authorization retries. Plus our own Ed25519 RFC 9421 signer and six-step verifier.
  • Trust: card data lives only inside Microform iframes; credentials live only in the venue app. The console's Tamper, Replay, Expired and Wrong-tag buttons are each rejected by the merchant, and nothing is captured.
  • Verified on the sandbox: real holds and captures (a team phone test captured \$137), all six TAP steps passing on a real commit, tamper and replay rejections, and releases.

Paper: Best Designed Hack

Paper file "SquadTab": https://app.paper.design/file/01M57RY01PHZA13NV3SS3NQN5N

Our design system is called Signal: SquadTab works like a traffic signal for a group plan, and the plan is a ticket.

  • Hierarchy: the ticket is the hero, and its price, "\$42 each", is the largest thing on every screen.
  • Legibility: three typefaces with fixed jobs: Funnel Display, Funnel Sans and Martian Mono (for amounts and codes). The Trust Console is built to be read from five meters on a projector.
  • Consistency: 30 tokens in Paper; all 17 colors and the radii are identical to our production globals.css, shared by the web app and the venue's pay page.
  • Contrast: 38 state color pairs measured, 0 failing WCAG; ink on sodium amber #FFB224 is 10.69:1. States also differ by shape (solid, outline, dashed), never by color alone.
  • Ease of use: nothing to install. The interface is an iMessage DM, so we designed the words as carefully as the screens.
  • Character: the "42" is digit-art made of tiny re-rolling private numbers that never resolve into anyone's budget. Each friend's hold freezes their quarter, and capture lights the mark. The 42 on the Paper cover is the real engine render, not a mockup, and the real production loop plays inside the Paper file. Sodium-vapor amber is the color of going out at 1 a.m., and in signaling it already means hold.
  • Written anti-AI rules: no gradients, glows, pills, bento grids, emoji or stock icon sets. Our icons are 7×7 dot glyphs.
  • Process: we critiqued our own designs (14 findings, each with what changed and where it's verified), then ran a second review and fixed every P0. The Paper file walks through Foundations, Components, Web, The conversation, Pay page, Trust console, Process and Shipped (live production captures beside the designs).

MLH Commit Fellowship

SquadTab is live on iMessage today, end to end, with 1,500+ automated tests. Our next 30 days: run it with 10 real friend groups and measure plans started vs booked, fix the top drop-off step, get one real venue to accept SquadTab checkout, and apply for Visa agent registration.

🐛 Side quest: we found a bug in our payment sandbox, and Cybersource acted on it

Around midnight, every card authorization on our provisioned Cybersource sandbox merchant started failing with a vague "502 General system failure". Our signing worked, the card form loaded, and validation errors came back normally. So we treated it like an incident:

  1. Reproduced it: the same failure for every amount and every request shape.
  2. Pulled the merchant's transaction records and found the real cause: reason code 150 on the fdiglobal processor, with the merchant's USD outlet ID and terminal ID missing. That's a processor setting merchants can't edit themselves.
  3. Reported it to Cybersource with a request ID, the exact missing fields, and a suggested fix.
  4. Kept shipping. Our venue switches merchants with environment variables only, so we moved to Cybersource's public test merchant (testrest) with no code change.

Sunday morning, a Cybersource Level II engineer replied that they had updated the outlet and terminal IDs. On our retest the error narrowed to a single field, usd_outlet_id, so the fix is partial and we're finishing it with their team. The demo runs on the public test merchant, where holds, captures, TAP commits and releases all work.

🧗 Challenges we ran into

  • The sandbox outage above. Detective work plus an overnight support case. The env-only merchant switch meant it never blocked the product.
  • No idempotency header, real money semantics. A timeout mid-authorization might or might not leave a hold behind. We never retry blindly: every call is recorded before it's sent, and an unknown outcome gets a timeout reversal.
  • Privacy you can test, not promise. One model call per person, one locked table, one module allowed to read it, and a test that fails the build if a budget leaks.
  • iMessage shared lines are DM-only, reject threaded replies and need the user to text first. That forced the private-DM design, which turned out to be the product.
  • CREAO webhooks are unsigned, so every webhook only triggers a re-fetch of the run.

🥇 Accomplishments that we're proud of

  • A group checkout where nobody fronts money, ever.
  • Our own Visa Trusted Agent Protocol signer and six-step verifier, with live tamper, replay, expiry and wrong-tag rejections.
  • An exactly-once, all-or-nothing commit that survives concurrent requests.
  • Privacy enforced by architecture and a test, not by prompts.
  • A CREAO agent that checks and fixes its own work before handing it to us.
  • A root-caused sandbox bug report that Cybersource's engineers acted on during the hackathon.

📚 What we learned

  • Money talk is a privacy problem first and a payments problem second.
  • Agentic commerce needs proof, not trust. The real question isn't "can an agent pay?" but "can a merchant verify exactly what the humans agreed to?"
  • A vague error is a starting point, not a dead end. Reading the processor's own records turned "system failure" into a two-field bug report.

🔮 What's next for SquadTab

  • Trips and gifts: the same all-or-nothing hold for group trips and group gifts.
  • Quiet cover: a friend can anonymously ask the group to cover them this time.
  • The venue side: partner merchants integrating SquadTab checkout directly.
  • Visa: agent registration in place of our mock key directory, and Visa Intelligent Commerce agentic tokens.
  • Business model: a fee per committed group booking. That's a hypothesis we still need to validate.

🔍 Honest notes

  • Payments run on Cybersource's sandbox, on its public test merchant: test cards only, no real money.
  • "SquadTab Partner Venue" is our own demo merchant, selling a prepaid dinner + show bundle.
  • The TAP key directory is a labelled mock.

🔗 Links

username for fetch.ai

Christian (user handle): user-0e73be43 Suman (user handle): user-88d6e8bd

Built With

Share this project:

Updates

Submission history