DEV Community: Papa

Ardum: An Agent-Guided Yoga Retreat Matcher That Reasons Out Loud, Remembers You, and Never Shows You a Loading Spinner

Papa — Mon, 06 Jul 2026 07:55:50 +0000

Ardum is an agentic yoga retreat matching platform. The name is mudra reversed — a mudra is a seal that directs energy and intention; Ardum opens the seal and begins the search.

The premise: most "AI matching" products are a form with a spinner and a recommendation at the end. We wanted something closer to what a good teacher actually does — listens, reasons visibly, remembers you, and never makes the moment feel transactional. The whole experience is anchored by Mira, a persistent agent persona (a breathing orb, a warm second-person voice) who is present at every step: intake, matching, the match letter, booking, and post-booking prep.

A full run through the app looks like this:

Calibrate — three honest questions (energy, budget, social comfort) plus an optional five-second pose sample processed entirely in-browser via MediaPipe. Raw video never leaves the tab.
Match — Mira reasons over a pool of retreat attestations and streams her logic live, structured as Gherkin steps (Given/When/Then), so every signal she weighs is visible and disagreeable. While she reasons, you're not staring at a spinner — more on that below.
Book — one click, no MetaMask, no seed phrase, no gas.

The interesting engineering is mostly in how steps 2 and 3 avoid feeling like a form and a checkout.

The matching phase is not a loading screen

This is the part of Ardum I'd point other builders to first. Matching takes a few seconds of real reasoning time, and instead of hiding that behind a spinner, Ardum turns it into an interactive aesthetic experience:

A 12-image curated pool, each image scored on 15 aesthetic dimensions
An ambient drone synthesized live via the Web Audio API — no audio files, fully deterministic
The user's reactions (resonate / skip, weighted by how long they linger) build a live preference vector
That vector drives which images get shown next (bandit-style selection), shifts the drone in real time, and later gets woven directly into Mira's match letter: "While I was thinking, you were drawn to ocean and warm tones. That tells me something about where you'd thrive."

It's tiered for cost: the curated-image tier is free and instant, and only one paid image-generation call (via fal.ai, ~$0.003) happens per match — for a generated "retreat vision" image personalized to what the user resonated with. If no image API key is configured, it falls back to curated stock photography automatically. Total marginal cost per match: about $0.018.

Reasoning you can see, question, and re-run

Mira's reasoning isn't a black box you either accept or reject. Two things make it inspectable:

Two lenses on every match. Every match result runs the same scoring registry through two different weightings — a "Restorative" lens and a "Movement" lens — and shows both side by side. When they agree, the recommendation is robust. When they disagree, the user sees exactly where the two perspectives diverge, computed deterministically from the same rule set (no extra LLM calls).

Counterfactual re-scoring. After a match, the user can ask "what if I'd weighted this differently?" and Mira re-scores the same attestation pool under a different composite weight balance — energy-heavy, social-heavy, or budget-heavy presets — and shows the alternate top match with the same step-by-step reasoning underneath. Changing your mind doesn't mean starting over.

Both features come from one design decision: matching logic lives in a single AXES registry that both the deterministic scorer and the LLM prompt read from. Change a rule once, and the local scorer, the LLM's reasoning, and the "why" behind every match all update together — nothing to keep in sync by hand.

Booking without touching a wallet

Ardum has three distinct people interacting with money, and each gets a different abstraction because their needs don't overlap:

Practitioners booking a retreat get a Magic social login (Google) that creates an embedded wallet, upgraded via Particle's Universal Account SDK (EIP-7702) so a deposit in any token on any chain settles automatically on Arbitrum against a deployed escrow contract. No chain selection, no gas.
Operators attesting a retreat listing get Particle Auth plus a ZeroDev ERC-4337 smart account, with gas sponsored by a paymaster and session keys so batch attestation writes don't require re-signing each one.
Drop-in class payments run through Openfort with the x402 HTTP payment protocol — a GET returns a 402 with payment requirements, a signed authorization gets posted back, and it settles on Base Sepolia with sponsored gas.

Particle's EIP-7702 accounts and ZeroDev's ERC-4337 accounts can't coexist on the same address, which is exactly why practitioners and operators need separate rails rather than one universal wallet abstraction trying to do both jobs.

