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.
Top comments (0)