All of it — retreat listings, bookings, class access — gets written as attestations to 0G Storage, which stays the single source of truth regardless of which wallet flow touched it.

Giving Mira actual memory

The one piece missing from all of the above: Mira forgot everyone the moment they closed the tab. The original stopgap was a localStorage fingerprint — three fields, a 1–30 day window, no real recall, nothing that survived a new device.

We replaced that with Cognee, a hybrid graph-vector memory store, wired in behind four verbs:

typescriptawait cognee.remember(userId, "energy=low, budget=1k-2k, matched to Restorative Yin in Ubud, score 0.87");
const memory = await cognee.recall(userId, "What do I know about this practitioner?");
await cognee.improve(); // enrich the graph in the background
await cognee.forget(userId); // right-to-be-forgotten, one tap

remember() fires after intake, after each match, and after each booking. recall() runs before the match stream starts and before Mira writes her letter, returning a structured MemoryContext (energy trajectory, past matches, past bookings, notes) that feeds both Mira's opening line — "You've been to Restorative Yin in Ubud before — this builds on that" — and the matching prompt itself, so the agent reasons about trajectory, not just a single snapshot.

A /memory page shows practitioners exactly what Mira knows, including the actual knowledge graph rendered as a force-directed visualization — nodes are entities, edges are relationships like matched_with or booked_at. There's a one-tap "forget me" button. We were nervous this would feel invasive; in testing it was one of the most-visited pages in the app. People want to see what an AI remembers about them, not just be told to trust it.

Every Cognee call degrades silently — missing API key, exhausted credits, network failure — the app just runs without cross-session recall rather than breaking the match flow. That's a hard requirement for anything sitting on the critical path of a real product, not just a nice-to-have.

What we learned

The "loading state" is real estate. Matching takes a few seconds no matter what. Spending that time on an aesthetic journey instead of a spinner turned dead time into a second, genuinely useful signal about the user's preferences — for free, before any LLM call happens.
Visible reasoning builds trust faster than accurate reasoning. Users didn't just want a good match; they wanted to see why, disagree with a step, and re-run it under different assumptions. The counterfactual feature came directly out of watching people ask "but what if—" out loud during testing.
Don't force one wallet abstraction to serve two different users. Practitioners and operators have genuinely different needs (cross-chain deposits vs. gasless batch writes), and trying to unify them under one account model would have made both worse.
Memory changes the product category, not just the tech. Before real cross-session memory, Ardum was a matching engine you'd use once. The moment Mira recognizes a returning practitioner with specific, accurate detail, it stops being a tool and starts being something closer to a relationship.
Transparency de-risks the creepy parts. Both the reasoning stream and the memory graph expose things that could easily feel invasive. Both became trust-builders instead, because the user could see and control them rather than just being told to trust a black box.

The stack

LayerTechnologyFrameworkNext.js 16 (App Router, React 19, Turbopack)Agent personaMira (custom voice + orb component)Attestations0G Storage SDKAgent reasoning0G Compute Router (OpenAI-compatible, streaming), deterministic local fallbackMemoryCognee (hybrid graph-vector)Pose calibrationMediaPipe Tasks Vision (in-browser)Aesthetic journeyCurated image pool + Web Audio API drone + fal.ai (Tier 2 generative imagery)Session persistenceSupabase (with in-memory fallback)Practitioner bookingMagic + Particle Universal Account (EIP-7702) + Arbitrum escrowOperator attestationsParticle Auth + ZeroDev (ERC-4337, gas sponsorship, session keys)Drop-in paymentsOpenfort + x402 (Base Sepolia)Real-time reasoningServer-Sent EventsDeploymentVercel

Try it

Live app: ardum.vercel.app
Source code: github.com/udirobert/ardum
Memory page: ardum.vercel.app/memory — the Cognee graph in action

Ardum runs fully in demo mode with no environment variables set — a deterministic local matcher, in-memory session store, and ten seeded retreats — so you can try the whole flow without spinning up any of the above.

Sportwarren - Rec Football Gets Its Intelligence Layer

Papa — Mon, 08 Jun 2026 06:59:20 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

SportWarren is a tactical command center for recreational football — the 5-a-side, 6-a-side, Sunday league kind that hundreds of millions of people play every week and that has, until now, left absolutely no trace.

You play every week. You score goals. You build chemistry with the same five people over years. And then the final whistle goes and none of it happened. No stats, no record, no reputation. Rec players are invisible.

SportWarren fixes that. Set your formation, put your squad on the pitch, share a challenge link to the group chat — and every matchday becomes verified stats, XP, and permanent squad history. Six attributes per player (pace, shooting, passing, dribbling, defending, physical) that actually evolve with every game. AI coaches that give you tactical banter and real analysis. Group verification via Telegram or WhatsApp so results are confirmed by the people who were there.

But the piece that makes this more than a stats tracker — and the piece that was entirely missing from the hackathon prototype — is the agentic commerce layer. There are two payable units baked into SportWarren now, both settled via x402 and USDC on GOAT Network's Bitcoin-secured infrastructure:

AI scouting reports (0.005 USDC) — an agent analyses your squad's attributes, form, and tactical tendencies and returns a structured breakdown
Match verification attestations (0.10 USDC) — once a result clears group confirmation via Telegram or WhatsApp, an agent produces a signed on-chain attestation of the verified outcome

The social layer is the integrity layer in SportWarren — group verification is what separates real stats from self-reported ones — and turning that verification into a purchasable on-chain attestation makes the commerce primitive inseparable from the core product mechanic. You're not paying for a feature. You're paying to make your match permanently true.

That's the Kite AI Agentic Commerce track in a sentence: rec football as an entry point into agent-native payments. Unglamorous use case, real economic primitives.

Built in collaboration with @udirobert · Find me on Farcaster · Lens

Demo

🔗 Live app: sportwarren.com
📦 Repo: github.com/udirobert/sportwarren
📱 Telegram bot: t.me/sportwarrenbot

The Comeback Story

The honest state of SportWarren before the Kite AI hackathon: everything was scattered. The tactics board existed but the challenge flow was broken. The player cards rendered but XP didn't update correctly after matches. The group verification system — the mechanic that makes stats trustworthy, not self-reported — was stubbed out. And the AI layer was a collection of disconnected pieces that didn't form a coherent loop.

Most critically: there was no agentic commerce layer at all. The verification system existed in fragments but wasn't connected to any on-chain settlement. The AI analysis ran and returned results into a void — no identity, no payment, no record.

The Kite AI Global Hackathon — and the support from GOAT Network's builder grants program — gave this a forcing function. Kite's agentic commerce track is specifically designed for agents that discover, pay, and manage via x402 and programmable constraints settled on-chain. The natural fit turned out to be verification: a squad logs a result, the group confirms it, and an agent produces a signed attestation someone pays for. That loop didn't exist before. Here's what actually got built and fixed:

The core loop stabilised. Formation setup → challenge link → opponent counter-pick → simulation → result logging → group verification. All five steps now work end-to-end without broken states or dead ends.

XP and player progression wired up correctly. Six attributes now actually update after every logged match. The progression curve — slower at higher levels, volatile early — is tuned to feel like a real career arc rather than a grind.

Group verification shipped. Squadmates can now confirm or dispute a logged result via Telegram or WhatsApp, with a 6-hour TTL, configurable confirmation thresholds, and silence-as-consent handling. This is what separates SportWarren from self-reported stat apps: the social layer is the integrity layer.

The simulation engine built out. The tactical AI runs opponent formations against each other using Monte Carlo probabilities, and delivers a readable breakdown — not just a scoreline but an explanation of why a 4-1 lost to a 1-2-1.

x402 payment integration on GOAT Network. Two payable endpoints now live: AI scouting reports at 0.005 USDC and match verification attestations at 0.10 USDC, both settled via x402 protocol through GOAT Network's facilitator. The economics are deliberately micro — this is about proving the primitive works at the right layer of the product, not extracting revenue.

Kite AI agent passport + ERC-8004 identity registered. The agent has its own verifiable on-chain identity, making it a first-class participant in the agentic economy rather than a backend function with a webhook.

The project went from a scattered prototype with broken flows to a working app with a genuine on-chain commerce layer. Rec football as a trojan horse for agent-native payments.

My Experience with GitHub Copilot

I used Copilot heavily on SportWarren — both inline autocomplete and Copilot Chat, often switching between them mid-session depending on what the problem needed. Alongside other AI tools in the repo (the codebase reflects a multi-tool workflow), Copilot was the constant thread.

Inline autocomplete earned its keep most on the repetitive but precision-sensitive work: building out the player attribute system, writing the XP calculation logic for different match outcomes, scaffolding the Telegram bot handlers. These are tasks where the pattern is clear but the details matter — getting the attribute deltas wrong would make the progression feel fake — and Copilot's suggestions were consistently close enough that reviewing them was faster than writing from scratch.

Copilot Chat was where the more interesting collaboration happened. The x402 integration on GOAT Network was genuinely new territory — x402 is a young protocol and there's limited prior art to draw from. Walking through the payment flow architecture in Chat, getting hypotheses about where the 402-challenge/response cycle should sit relative to the verification workflow, and debugging EIP-3009 permit handling were all places where Chat provided real signal rather than just plausible-sounding boilerplate.

The other place it proved its worth was verification system design. Group verification sounds simple but has real edge cases: what happens when one player disputes a result the other four confirmed? What's the timeout window? How do you handle silence? Copilot Chat was useful for thinking through the state machine before writing it — catching the cases I'd glossed over before they became bugs.

Between both modes, Copilot was present across most of the meaningful decisions in this build — not leading them, but keeping pace.

Supported by GOAT Network builder grants — Bitcoin-secured infrastructure for the agentic economy.

Find me on Farcaster and Lens — always building at the intersection of AI, emerging markets, and on-chain infrastructure.

OnPoint - curator first AI fashion studio

Papa — Mon, 08 Jun 2026 06:58:35 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

OnPoint is a curator-first AI fashion studio — a multiplatform ecosystem for personalized styling, fashion discovery, and digital ownership.

The pitch in one line: stylists hand customers a branded try-on → polaroid → share → buy loop, and every session generates live retail intelligence on the back end.

The problem OnPoint solves exists at the intersection of two broken experiences. For shoppers, fashion discovery is noisy and impersonal — you scroll endlessly, get generic recommendations, and can't tell if something will work on you before you buy. For retailers and stylists, the data they need (what's missing from the catalog, what competitors are pricing, what customers are actually reaching for) is either locked behind expensive tools or never collected at all.

OnPoint closes both gaps at once. Shoppers get a real-time AI styling session — point a camera at an outfit, get instant coaching overlays, discover matched products, and buy. Stylists and curators get the same flow turned into live GTM intelligence: when a shopper tries on a jersey and the catalog has no match, the agent fires an external_search action. The Python FastAPI bridge (via Browser Use Cloud and Bright Data) searches the open web, extracts competitor pricing, and returns a structured product list — name, price, source URL, image — surfaced as an "Agent Discovery" card. That's the GTM intelligence: not a dashboard, but a structured signal a curator can act on immediately.

The platform also has a meaningful on-chain layer. Each agent has an ERC-8004 identity (Agent ID 9177), an agent wallet on Celo, and session data is stored verifiably via IPFS/Filecoin through Lighthouse.

The stack: Next.js frontend on Netlify, Express API and Python FastAPI agent bridge on Hetzner, multi-chain support across Celo, Base, Ethereum, and Polygon, with AI routing across Venice AI, Google Gemini Live, OpenAI, and AI/ML API.

Demo

🔗 Live app: beonpoint.netlify.app

🔗 Source: github.com/thisyearnofear/onpoint

🔗 Agent identity: 8004scan.io/agents/celo/9177

Key flows to try:

Upload a photo or use your camera for live AR styling feedback
Watch the agent search the open web when the catalog doesn't have a match
Check the retail intelligence panel for product gap and competitor pricing signals
Connect a wallet (RainbowKit) and explore the on-chain agent identity layer

The Comeback Story

OnPoint started as several hackathon projects running in parallel. The core try-on and styling loop worked, but each vertical — Bright Data web intelligence, Auth0 Token Vault, the Celo agent wallet, IPFS storage — had been built and deployed independently. The real finish-up work wasn't adding features; it was making the pieces coherent enough to trust in production.

Here's the specific problem that forced the biggest change: the agent heartbeat was running on Vercel serverless functions with a 60-second execution cap. The platform promised "agent works while you sleep," but the infrastructure couldn't sustain it. Cold starts (~8s) made the heartbeat unreliable, and the stateful loops needed for the Dead Man's Switch simply couldn't run on serverless. The fix — documented in ADR 0001 — was moving stateful agent execution to Hetzner. That required extracting agent-core into a shared package both runtimes could import, which touched every agent endpoint. After the migration, heartbeat latency dropped from cold-start territory to under 100ms on the persistent worker. The autonomous executor now handles nonce management via Redis atomic INCR — no more nonce-dance crashes on retry.

The fraud detection layer is what makes the "agent spends your money" pitch credible. The Dead Man's Switch monitors heartbeat health — miss 3 consecutive check-ins and the agent freezes autonomously. Transactions above $500 require multi-signature approval. Every suspicious pattern (velocity spikes, unusual amounts, rapid large transfers) increments a 0–100 anomaly score that triggers an automatic freeze at 75. Velocity checks cap at 20 transactions per hour. This isn't safety theater — it's the trust infrastructure that lets a shopper hand the agent real spending authority.

The curator primitive came from field feedback. A stylist selling football jerseys needed a toolkit for her customers, not a crypto wallet. ADR 0002 formalized the decision: what a Curator is, what data lives where, what stays out of scope. Writing the ADR clarified that the agent layer should be infrastructure (behind /lab) rather than the hero feature — the curator's brand and storefront stay front and center.

Auth0 Token Vault brought external API credentials (Calendar, Slack, and others) under proper management via RFC 8693 Token Exchange. The agent can now act on behalf of users without those users handing raw API keys to a third party.

Farcaster miniapp frame — the app now launches directly from the Farcaster social layer, which is a meaningful distribution channel for the Web3-adjacent audience OnPoint is built for.

What I'd do differently: I'd have extracted agent-core earlier. The Phase 2 extraction in ADR 0001 was necessary but disruptive — a deployment change became a refactor. I'd also have been more conservative about the chrome extension. It shipped but hasn't been maintained; better to have left it as a future phase than carry the dead code.

My Experience with GitHub Copilot

OnPoint spans more languages and runtimes than most projects its size — TypeScript for the Next.js frontend and Express API, Python for the FastAPI agent bridge, Solidity for on-chain contracts, and shell scripts for deployment. Switching contexts across all of these in a single session is where Copilot earned the most.

The fraud detection tests were a good example. Mocking Redis across 14 scenarios — high velocity, unusual amounts, Dead Man's Switch triggers, multi-sig lifecycle, alert resolution — required thinking through edge cases that hadn't come up in the happy path: what happens when an agent has no prior heartbeat? What about zero-value transactions? Copilot was good at generating the boilerplate mock structure once I'd defined the first two or three cases, which meant I spent my time thinking about the scenarios rather than the scaffolding. The test file became documentation.

Cross-language consistency — when wiring the Python bridge to the TypeScript API, Copilot helped keep interface contracts consistent. It would suggest Python function signatures that mirrored the TypeScript types I'd defined, which caught a handful of mismatches before they became runtime errors.

ADR drafting — this was a surprise. When writing the Architecture Decision Records, Copilot's inline suggestions helped maintain the consistent structure (Context → Decision → Consequences) and often anticipated trade-offs I was about to articulate. The commit references, the "Out of Scope" sections, the migration phases — Copilot helped maintain that discipline across multiple documents without me having to paste a template each time.

Multi-chain wallet integration — RainbowKit + Wagmi + multi-chain configuration has a lot of repetitive ceremony. Copilot handled the per-chain config objects and provider setup cleanly, letting me focus on the ERC-8004 agent identity integration, which was the genuinely novel part.

The honest caveat: the hardest decisions — the Hetzner migration, the curator primitive model, the fraud detection thresholds — Copilot didn't make. Those required working through the product and the trade-offs. What it did was compress the distance between decision and working code, which for a project with this much surface area made a real difference.

Find me on Farcaster and Lens — always building at the intersection of AI, emerging markets, and on-chain infrastructure.